Description: It would come in handy to have a visual indicator which would make it possible for user to know if he is in the «Edit» mode or in the «Quick entering» mode (I do not know the official term for this mode, if any) at any given moment. Some background that is applied automatically as soon as the first character is typed when in «Quick entering» mode, but would be gone as soon as one switches to the «Edit» mode comes to mind as a possible solution. Here is the rationale. Normally, it does not make any difference in case one enters numbers in cells (one types number's digits and hit «Enter», period). However, should one enter text (making typos this time and another) and hit «Left» to correct a typo, the results will be completely different depending on whether F2 has been hit. On the other hand, should one enter text in some cells and formulae in some others the problem gets worse. It sounds a bit stupid (How can not one know whether he has hit key F2 or «Enter» provided the latter is configured?), but in reality it makes life harder and causes unneeded headaches and frustration for some of users (for example, please see https://ask.libreoffice.org/t/cell-edit-mode-on-by-default/78516). Please do not misunderstand me. It is perfectly possible to live without the proposed functionality. It is only a matter a convenience and overall satisfaction from my viewpoint. Still, some people would appreciate that. Steps to Reproduce: 1. Get focus to a cell, hit «a». Actual Results: The cell background remains white. Expected Results: The cell background turns, I do not know, light yellow, for example. Reproducible: Always User Profile Reset: No Additional Info: Sorry for so many words.
UX/Design team, has it been suggested in the past to use a visual aid to denote cell edit mode?
F2 (or Enter) and type-ahead both go into the edit mode where the second just overwrites the content. Some visual indicators exists to make the edit mode obvious, eg. hidden cell frame and input cursor, but more were requested in bug 63374 and are being implemented (final pieces missing). My take: duplicate
Ah, thanks for digging that out. I agree, let's mark as duplicate. *** This bug has been marked as a duplicate of bug 63374 ***