Created attachment 203376 [details] File for testing The sort dialog (Data > Sort) has the checkbox `Include boundary row(s)/columns() containing only comments` on tab `Options`. Its label and descriptions are insufficient. This feature has been introduced with fix for bug 100517. The idea is, that if LibreOffice auto-detects the to be sorted range then the sort dialog allows to include cells, that only contain comments. That is, if your data is in column A and column B has only comments on empty cells and nothing else, the setting allows to include these comments in sorting. The setting tells LibreOffice to include the empty comment cell into the to be sorted data record. I have attached a document where you can play around with this feature. Problems: If you sort rows (which is the default), then the label is `Include boundary row(s) containing only comments`. That is wrong. The feature is not about rows with empty cells but about an adjacent column with comments on empty cells. Thus it needs to be `Include boundary columns(s) containing only comments`. The help has the correct row/column use. You can test it on Sheet2 (sort descending). If a user thinks, that it is about rows with empty cells, then he will notice, that empty cells are always sorted at the end and comments will be moved or not moved, but in any case that it is useless. You can test it on Sheet1 (sort descending). The wording "boundary" is not clear, see bug 168687. There is no normal tooltip for this checkbox and the extended tooltip is "Sets additional sorting options", a generic tooltip that is used for other options as well. The extended tooltip needs to be specific. The help has the text "Range boundary columns (for sorting rows) or boundary rows (for sorting columns) of a sorting range are not sorted by default if they are empty." That does not really catch the problem. If they belonged to the sorting range, then they would be sorted. But LibreOffice makes an automatic "shrink sorting range to data" and that reduces the sorting range even if you have selected that area before calling the Sort dialog.
(In reply to Regina Henschel from comment #0) > That is, if your data is in column A and column B has only comments on empty > cells and nothing else, the setting allows to include these comments in > sorting. Oh, wow, that is _totally_ not what the label and the documentation say this should do. My assumption - reading the label and the documentation - was that this option regarded the behavior of the "shrink sort range to data" functionality; but it seems that is really not the case. But this takes me ever deeper down the rabbit hole: When comments are also accounted for in sorting - where are they to be placed? What is their order relative to empty cells with no comments? Non-empty cells? And what about their order relative to each other? Is the comment text to be taken into account somehow? And if there is no clear ordering in the cases I mentioned above - are the results even stable? These may be moot poins when there are additional columns with contents, but when sorted rows have other strong ordering due to other columns, e.g. in a one-column case, they do need answers...
Created attachment 203422 [details] Effect of different sort options and range choices on sorting range with comments Here is how LO orders ranges with empty cells at range start and range end, with comments and without them, with the "Include empty cells with comments" both checked and unchecked.
Change of the labels in the Sort dialog is in https://gerrit.libreoffice.org/c/core/+/193576
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de01d6f6e5637726e99273f257df348118643cb3 tdf#168905 If sort by row, include affects columns It will be available in 26.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.
The wrong label in the dialog is fixed now. But the problem of missing tooltips and the request for improvements in the help texts remain. I change the Component to Documentation and mark the bug report as enhancement request.
Help page was updated with https://gerrit.libreoffice.org/c/help/+/193499 for bug#168917 Please verify in https://help.libreoffice.org/master/en-US/text/scalc/01/12030200.html?DbPAR=CALC#bm_id3147228
(In reply to Olivier Hallot from comment #6) > Please verify in > https://help.libreoffice.org/master/en-US/text/scalc/01/12030200. > html?DbPAR=CALC#bm_id3147228 The "Natural Sort" part is OK. The "Boundary " parts are still problematic. The text is now, "Range boundary columns (for sorting rows) or boundary rows (for sorting columns) of a sorting range are not sorted by default if they are empty." For users a cell, that has an image or shape anchored to the cell or has a comment, is not "empty". Thus "empty" needs to be more precise. `Not sorted by default` does not really describe the problem. The user wants the columns to be sorted. Therefore he marks the cell range so, that these columns are marked too and then he expects, that they are sorted together with the other cells of a record. The user has no information, which area is actually affected by sorting (see also bug 132521). BTW, do you have noticed, that if there is a cell in such "empty" column, that has a background set (and `Include formats` is checked and column is included in the marked cell range), that then it is moved together with the records even if options `Include boundary...` are not selected? Wrong: Section `Range contains row/column labels` does not belong to tab "Options" but to tab "Sort Criteria". It was changed in bug 131155. And same for section `Direction`. See also the similar problem for the `Sort criteria` tab, bug 168961. Wrong: `Copy sort results to` Copies the sorted list to the cell range that you specify. Not the sorted list is copied, but the original unsorted list is copied to the target location and then the target range is sorted "in-place". You can see in the Undo stack that this process order is used. This process order might become important if your original unsorted list contains formulas, because a copy of a range adapts relative addresses in formulas. Do you want a new bug report or do you will handle the problems here?