Created attachment 156977 [details] Arrow shown for "more text available" There is an ### indication that usually (*) means "cell is not wide enough to show the content" [1]. E.g., a datetime with format like `YYYY-MM-DD"T"HH:MM:SS` typically does not fit into the default column width. However, there are lots of questions "I see ### instead of something; how to fix?" [2] - which shows it's not always clear to novice users. We have another indication that content doesn't fit - for *text* values: e.g., put a long string into a cell which isn't allowed to wrap text, and put something to the neighbour cell to disallow the text to continue to the right empty cell; see the small red arrow (see screenshot). The proposal is to add the red arrow *also* to the ### indication, which would hopefully make the indication more intuitive, suggesting "widen me to see it full". * there are cases when this indication is produced for other cases, which should be a bug - irrelevant to the discussed issue [1] https://help.libreoffice.org/6.4/en-US/text/scalc/05/02140000.html [2] https://www.google.com/search?q=%22%23%23%23%22+site%3Aask.libreoffice.org
I believe the relevant code is in sc/source/ui/view/output2.cxx, in ScDrawStringsVars::SetHashText, ScOutputData::ShowClipMarks, and also in different places over that file commented like "No clip marks if "###" doesn't fit".
... and in ScOutputData::DrawClipMarks() in sc/source/ui/view/output2.cxx which is the actual function that outputs the arrows
+1, there are lot of questions in Ask and other forums about this.
+1 to the additional indicator. Just out of curiosity: While reading I wonder why we and everyone else don't take ellipsis commonly used to indicate shortened content. "1.23...", "2020-01-09 12:..." vs "######".
It would be misleading, displaying 123456789 as 123… is not any more helpful than ###, which can be spotted easier.
Created attachment 157068 [details] Sample formats Hi Eike I don't dislike at all Heiko proposal. In addition to the arrow, maybe could be more clear the width issue, and also visible on printing, with formats like: 123456789 "123…" -- #123…# -- «123…» -- <123…> -- [123…] -- ¦123…¦ 10/01/2020 12:34:56 "10/01/2020 12:…" -- #10/01/2020 12:…# -- «10/01/2020 12:…» -- <10/01/2020 12:…> -- [10/01/2020 12:…] -- ¦10/01/2020 12:…¦ for me, as quotes are used with text, between them, I think it does more clear for numbers the width issue, even the # is clear also for those that we are used to the classic ###. I think it has a great advantage, seeing a relevant part of the value, can avoid many times to resize the column width, e.g. you can see there are expected values. And even can be used on purpose as another "kind" of format.
Also relevant for implementing this: grep for VOPT_CLIPMARKS (the setting under Options->Calc->View->Display->Text overflow).
(In reply to Mike Kaganski from comment #7) > Options->Calc->View->Display->Text overflow "If a cell contains text that is wider than the width of the cell, the text is displayed over empty neighboring cells in the same row. If there is no empty neighboring cell, a small triangle at the cell border indicates that the text continues." Shows the triangle for text if the option is on or just nothing if off. Misleading caption and help.
I want to add that I just wasted hours trying to figure what ### means. I had a field which was a sum of another set of fields. After entering some values in the the fields it was sum() over, the sum field changed to ###. I assumed that I had copy-pasted some non-numeric unicode characters, so I tried re-entering the values manually. Same problem. I then opened the document in the google docs and it worked fine. So I assumed that libreoffice calc must be broken. Google docs showed part of the value followed by ... so I widened the column. Then I re-opened the document in calc and, behold, it worked! So I had to reverse-engineer what ### means. Please can we get rid of this ###. Noone uses ###. The standard symbol for omission is the ellipsis (...).
No further input from UX needed. Hope Mike's code pointer are sufficient to implement it. Likely not a task for beginners. Could imagine comment 6 or 4 as an option but the basic task is to show the triangle.
This seems to be a gerrit patch for this issue: https://gerrit.libreoffice.org/c/core/+/150703
(In reply to Tomaz Vajngerl from comment #11) > This seems to be a gerrit patch for this issue: > https://gerrit.libreoffice.org/c/core/+/150703 Indeed, so let's keep the correct status and assignee
anfanite396 committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d2380516ac9871743c5a5455f0734d02be8eade tdf#129847 Show "more content" red arrow along with ### indication It will be available in 24.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 bug wasn't fixed? why the status is NEW again?
It was likely some confusion about the workflow. Let's close.
(In reply to Roman Kuznetsov from comment #14) > the bug wasn't fixed? why the status is NEW again? The patch was initiated by anfanite396 but finished by Hossein, so the ASSIGNEE field was changed. ATM, Hossein is not CC'ed in this bug 129847. FWIW, ATM there are no new Dev builds to test this under Linux nor Windows. I would also suggest adding bug 155886 to the See also field.