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
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.
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.
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.
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.
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.
*** Bug 43742 has been marked as a duplicate of this bug. ***
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?
(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.
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.
(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.
Dennis: worth mentioning at release notes?
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 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.
(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
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.
I would also be in favor of this being optionally toggled or enabled. This would then successfully serve both groups of users.
Thank you Microsoft. First scientists had to rename genomes because you weren't willing to adjust Excels autocorrection AND now Libreoffice Calc had to downgrade the autocomplete to the level of Excel, because you couldn't handle the (over?)power of Calcs autocompletion?!
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.
Oh by the way, do not make this new "functionality" the default!
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.
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.
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.
Since when are objections to a bugfix (for a bug that wasn't a bug) "off topic"? Turning a bit North Korea, are we?
(In reply to Michael Bauer from comment #23) I set your comments off-topic, because they are off-topic. If you check, I didn't mark any other comments that way, because they were describing specific situations, even if sometimes too emotionally (e.g., comment 18). You were bashing something unrelated, which you also show lack of understanding ("all that is wrong with FOSS", "We tolerate absurd things like the default paste from MS Word to Calc producing an OLE object" etc.) By the way, I mark this my comment here off-topic, too - because it is not for the issue here, but just to tell you the obvious, which you seem to not see.
I submitted a patch for reverting the change that ignores empty blocks: https://gerrit.libreoffice.org/c/core/+/121640
Hi there, definitely agreed with all the complaints against the autocomplete behavior change given above! It is a feature downgrade in fact, and should be withdrawn or at least changed to not-default option.
(In reply to p.loretz@posnet.com from comment #26) > Hi there, definitely agreed with all the complaints against the autocomplete > behavior change given above! > > It is a feature downgrade in fact, and should be withdrawn or at least > changed to not-default option. Agree! 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... Why does LibreOffice have to behave the same as that other popular alternative. There are quite a few things that make LIbreOffice better than the other alternative. Request the former behavior be restore as the default. Add an option if this new "feature" must be included.
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.
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.
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.
(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?
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.
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.
(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.
(In reply to Buovjaga from comment #34) > (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. Thanks. I do hope there is work to put back the behavior as I described in my post. Did I apply the correct patch? I see at three different patches in the last few post above.
(In reply to chrisretusn from comment #35) > (In reply to Buovjaga from comment #34) > > (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. > > Thanks. I do hope there is work to put back the behavior as I described in > my post. > > Did I apply the correct patch? I see at three different patches in the last > few post above. The patches are not different. They are just applying the change to different version branches.
(In reply to Buovjaga from comment #36) > (In reply to chrisretusn from comment #35) > > (In reply to Buovjaga from comment #34) > > > (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. > > > > Thanks. I do hope there is work to put back the behavior as I described in > > my post. > > > > Did I apply the correct patch? I see at three different patches in the last > > few post above. > > The patches are not different. They are just applying the change to > different version branches. 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. I am still wondering why LibrOffice must behave that same as other popular alternatives. Thanks for the replies.
(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
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
(In reply to Buovjaga from comment #38) > (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 Thanks for the patch. I was able to verify that I am using the correct patch. I created my account in Bugzilla for LibreOffice a while back. I tried that with the single sign-on system, no go, so I created an account. It picked up my Bugzilla account and now I have access to Gerrit. I tried the download menu options I'm only offered git URLs. That said I did figure out how to get patches using your URL above as a hint. I tried with a few other commits and works like a charm. Thanks for your help. I'll guess I stick with 7.1.4.2 until they release 7.3, hopeful that I will still be able to use Calc the way I have been using it for years.
(In reply to Eike Rathke from comment #39) > 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 Thanks, I figured things out, the download overlay is not showing the bottom to options in my browser, zoom out a little and it's there. I use github a lot, already know that trick.
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 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
(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.
excuse my language and frustration What feature are you trying to incorporate ? Looks LibreOffice is trying to convince die hard users NOT TO USE libreoffice now. Don't break that's working fine or IS MICROSOFT PAYING DEVELOPERS TO DESTROY LIBREOFFICE FROM INSIDE OUT. Feature my ass, its more like poking a stick in the wheel of a running cycle If you want people to stop using libreoffice just say so. I have a perfect pirated Office 2019 running on my home computer and official legal office 2016 on my work computer. I use LibreOffice out of Love to Open Source, how much is Microsoft paying Trojan developers ? community should keep an eye on this issue also else this wonderful project will die sooner than later
Created attachment 175081 [details] Autofill / AutoInput was fine in 7.1.x, not so fine in 7.2.1, dont fix something that is perfect Autofill / AutoInput was fine in 7.1.x, not so fine in 7.2.1, dont fix something that was perfect or Is Microsoft paying Developers to mess things up You can always Ban me, I give a damn, already am fed-up with all these so called fixes which were never needed in the first place
This is the second time I'm going back to 7.1.x from 7.2.0 & 7.2.1 Seriously thinking LibreOffice has been compromised by Trojan developers paid by Microsoft With a heavy heart thinking of using MS Office now SHAME SHAME SHAME
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.
I have to agree with Timur in Comment 47. It seems to me that --- as a matter of process --- even committers should not be able to make user-visible changes without waiting for public comment, debate, and review by other LO developers.
My proposal here is to revert all in 7.2 and continue with 7.3+.
(In reply to Timur from comment #47) > I didn't find a time to test all this, but I see a huge backlash from users. > I see a recurring problem... (In reply to Michael Warner from comment #48) > I have to agree with Timur in Comment 47. It seems to me that --- as a > matter of process --- even committers should not be able ... I see here a problem of wrong expectations. Every angry person commenting here does two things. 1. They do exactly the task that an *independent* open-source project puts on its *users*: to be the part of the community, and affect its evolution e.g. by their feedback. 2. They show how they do not understand this their role, and express that they want that role to be off-loaded to some third party, so that they never need to do this. Problems happen. Having UX review is not a panacea (/me recalls on-going tdf#144247). Very many changes (basically all) are user-visible. Developers don't always know how much of impact a change would have. Trying to put more bureaucracy on the project is much better way to make sure it will die, than any conspiracy theories. But any user of LibreOffice *is* part of the team; nothing is free, and LibreOffice requires its users to serve as QA and UX, at least sometimes. Having proper expectations on this regard, and taking this load without anger, is a way to successful evolution, fixing any problems as they arise.
(In reply to Mike Kaganski from comment #50) > Problems happen. Having UX review is not a panacea Of course I am aware that it is only a tiny fraction of users who will ever visit BZ; and only a vanishingly small percentage of people (perhaps 0) who will monitor every item filed. So, IIUC, what you are saying is basically that even if this change had been proposed here, and left open for some time (say, a month) it might not have attracted much comment, or only comments from people who liked it, and then it would have gone through anyway, and there would have been the same surprised backlash from people who don't like it. This is a fair point. > Very many changes (basically all) are user-visible. Hmmm, many, perhaps most. But not all, at least not as I would define the term. Performance improvements, crash fixes, fixing other things that are obvious errors are technically "user-visible" but wouldn't ever be controversial. > Developers don't always know how much of impact a change would have. True...true... (In reply to Timur from comment #47) > 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. A nice idea, but which particular changes will be controversial? Before they are made, when we don't yet have any feedback, we can only guess. Adding an option for every UI change is too burdensome and overkill when only a small fraction of the total changes that are made will stir a strong reaction. > Trying to put more bureaucracy on the project is much better way to make > sure it will die, than any conspiracy theories. Where I work, every change is reviewed before it is committed, even changes made by the most senior developers. But on the other hand, that is a job where everyone involved is paid for their time; so the dynamics are different from a FLOSS project where some are paid and others are volunteers. To be clear, I am not advocating for any specific process change. I suspect situations like this are inevitable no matter what is done. Perhaps the number of them can be reduced somehow, but I refrain from advancing any wild ideas as to how that could be achieved. > Having proper expectations on this regard, and taking this load without > anger, is a way to successful evolution, fixing any problems as they arise. Good Life Pro Tip :-)
(In reply to Michael Warner from comment #51) > (In reply to Mike Kaganski from comment #50) > > Very many changes (basically all) are user-visible. > > Hmmm, many, perhaps most. But not all, at least not as I would define the > term. Performance improvements, crash fixes, fixing other things that are > obvious errors are technically "user-visible" but wouldn't ever be > controversial. Performance improvements: see https://git.libreoffice.org/core/+/9a5f2961b085ce2f23ecdf0a03d1114bacac8e2c improving performance and causing very user-visible bug 134234. Crash fixes: see https://git.libreoffice.org/core/commit/6db71f70a3b200d4074f6cda8ce445e9861d3296 fixing a crash in a debug build, which caused very user-visible bug 142165. ... and so on. There ate *really* very small percentage of changes that would not introduce a user-visible results; sometimes even an innocent refactor would hit a compiler bug/issue that would make the change a disaster (I recall bug 112928 that was caused by VS pre-2015 incompliance with C++11). So I claim this: ~every change you make has a potential to be very user-visible. And yes, in the open-source project, using an "every change from every committer needing an independent review" makes it stagnant. You just can't make sure that you have enough volunteer reviewers - or you need a budget for paid reviewers. (Yes, I will mark this my reply off-topic again; of course, I won't mark any others' comments off-topic, because - well, indeed, this specific issue will benefit from multiple unrelated comments claiming something like "This, in a nutshell, encapsulates all that is wrong with FOSS". I'm looking specifically at comment 47.)
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
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
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.
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.
FTR: https://lists.freedesktop.org/archives/libreoffice/2021-October/087911.html
(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.
Created attachment 175775 [details] attached file contains 5000+ entries, Autocomplete works fine in 7.1.6 but DOES NOT even in 7.2.2 attached file contains 5000+ entries, Autocomplete works fine in 7.1.6 but DOES NOT even in 7.2.2 Autocomplete works in 7.2.2 when entries ARE LESS but when in thousands it DOESN'T work I have checked in both Linux (Ubuntu 21.10) and Win10 x64
Just tried LibreOffice version 7.2.2.2 Calc is not behaving the same as with version 7.4.1.2 so I am back to that version. I have a sheet with a data entries area (A1:F807), all cells are bordered in this range. The first row is labels. Columns A (Date), B (Type) and F (Unit Cost) always get an entries. Column C (Description), D (Cost) and E (Qty) will be empty if there is nothing to enter for a given date. Column F is filled to row 807 with a formula. B809:B817 contain unique data entry possibilities for this column. C809:C954 contain unique data entry possibilities for this column. No borders here. New entries are sometimes added with data entry. The unique list is created from the previous years sheet. Last column with data is row 801, A has Date, B has Type, C, D, E are empty, F is 0. Next entry row is 802. In cell A802 the date is entered. In cell B802 the Type "Food" is entered. Now for cell C802 Example #1 Data entry possibilities: Sarsi 330ml can Sky Flakes SM Apple SM Beer SM Light Smoked Ham Smoked Sausage Hoffy Soda Water 330ml can Soup, Chicken Noodle Soup, Chicken w/Rice can Soup, Cream of Mushroom Soup, Tomato Spaghetti Sprite 330ml can I want to enter "SM Light" in cell C802 With 7.4.1.2 the sequence is like this: "S" suggest "Sarsi 330ml can" "SM" suggest "SM Apple" "SM " suggest "SM Apple" "SM L" suggest "SM Light" This is what I want, Tab to D802 done with C802 With 7.2.2.2 the sequence is like this: "S" suggest nothing "SM" suggest nothing "SM " suggest nothing "SM L" suggest "SM Light" Example #2: Data entry possibilities: Jack Daniels 1L Jack Daniels 700ml Johnny Walker Black 1L Johnny Walker Red 1.75L Johnny Walker Red 1L Johnsonville Cheddar Johnsonville Cheddar Brat Johnsonville Garlic Johnsonville Garlic Brat Johnsonville Hot & Spicy Johnsonville Hot & Spicy Brat Johnsonville Smoked Jose Cuervo 1L Jose Cuervo 700ml I want to enter "Johnsonville Cheddar" in cell C802. With 7.1.4.2, the sequence is like this "J" suggest "Jack Daniels 1L" "Jo" suggest "Johnny Walker Black 1L" "Joh" suggest "Johnny Walker Black 1L" "John" suggest "Johnny Walker Black 1L" "Johns" suggest "Johnsonville Cheddar" This is what I want, Tab to D802 done with C802 With 7.2.2.2 the sequence is like this: "J" suggest nothing "Jo" suggest nothing "Joh" suggest nothing "John" suggest nothing "Johns" suggest nothing ... "Johnsonville Cheddar" suggest nothing Well this IS what I want, Tab to D802 done with C802, hope I got it spelled right and it is the same as the other "Johnsonville Cheddar" entries. "Johnsonville Cheddar " suggest "Johnsonville Cheddar Brat" Example #3 Data entry possibilities: Red Bull Red Horse Stallion 500ml Rice Root Beer, Mug 330ml can Root Beer, Zesto 330ml can Round Neck T-Shirt 2XL Round Neck T-Shirt 3XL Round Neck T-Shirt 4XL Round Neck T-Shirt L Round Neck T-Shirt M Round Neck T-Shirt S Round Neck T-Shirt XL Royal 330ml can I want to enter "Round Neck T-Shirt L" in cell C802 With 7.1.4.2, the sequence is like this: "R" suggest Red Bull "Ro" suggest "Root Beer, Mug 330ml can" "Rou" suggest "Round Neck T-Shirt 2XL" The is close to what I want. F2 to edit "Round Neck T-Shirt 2XL" back space x 3, type "L" Now suggestion is "Round Neck T-Shirt L" This IS what I want, Tab to D802 done with C802 with 7.2.2.2 the sequence is lie this. "R" suggest suggest nothing "Ro" suggest suggest nothing "Rou" suggest suggest nothing ... "Round Neck T-Shirt" suggest nothing "Round Neck T-Shirt " suggest nothing "Round Neck T-Shirt L" suggest nothing Well this IS what I want, Tab to D802 done with C802, hope I got it spelled right. and it is the same as the other entries. This new behavior leads to mistakes in data entry, less consistency in data entry and more typing. There are things that Calc does better than "its other popular alternatives". I prefer Calc because of this. The old auto-complete behavior was one of those. This change was NOT a "user experience improvement". I have many spreadsheets that take advantage of the pre 7.2 behavior (feature). It makes for a lot more work. I do not understand why Calc must behave the same as other popular alternatives. Want Calc to behave like X, then use X, not Calc. Please reverse this "bug" back to the way it was before 7.2.
IIUC, ESC opted to revert changes in 7.2 and continue in 7.3.
Does not work in any way in Mac OS 10.13 High Sierra with LO 7.2.1 or 7.2.2 No suggestions in AutoInput. Option+Keydown shows all entries, not the ones with the given chars.
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.
(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.
(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.
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
(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
(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
(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
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".
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).
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
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
(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?
*** Bug 152936 has been marked as a duplicate of this bug. ***
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!