Bug 142214 - Improve Calc's auto-complete feature
Summary: Improve Calc's auto-complete feature
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.7.2 release
Hardware: All All
: medium enhancement
Assignee: Dennis Francis
URL:
Whiteboard: target:7.2.0 target:7.3.0 target:7.2.1
Keywords:
: 43742 (view as bug list)
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2021-05-11 09:07 UTC by Dennis Francis
Modified: 2023-04-05 03:04 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
why does "bestellt" not work?!? (173.14 KB, image/gif)
2021-09-16 09:29 UTC, Viktor
Details
Autofill / AutoInput was fine in 7.1.x, not so fine in 7.2.1, dont fix something that is perfect (15.23 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-09-16 16:52 UTC, Getafix
Details
attached file contains 5000+ entries, Autocomplete works fine in 7.1.6 but DOES NOT even in 7.2.2 (41.30 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-10-16 08:35 UTC, Getafix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Francis 2021-05-11 09:07:58 UTC
Description:
Calc's auto-complete behaviour is different from that of its other popular alternatives and there is some scope for user experience improvement by reducing differences such as:

1. Calc auto-complete should offer suggestions only from the block of nonempty cells above/below the current cell; ie. imagine you have "Hello" in A1. When the user is in A2, they should be getting suggestions when they start typing an "H"; but when the user is in in A4, A5 or A1000, there should be no suggestions at all.

2. It should offer no suggestions until it is completely clear that there are no options any more ie. imagine you have "Hello", "Hero", "Hesitate" in A1, A2, A3. When in A4, and press "H" -> just "H" appears, now on adding an "e" -> still no suggestion, and finally on adding a "s" -> suggestion "Hesitate" (with the "itate" selected) appears. Currently Calc starts showing auto-completion with some chosen word from the list of possible matches, so the user has to pay close attention whether the current completion is correct or not.

Steps to Reproduce:
Currently Calc's behaviour is different from the points (1) and (2) mentioned in the description.

Actual Results:
For point (1) Calc auto completes even in A4 or A5 or A1000
For point (2) Calc auto completes to "Hello" on typing just "H" even though there are other choices.

Expected Results:
Mentioned in the description in points 1 & 2.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.7.2
Build ID: 1:6.4.7-0ubuntu0.20.04.1
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3; 
Locale: en-US (en_IN); UI-Language: en-US
Calc: threaded
Comment 1 Commit Notification 2021-05-13 14:24:37 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f8039c6d645acb015a6c4e45000bbfd1311bfea3

tdf#142214: show autocompletion only if there is...

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 2 Commit Notification 2021-05-13 14:24:47 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ca2ec443893731093970914feb750b31ea13e47f

tdf#142214: autocomplete: do not search across empty blocks

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 3 Commit Notification 2021-05-13 14:25:57 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/06c360d4d27ab0dadfdcd5f9d4f0c87288d3cb75

tdf#142214: unit-tests for new behaviour of auto-complete

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 Commit Notification 2021-05-13 14:26:07 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ebff4e5181b102e5184277f57fda32fcce60431f

tdf#142214: autoinput: remove search/entry count limits

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Commit Notification 2021-05-13 14:30:19 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/17d4221c047eac47e26465ddc72d13fb89284f57

tdf#142214: unittest:test autocomplete through numeric block

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Buovjaga 2021-06-04 06:35:27 UTC
*** Bug 43742 has been marked as a duplicate of this bug. ***
Comment 7 Buovjaga 2021-06-08 05:09:31 UTC
Dennis: there are a couple of reports that requested autocompletion by most used: bug 78545, bug 117344. What do you think about the approach? Should I keep them as closed or open one of them?
Comment 8 Dennis Francis 2021-06-09 07:25:24 UTC
(In reply to Buovjaga from comment #7)
> Dennis: there are a couple of reports that requested autocompletion by most
> used: bug 78545, bug 117344. What do you think about the approach? Should I
> keep them as closed or open one of them?

Keeping one of them open would make sense I think as this bug focus on the conventional behaviour of autocomplete so somewhat different from them.
Comment 9 John 2021-07-30 16:39:54 UTC
I have been looking at 7.2 and have just noticed this altered behaviour for AutoInput. it does not work for me and essentially breaks function as the columns in which I use AutoInput do not always have entries, i.e. empty cells. While I appreciate that some might like this function I would like to suggest the option to turn it off and to revert to the previous behaviour whereby the options offered were taken from the whole of the column.
Comment 10 Mike Kaganski 2021-08-09 14:46:31 UTC
(In reply to Dennis Francis from comment #0)
> 2. It should offer no suggestions until it is completely clear that there
> are no options any more ie. imagine you have "Hello", "Hero", "Hesitate" in
> A1, A2, A3. When in A4, and press "H" -> just "H" appears, now on adding an
> "e" -> still no suggestion, and finally on adding a "s" -> suggestion
> "Hesitate" (with the "itate" selected) appears. Currently Calc starts
> showing auto-completion with some chosen word from the list of possible
> matches, so the user has to pay close attention whether the current
> completion is correct or not.

Note that the described behavior allowed one to use Calc's usual keyboard shortcut - Ctrl+(Shift+)Tab - to select from all the available suggestions. Also note that now, after the changes mentioned here, it's still working; so entering "h" and pressing the shortcut would provide the suggestions even though the auto-completion didn't appear automatically. So there is a working mechanism to choose other variants; sorting the suggestions based on arbitrary criteria (e.g., frequency) might be implemented separately.
Comment 11 Mike Kaganski 2021-08-17 05:42:58 UTC
Dennis: worth mentioning at release notes?
Comment 12 andis.lazdins 2021-08-17 09:59:21 UTC
Is it possible to get back to previous behavior, e.g. by an expert setting? 
It is now very annoying that any empty cell results in ignoring of all values above or below the empty cell.
Comment 13 Cor Nouws 2021-08-18 11:38:05 UTC
I really support the idea that the old behavior should be available somehow, allowing to chose from the already present values in the column.

I work really often in tables where there are empty cells, and still values that already exist must be used again
These are values that can be random, so having a range/source to use in Data>Validity is impossible

I do not object a setting.
And if it is really needed to use a extra key-stroke (alt+Down) to start a list with present content, well, I can live with that too.
Comment 14 Xisco Faulí 2021-08-24 16:02:04 UTC
(In reply to andis.lazdins from comment #12)
> Is it possible to get back to previous behavior, e.g. by an expert setting? 
> It is now very annoying that any empty cell results in ignoring of all
> values above or below the empty cell.

I do agree. We already have some reports about it and more will come for sure.
Adding Eike and Heiko to loop, I think they should also know about it
Comment 15 Heiko Tietze 2021-08-25 07:03:48 UTC
Options for each and every setting... Can we tackle the problem from the interaction, eg what's being requested in bug 133494?

Otherwise, since apparently so much interest exists in whether to stop by blank lines I would make it a real (tools > autocorrect) option.
Comment 16 Viktor 2021-08-25 16:08:34 UTC
I would also be in favor of this being optionally toggled or enabled. This would then successfully serve both groups of users.
Comment 17 Milston B. 2021-08-27 16:43:50 UTC Comment hidden (off-topic)
Comment 18 gigago 2021-08-27 21:09:53 UTC
OH THE HORROR

I stumbled over the new broken behaviour as well. Let's look at this functionally:

-> Calc auto-complete should offer suggestions only from the block of nonempty cells above/below the current cell.

Erm... autocomplete by definition promises to either scan 2000 rows or 200 items max, whichever comes first. Your proposal completely breaks this extremely useful functionality for an astounding number of real world cases. Many worksheets DEPEND on having empty rows to conceptually, visally AND technically separate data. I assure you that Microsoft does _a lot_ better than this!

-> but when the user is in in A4, A5 or A1000, there should be no suggestions at all.

What? Allow me to suggest an excellent solution for your use case: DISABLE AUTOINPUT for your 998 empty rows worksheet.

By the way, the autocomplete drop down list is also COMPLETELY BROKEN now: in many cases it only shows a handful of items, that are already visible on the page, directly next to the active cell. Now think about this: autoinput's usefulness consists primarily in showing things that are NOT visible on the page directly next to the cell you're editing, e.g. an entry a thousand rows back.

I do agree that libreoffice does not select the smartest suggestions. Apparently calc always simply picks the first, thus oldest item on the list. IIRC, Excel rather presents the *last* candidates from the scanned list, which in practice often turns out way more relevant than the first.

*Please* undo this utterly tragic non-solution to a non-problem ASAP. Or at the very least make it optional, so users can opt out of this disaster.
Comment 19 gigago 2021-08-27 21:48:21 UTC
Oh by the way, do not make this new "functionality" the default!
Comment 20 Michael Bauer 2021-09-03 12:02:26 UTC
This, in a nutshell, encapsulates all that is wrong with FOSS. Someone with a pet peeve (in this case, trying to make everything like Microsoft) finds a discrepancy that is not even a bug, "fixes" it and boom, users are saddled with it without anyone ever checking with the end users if this is *actually* a problem or even vaguely desirable.

We tolerate absurd things like the default paste from MS Word to Calc producing an OLE object (Bug 113719) or offering the wrong editing languages to users (Bug 95274 - incidentally, that is the MAIN reason why I'm still using MS Word for word processing, this issue makes Writer simply unusable for people working in multiple languages) but we can't possible tolerate a useful deviation from Excel such as permitting auto-complete when there are empty cells in between. Which funnily enough, is the MAIN reason why I moved from MS Excel to Calc for my work spreadsheets because Calc doing auto-complete in spite of empty cells in between is actually *useful*, like when you're using a spreadsheet to track different client invoices and payments in the same sheet and you have, to preserve your sanity, used (among other things) empty cells to break up certain areas.

Dennis "fix" may have been well-intended but it sure wasn't needed, at best should have been a new option and most certainly should have been subjected to more scrutiny before hitting a general release.
Comment 21 chrisretusn 2021-09-04 10:30:44 UTC
Version: 7.2.0.4 / LibreOffice Community
Build ID: 20(Build:4)
CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-PH (en_PH.UTF-8); UI: en-US
SlackBuild for 7.2.0 by Eric Hameleers
Calc: threaded

Okay I have to chime in on this. This new behavior is terrible. I have been using LIbreOffice Calc for years, When I enter data in columns I want suggestions of entries in that column.

Sheet has 7 columns, at least three are filled every day, there can be multiple entries on a single day. These are currently are 694 rows with data, 695 to 703 are blank except for column 7 which has a formula. The data rows 1 to 703 is used in a formula in a another sheet, so one must add new rows within the cell range of the formula. Below this data section there are three columns of text that are unique entries from the previous years spreadsheet. These are there to be used as suggestions for new entries in the data area.

Yesterday was a day where a particular column was not filled in. There was one row for that day. Today I needed to add four more entries (rows), as I typed in the cell below the empty column nothing was suggested! Say what! Nothing from below or above was suggested and Alt-Down did nothing. Normally unique entries from above or below in that column was suggested. So today I had to type out fully each of those four additions for today instead of getting suggestions or use Alt-Down to get a selection list. I'm just glad I didn't have a lot more to add for today.

Please fix/restore this or at least make it an option for the previous behavior.  Having the suggestions and/or Alt-Down selection list is an awesome time saver and it keeps data entries consistent within that column.
Comment 22 Hitesh Shah 2021-09-04 12:50:46 UTC
Point 1 of this issue affects me.

Re. "Calc auto completes even in A4 or A5 or A1000", what is wrong with that? Having intervening empty cells in a column should not make my data in filled cells unavailable to me wherever I choose in the same column via autoinput. 

A change in this behaviour from that in earlier versions degrades my productivity and user experience.
Comment 23 Michael Bauer 2021-09-04 13:38:05 UTC Comment hidden (off-topic)
Comment 24 Mike Kaganski 2021-09-04 14:30:27 UTC Comment hidden (insightful, off-topic)
Comment 25 Buovjaga 2021-09-04 17:45:20 UTC
I submitted a patch for reverting the change that ignores empty blocks: https://gerrit.libreoffice.org/c/core/+/121640
Comment 26 p.loretz@posnet.com 2021-09-06 08:45:08 UTC Comment hidden (me-too)
Comment 27 chrisretusn 2021-09-06 10:55:52 UTC Comment hidden (me-too)
Comment 28 Commit Notification 2021-09-06 11:48:52 UTC
Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/223f3a6fac43580114bca86abb34d7cf3219f4bc

Revert "tdf#142214: autocomplete: do not search across empty blocks"

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2021-09-06 13:21:45 UTC
Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/51964092e9a4e57c9455795e50c118fca8d8e0e6

Revert "tdf#142214: autocomplete: do not search across empty blocks"

It will be available in 7.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 30 Commit Notification 2021-09-06 13:53:38 UTC
Ilmari Lauhakangas committed a patch related to this issue.
It has been pushed to "libreoffice-7-2-1":

https://git.libreoffice.org/core/commit/4ac35a8b1f1861b9a01e1c0490c5415df4057b66

Revert "tdf#142214: autocomplete: do not search across empty blocks"

It will be available in 7.2.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 31 chrisretusn 2021-09-10 09:01:54 UTC
(In reply to chrisretusn from comment #27)
> Today I ran in to this issue
> 
> TEST test
> TEST rext
> 
> No suggestion until "TEST r" or "TEST t" was typed in the cell immediately
> below these two cells. Not cool! Before I was offered at least one, if that
> was what I wanted then tab, next cell, continue...  

This seems to carry out to as many characters that match, example:

Long sentence to enter today
Long sentence to enter tomorrow
Long sentence to enter yesterday

When typing in the cell below, one must type "Long sentence to enter t" (or "y") before you get a suggestion. 

Does the patch fix this too?
Comment 32 Commit Notification 2021-09-10 12:31:36 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f26af764dee862e5c9a689d242ee72d1dac8bc1f

tdf#142214: reintroduce unittest and adapt it to the expected behaviour

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 33 chrisretusn 2021-09-14 07:33:27 UTC
I've reverted back to LibreOffice Version: 7.1.4.2

I rebuilt version 7.2.0.4 with this patch: 
https://git.libreoffice.org/core/+/4ac35a8b1f1861b9a01e1c0490c5415df4057b66%5E%21

I couldn't figure out how to download a patch file from that site, I did find the github site which I do now how to get a proper patch file download. 

I seems I am missing a few other patches. 

The patch I installed looks like it restored Alt-Down behavior and some of the auto suggest from cells above and below.

I may try and rebuild with the other patches listed here.

Bottom line will these patches restore the behavior as it was before this new version?

The old way, I type in a character in the cell, it suggest an entry from above or below in alphabetical order, regardless of empty cells, on entering second character the suggestion changes to the next available suggestion. 

Example:

Somewhere in the column are
Burger Buns
Baby Potatoes
Burrito, Beef Bean
Burrito, Beef Bean Green Chili
Burrito, Beef Bean Red Hot

If I type "b" in an empty cell in the column, the suggested entry is "Baby Potatoes". If I type "bu" the suggestion changes to "Burger Buns". If I type "bur" the suggestion remains "Burger Buns". Typing "burr" the suggestion changes to "Burrito, Beef Bean". Hitting <tab> or <enter> will complete the entry with the suggestion. In the case of the "burr" suggestion of "Burrito, Beef Bean" I can hit <F2> to edit the cell, type a space and the suggestion changes to "Burrito, Beef Bean Green Chili". Type r after the space, and the suggestion is now "Burrito, Beef Bean Red Hot"

This helps get data entry consistent in all cells in the column, it also saves typing time. 

The new way doesn't do this at all, every entry must be typed out if it's not in the cells above, the suggestions are only from the cells above that are not broken with an empty cell. On top of that, even if there are matching cells above like with the Burrito above, one must type out "Burrito, Beef Bean " before a suggestion is presented. 

Before I reverted back to 7.2.0.4 I was find I had to scroll up or down the list to copy and paste previous entries from above or below. 

I do hope all these patches restore the old behavior.
Comment 34 Buovjaga 2021-09-14 07:40:25 UTC
(In reply to chrisretusn from comment #33)
> I do hope all these patches restore the old behavior.

There is only one revert patch. It does not restore the old behaviour. The only thing it does is undo the most controversial change, skipping search across empty blocks. The idea going forward is to continue tweaking the behaviour to improve the feature. See for example comment 15.
Comment 35 chrisretusn 2021-09-14 07:51:10 UTC Comment hidden (obsolete)
Comment 36 Buovjaga 2021-09-14 08:01:19 UTC Comment hidden (obsolete)
Comment 37 chrisretusn 2021-09-14 09:14:50 UTC Comment hidden (obsolete)
Comment 38 Buovjaga 2021-09-14 09:21:23 UTC
(In reply to chrisretusn from comment #37)
> Ah, okay. I can see that commit 51964092e9a4e57c9455795e50c118fca8d8e0e6 and 
> 4ac35a8b1f1861b9a01e1c0490c5415df4057b66 are indeed the same. Though commit
> f26af764dee862e5c9a689d242ee72d1dac8bc1f is different. 
> 
> I am learning as I go. 
> 
> Is there a way to get the patch from the git.libreoffice.org site, I am
> currently using the github.com/LibreOffice/ site to grab patches. Thanks. 

If you are logged into Gerrit, you have access to a bunch of ways to download and apply the patch. Click the kebab menu and Download patch. As you maybe don't have an account in our single sign-on system, here is a direct link to a zipped diff: https://gerrit.libreoffice.org/changes/core~121640/revisions/3/patch?zip
Comment 39 Eike Rathke 2021-09-14 10:10:34 UTC
Fwiw, downloading a patch set from a gerrit change is also possible without account or being logged in, it also offers various strategies with commands to directly apply the patch to a cloned repository. Just visit the last Reviewed-on Gerrit URL mentioned in each commit message (e.g. for https://git.libreoffice.org/core/commit/4ac35a8b1f1861b9a01e1c0490c5415df4057b66 that's https://gerrit.libreoffice.org/c/core/+/121570 ) and click Download.

Or simply with a cloned repo do like

git fetch
git cherry-pick 4ac35a8b1f1861b9a01e1c0490c5415df4057b66

When using GitHub (why even) it's also possible to append .patch to a commit URL, so for example for
https://github.com/LibreOffice/core/commit/4ac35a8b1f1861b9a01e1c0490c5415df4057b66
use
https://github.com/LibreOffice/core/commit/4ac35a8b1f1861b9a01e1c0490c5415df4057b66.patch
Comment 40 chrisretusn 2021-09-14 11:03:34 UTC Comment hidden (obsolete)
Comment 41 chrisretusn 2021-09-14 11:12:06 UTC Comment hidden (obsolete)
Comment 42 Viktor 2021-09-16 09:29:36 UTC
Created attachment 175058 [details]
why does "bestellt" not work?!?

the new adaptation seems to be even a bit more "unreliable" than "before


Tested under ▼▼
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Version: 7.2.1.2 (x64) / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Comment 43 Buovjaga 2021-09-16 10:39:49 UTC
(In reply to Viktor from comment #42)
> Created attachment 175058 [details]
> why does "bestellt" not work?!?
> 
> the new adaptation seems to be even a bit more "unreliable" than "before

See my comment 34 and please be patient.
Comment 44 Getafix 2021-09-16 16:46:59 UTC Comment hidden (noise)
Comment 45 Getafix 2021-09-16 16:52:15 UTC Comment hidden (noise)
Comment 46 Getafix 2021-09-16 16:56:11 UTC Comment hidden (noise)
Comment 47 Timur 2021-09-17 08:35:10 UTC
I didn't find a time to test all this, but I see a huge backlash from users. 
I see a recurring problem, like with Calc pointer: someone thinks that something should be different and just changes that, even that many would prefer it like it was. And does that without UXeval, which is there to control and prevent. 
In those cases rule of thumb should be (as in Comment 12, Comment 16, Comment 19): add change only as an option (like finally it went for Calc pointer). It's not "Options for each and every setting" but for new controversial change. 
It's very important and politely said in Comment 20, which should be seen and is definitely not off-topic, so I make it visible, last time I hope.
Comment 48 Michael Warner 2021-09-17 14:29:30 UTC Comment hidden (off-topic)
Comment 49 Timur 2021-09-17 14:32:07 UTC
My proposal here is to revert all in 7.2 and continue with 7.3+.
Comment 50 Mike Kaganski 2021-09-17 14:49:44 UTC Comment hidden (off-topic)
Comment 51 Michael Warner 2021-09-19 01:01:13 UTC Comment hidden (off-topic)
Comment 52 Mike Kaganski 2021-09-19 08:13:03 UTC Comment hidden (insightful, off-topic)
Comment 53 gigago 2021-09-29 18:47:02 UTC
Hi

Relieved to see the "empty lines" change undone, good job.

Not too happy about the new "delay" feature though, which prevents many items from being suggested until they're almost completely entered. Yes, one can request the autocomplete list upfront with Alt+Down Arrow but frankly, it's a bit of a pain to be forced to do this every time. It's particularly painful to watch my carefully crafted, self-sorting entries being completely ignored - presumably because they're "too similar" or some other arbitrary criterion.

I will propose again that selecting the *last* matching item in the autocomplete list gives more relevant results. Many times one will enter similar entries in a column with just one or more small changes. Thus, later entries simply have a bigger chance of being closer to what one needs today.

Otherwise, as real improvement seems hard to attain, I would propose to completely revert any and all changes to the autocomplete functionality in this package.

Regards
Comment 54 chrisretusn 2021-09-30 08:37:36 UTC
I am disappointed that Calc (7.2.1) still does not work as it has before 7.2.0. It is nice that the I can now use the Alt+Down feature to get a selection of available entries from a cells in that column.

It is also okay, that I can start to type and get a suggestions BUT, if there are like entries in the list, I have to keep typing until I get a unique one. The previous behavior was I was offered suggestions right away.  

See my comment 31: and comment 33:

I have many spreadsheets setup to utilize the prior behavior of Calc (version 7.1.4), this change has really made it difficult to work with many of my spreadsheets, so much that I reverted back to 7.1.4 and it appears with reports regarding 7.2.1 will continue to use 7.1.4. 

One of the reasons I like to previous behavior is the often time many entries that need to be entered multiple times in the same column. Having this suggestions available help keep entries consistent in the column. It also saves on typing.

I would suggest that the previous autocomplete behavior of Calc be restored as it was before 7.2.0.

Thanks
Comment 55 Gene Sain 2021-10-07 11:28:04 UTC
I would add that the behavior of 7.1.4 should be restored.  I have reverted back to 7.1.4.  My main use of Calc is electronic check registers.  The prior behavior significantly reduced typing / data entry.  Shouldn't have to hit other keys or make selections from list.  It just needs to look up prior column entries as you type.  While many entries are monthly, some are quarterly or annual, but the vast majority are repetitive.  I am doing annual pivot tables off of the rows of data and consistency in the input is paramount.  Occasionally I will make an error that is saved, but I go edit that data to the correct format.  This is a rows and columns tool, preserve that integrity.
Comment 56 Timur 2021-10-08 04:41:10 UTC
This bug was started and commits and reviews done by the single person. It didn't have UXeval, which I ask now. IMO it's of the highest priority for UX, given number and content of comments, including those hidden. 
This is WIP and should not affect Fresh version 7.2 with frozen GUI and features, so I asked to revert all commits in 7.2 and consider issue with 7.3+.

Personally at this moment, unless explained differently, I don't see other option than to add changes only as an option. 
While "we can't have options for all" they should exist for controversial features, where user expectations are different.
Comment 58 Heiko Tietze 2021-10-08 08:03:22 UTC
(In reply to Mike Kaganski from comment #57)
> https://lists.freedesktop.org/archives/libreoffice/2021-October/087911.html

Which is also UX input. Until a better solution is implemented (see bug 133494?) we could add an option, perhaps via expert setting. The ultimate solution might be worth a GSoC project if the effort is too large.
Comment 59 Getafix 2021-10-16 08:35:13 UTC Comment hidden (me-too)
Comment 60 chrisretusn 2021-10-16 14:41:17 UTC Comment hidden (me-too)
Comment 61 Timur 2021-10-18 15:52:58 UTC Comment hidden (obsolete)
Comment 62 Manfred 2021-11-01 10:17:52 UTC Comment hidden (me-too)
Comment 63 Timur 2021-11-02 08:20:17 UTC
Ilmari, please explain why you hid some comments with "me-too" . That tag is used when someone repeats or updates his own comment, but those are not redundant. 

Could someone confirm or explain this, because users still complain for 7.2.2 and there's no patches here:
(In reply to Timur from comment #61)
> IIUC, ESC opted to revert changes in 7.2 and continue in 7.3.
Comment 64 Buovjaga 2021-11-02 09:47:33 UTC
(In reply to Timur from comment #63)
> Ilmari, please explain why you hid some comments with "me-too" . That tag is
> used when someone repeats or updates his own comment, but those are not
> redundant. 

No, the tag is used whenever someone comments on an obviously confirmed thing with no new information.

More interesting would be to try a master build, which has had the change from bug 145198 since 18 Oct.
Comment 65 Aron Budea 2021-11-16 01:36:47 UTC
(In reply to Timur from comment #63)
> Could someone confirm or explain this, because users still complain for
> 7.2.2 and there's no patches here:
> (In reply to Timur from comment #61)
> > IIUC, ESC opted to revert changes in 7.2 and continue in 7.3.
This is the revert of the remaining patches in 7.2, merged on 2021-10-12 (7.2.2.2 was tagged on 2021-10-06):
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-7-2&id=1e033fe1f270e7a76cb8821af9ceb1c096403442

Reverts will be part of 7.2.3, with RC1 pre-release already available for download, final release planned next week.
Comment 66 Ming Hua 2021-11-28 03:35:33 UTC Comment hidden (obsolete)
Comment 67 Xisco Faulí 2021-11-29 11:27:34 UTC Comment hidden (obsolete)
Comment 68 Buovjaga 2021-11-29 11:32:37 UTC
(In reply to Xisco Faulí from comment #67)
> (In reply to Ming Hua from comment #66)
> > My understanding is that all changes regarding auto-input have been reverted
> > in 7-2 branch since 7.2.3, so I've also removed the entry for this in 7.2.x
> > release notes on wiki:
> > https://wiki.documentfoundation.org/ReleaseNotes/7.2#General_improvements_2
> 
> yep, good point. it should be in the 7.3's release notes, though

Implementation of bug 145198 is already in 7.3 release notes. It was implemented over a month ago, but nobody gave feedback on it yet, so please everyone test the new behaviour in 7.3
Comment 69 Getafix 2021-11-29 13:08:20 UTC
(In reply to Buovjaga from comment #68)
> (In reply to Xisco Faulí from comment #67)
> > (In reply to Ming Hua from comment #66)
> > > My understanding is that all changes regarding auto-input have been reverted
> > > in 7-2 branch since 7.2.3, so I've also removed the entry for this in 7.2.x
> > > release notes on wiki:
> > > https://wiki.documentfoundation.org/ReleaseNotes/7.2#General_improvements_2
> > 
> > yep, good point. it should be in the 7.3's release notes, though
> 
> Implementation of bug 145198 is already in 7.3 release notes. It was
> implemented over a month ago, but nobody gave feedback on it yet, so please
> everyone test the new behaviour in 7.3

I checked on Windows10_x64 and Ubuntu_21.10_x64, in both LO_7.2.3 Auto-fill/Auto-complete function is back to normal and is working fine as it used to do earlier, thanks to this now I can update from 7.1.7 to 7.2.3 on my production machines, thanks all
Comment 70 chrisretusn 2021-12-04 07:13:01 UTC
I hope this is permissible. I have been using Version: 7.2.3.2 now since November 27. Calc is working as expected. Very happy to be on an updated version again. Many thanks to the Developers for rethinking this "enhancement".
Comment 71 Timur 2021-12-04 08:00:31 UTC
As Buovjaga wrote in Comment 68,it would be valuable if users could give a feedback not on 7.2 but on LO 7.3 or on master installing from https://dev-builds.libreoffice.org/daily/master/current.html (In addition to working LO).
Comment 72 Xisco Faulí 2022-05-03 12:28:25 UTC
A polite ping to Dennis Francis:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ?
Otherwise, Could you please explain what's missing?
Thanks
Comment 73 Michael Bauer 2023-01-04 12:53:26 UTC
It would seem the broken behavious is back

Version: 7.4.3.2 (x64) / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 6; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: gd-GB (gd_GB); UI: gd-GB
Calc: CL
Comment 74 Buovjaga 2023-01-04 16:13:03 UTC
(In reply to Michael Bauer from comment #73)
> It would seem the broken behavious is back

Broken how? Do you mean to say you don't like how the change in bug 145198 was implemented?
Comment 75 Heiko Tietze 2023-01-10 08:21:58 UTC
*** Bug 152936 has been marked as a duplicate of this bug. ***
Comment 76 Stéphane Guillou (stragu) 2023-04-04 10:14:01 UTC
Marking this as "resolved - fixed" as it was implemented, and then the less popular part was reverted.

Michael, and others: if there are issues in currently supported version (7.4 and 7.5 at the time of writing), please look at other related reports (there are quite a few in "See also" and the meta bug 103341) or open a new one. 74+ comments here makes it hard to navigate.

Thanks!