Bug 104185

So what do we do after we change the default and millions of angry users attack?

So just add possibility to change it in settings. You know better what is good as default, I've only mention what would be better for me (and I consider it as more logical), just as a feedback.

BTW* this would not be so big change as when you break compatibility in macros for ver.4 vs ver.5. People can learn minor changes in gui/behavior, but cannot keep running their scripts.
*Its 'btw'. I doesn't mean I want force my point of view.

**Solution**
for people who don't want this feature

-> uncheck tools/autoinput
but this doesn't switch it off at all. If you type more letters and than delete them by backspace, autoinput still works.

If don't want switch autoinput off or be sure that this will never happen accidentialy, teach your muscle memory to use TAB, ENTER instead of ENTER.

Typically the dropdown for autocomplete shows up and after selecting one the items it is inserted with enter. Having another option like (o) Enter, () Shift+Enter, () Ctrl+Enter sounds like an overkill.

However, we could change the autocomplete behavior. As reported by Mieszko the functions is not shown when text is added and AutoInput (bad camel case) is disabled but pops up on backspace. And when this bug is solved we could introduce a manual autocomplete like the user enters =p and presses <F2> (use a good shortcut here) the function list is shown. But the selection of an entry would be done per Enter.

unconfirmed -> new
enhancement -> normal since autocomplete is buggy for backspace. 
-needsUXEval +needsDevEval

Hi,

The looks of auto-input has been changed but disabling tools->auto-input still doesn't work on backspace press.

Version: 6.0.4.1
Build ID: 00m0(Build:1)
CPU threads: 4; OS: Linux 4.16; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.

Some alternatives:

1) Change auto entry to use tab, the default in almost every other system out there from Eclipse clear down to MS Hotmail. Obviously, my choice and Mieszko's but another idea is...

2) Don't kick in auto entry after backspace...per other suggestions already given.

3) Don't kick in auto entry until at least two (even three) letters have been typed. That would at least avoid the mess for simple column reference situations in the vast majority of cases.

4) Put "Tab to ignore" in bold at the end of the auto entry popup text tip while not changing the behavior at all.

I think this is more than a preference question. If you, for example, have 
=($A:$A) in column C then go to change that to 
=($B:$B) you get into a morass of =($B:$B()), etc., when doing the obvious and pressing Enter.

Here is the thing: Anyone wanting auto entry will be able to see clearly if that function has popped up, and will probably have to keep typing awhile before the drill down matches what they want, anyway. Meanwhile, the person expecting enter to do as it says and enter the edited value into the cell is left trapped, having to re-edit, and having to click into the end of the line or having to figure out to use tab to do what enter says right on the key, "Enter".

The popup tip for the auto entry feature could have a bold "then Tab" at the end of it if switched to tab. MS Hotmail does something like this. Or...if the behavior isn't changed, what about putting "Tab to ingore" at the end of the tip?

In any case, most intense users of LibreOffice Calc probably have the basic familiarity with tab for autocomplete, not enter. Tab for autocomplete is very mainstream.

In case anyone's interested, I think I've pinpointed the part of the code where function autoinput happens, with stephane's help.

In core/sc/source/ui/app/inputhdl.cxx , there's this segment under ScInputHandler::KeyInput :
        case KEY_RETURN:
            // New line when in the input line and Shift/Ctrl-Enter is pressed,
            // or when in a cell and Ctrl-Enter is pressed.
            if ((pInputWin && bInputLine && bControl != bShift) || (!bInputLine && bControl && !bShift))
            {
                bDoEnter = true;
            }
            else if (nModi == 0 && nTipVisible && pFormulaData && miAutoPosFormula != pFormulaData->end())
            {
                PasteFunctionData();
                bUsed = true;
            }
            else if ( nModi == 0 && nTipVisible && !aManualTip.isEmpty() )
            {
                PasteManualTip();
                bUsed = true;
            }
// And a few blocks down...
        case KEY_TAB:
            if (bControl && !bAlt)
            {
                if (pFormulaData && nTipVisible && miAutoPosFormula != pFormulaData->end())
                {
                    // Iterate
                    NextFormulaEntry( bShift );
                    bUsed = true;
                }
                else if (pColumnData && bUseTab)
                {
                    // Iterate through AutoInput entries
                    NextAutoEntry( bShift );
                    bUsed = true;
                }
            }

Move that PasteFunctionData block down to tab's handling and I think that should make it the new function entry key. User setting based would be optimal imo, but I haven't looked into how settings work. Would start from SC_MOD()->GetAppOptions().GetAutoComplete() and try to make a replica of the process.

(In reply to symbioma.trix from comment #11)
> I've pinpointed the part of the code...
Looks promising. Please assign the bug to yourself and set the status to assigned so it would be visible for other volunteers that you are working on it.

Apologies, heiko, I am not. Merely dropped a quick tip based on dry reading the code for someone who is more familiar with the project or has time to learn. A bit too much for me currently.

Hossein, what do you think about an easyhack?