Bug 99615 - No way to accept autocomplete and continue typing in the cell (without exiting and returning)
Summary: No way to accept autocomplete and continue typing in the cell (without exitin...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: accessibility
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
Reported: 2016-05-01 20:30 UTC by teo8976
Modified: 2018-06-21 08:41 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description teo8976 2016-05-01 20:30:49 UTC
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.
Comment 1 V Stuart Foote 2016-05-02 00:29:47 UTC
OK, to new.
Comment 2 Alex ARNAUD 2016-05-10 09:52:51 UTC
It's also a problem for keyboard users like blind and visual impaired.
 It's for me a bug that causes difficulties for users.
Comment 3 Heiko Tietze 2018-06-14 13:20:12 UTC
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.
Comment 4 Eike Rathke 2018-06-15 09:15:05 UTC
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.
Comment 5 Heiko Tietze 2018-06-21 08:41:26 UTC
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.