Bug 129847 - ### indication of "cell too narrow" should additionally show "more content" red arrow
Summary: ### indication of "cell too narrow" should additionally show "more content" r...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Hardware: All All
: medium enhancement
Assignee: Not Assigned
Whiteboard: target:24.2.0
Keywords: difficultyInteresting, easyHack, skillCpp, topicUI
Depends on:
Blocks: Calc-UX
  Show dependency treegraph
Reported: 2020-01-07 07:37 UTC by Mike Kaganski
Modified: 2023-07-13 08:18 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Arrow shown for "more text available" (1.57 KB, image/png)
2020-01-07 07:37 UTC, Mike Kaganski
Sample formats (13.91 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-01-10 16:17 UTC, m_a_riosv

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-01-07 07:37:19 UTC
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
Comment 1 Mike Kaganski 2020-01-07 08:04:05 UTC
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".
Comment 2 Mike Kaganski 2020-01-07 08:25:56 UTC
... and in ScOutputData::DrawClipMarks() in sc/source/ui/view/output2.cxx which is the actual function that outputs the arrows
Comment 3 m_a_riosv 2020-01-07 22:25:58 UTC
+1, there are lot of questions in Ask and other forums about this.
Comment 4 Heiko Tietze 2020-01-09 11:06:49 UTC
+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 "######".
Comment 5 Eike Rathke 2020-01-10 14:07:33 UTC
It would be misleading, displaying 123456789 as 123… is not any more helpful than ###, which can be spotted easier.
Comment 6 m_a_riosv 2020-01-10 16:17:03 UTC
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.
Comment 7 Mike Kaganski 2020-01-15 06:23:22 UTC
Also relevant for implementing this: grep for VOPT_CLIPMARKS (the setting under Options->Calc->View->Display->Text overflow).
Comment 8 Heiko Tietze 2020-01-15 13:20:19 UTC
(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.
Comment 9 Sean Young 2020-04-08 09:37:10 UTC
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 (...).
Comment 10 Heiko Tietze 2021-05-18 10:52:12 UTC
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.
Comment 11 Tomaz Vajngerl 2023-05-06 01:58:52 UTC
This seems to be a gerrit patch for this issue: https://gerrit.libreoffice.org/c/core/+/150703
Comment 12 Buovjaga 2023-05-06 08:46:10 UTC
(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
Comment 13 Commit Notification 2023-07-06 09:19:36 UTC
anfanite396 committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 14 Roman Kuznetsov 2023-07-08 18:06:02 UTC
the bug wasn't fixed? why the status is NEW again?
Comment 15 Buovjaga 2023-07-09 07:52:38 UTC
It was likely some confusion about the workflow. Let's close.
Comment 16 ady 2023-07-09 08:32:18 UTC
(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.