Steps to reproduce: 1 - Have some cell that contains a given string, e.g. "foo bar" 2 - Start typing into another cell: start by typing the first few characters of that string, in this example "fo" => the string "foo bar" is proposed as autocomplete Expected behavior: You should be able, by using either the TAB key or the right arrow, to "accept" the proposed autocomplete without leaving the cell, for example to continue typing or delete a few characters and finish entering a slightly different string. This is how practically EVERY other software that has autocomplete works, it's a well established UI convention. Observed behavior: there's no keystroke that can give you that. If you hit tab, the right arrow (or any arrow for that matter), or the Enter key, you "accept" the autocomplete but you also leave the cell. The only way to go on editing it is by DOUBLE-CLICKING on it, that is, you have to move your hand away from the keyboard and grab the mouse, and then go back to the keyboard. This is extremely annoying. I know this is consistent with the behavior of calc in general, BUT, again, in every conventional UI, autocomplete behavior usually overrides the generic behavior of keys. For example, in browsers, the tab key while typing into an input field usually moves focus to the next input field, but if you are being offered an autocomplete, the tab key instead accepts it and does not move focus; the same for the Enter key, which usually sends the entire form, but when you are being offered an autocomplete just accepts it without performing the default action.
OK, to new.
It's also a problem for keyboard users like blind and visual impaired. It's for me a bug that causes difficulties for users.
Basically I agree and would suggest the cursor right key jumping to the end. But in order to allow quick input we jump to the next cell per cursor; and to evaluate if the current cell editing mode includes an autocompleted text sounds confusing and inconsistent. So if we go ahead with this change we have to accept a serious regression.
While editing a cell, F2 enables and disables the in-cell cursor movement, and for this case also accepts the auto-completion suggestion so it can be edited. Also, Ctrl+Tab and Shift+Ctrl+Tab (without F2 first) travel through the possible completions. I'm strictly against fiddling around with the behaviour of (Shift+)Tab/Enter and cursor keys finishing the input and going to the next cell if F2 wasn't used to activate the in-cell movements. The argument "there is no keyboard shortcut and on can only double-click" is moot, use F2. I suggest to close this.
We discussed the topic in the design session and agree with Eike. The supposed workflow is to go into edit mode per F2; that's by the way the same in Excel.