I'm not for change the behavior, it is right as it is.
The change breaks the way it works now, perhaps used on purpose.

(In reply to m_a_riosv from comment #1)
> I'm not for change the behavior, it is right as it is.
> The change breaks the way it works now, perhaps used on purpose.

Can you clarify that please?

If you mean hidden columns are used to force text clipping in cells instead of overflowing, that's a dubious practice, and LibreCalc should have a "Clip" option under Format Cells -> Alignment -> Properties.

(In reply to Dan Dascalescu from comment #2)

> If you mean hidden columns are used to force text clipping in cells instead
> of overflowing, that's a dubious practice

Why is that dubious? Are you saying that other spreadsheet tools have been doing it differently during the last 3 decades? Please clarify by sharing examples of such tools (with versions please).


>  LibreCalc should have a
> "Clip" option under Format Cells -> Alignment -> Properties.

@Dan,

While I think your request is worth a discussion, let's not mix things. Your request is about a visual behavior, but it is not really an alignment setting for the cell.

It is still possible that some other spreadsheet tool has this kind of setting and that it calls this an "alignment" alternative. It would be helpful to have specific examples of such tools.

The cell could be, say, centered, and still have some kind of overflow, exactly as you described.

Moreover, if a "clipped" overflow would be some kind of cell attribute, what would be the possible other ("non-clipped") settings? Depending on alignment and content, you could have clipped overflow on one side of the cell, or the other, or both, or none (and for each case, we have several possible alignments).

Now, assuming this kind of visual re-fresh would happen as you request, I would be concerned about its performance consequences. Changing one cell (or an entire column, as you described in comment 0) would affect another column (not only the adjacent ones), even when the affected columns would have unrelated content (e.g. formulas that don't relate these columns in any way). That sounds similar to volatile formulas, and such scenario is expensive (i.e. can have negative performance consequences).

To sum up: worth a discussion; not yet convinced; visual behavior; not necessarily an alignment setting (but related in its influence on the visual result); an example of some other spreadsheet tool with this behavior/setting would help.

Perhaps this should not be an "automatic" reaction. A manual setting could possibly achieve the visual effect, meaning "do not clip" (whichever the potential normal clipping would be in each case), and instead, leave the content to overflow.

IOW, a setting to disable the clip, for each cell. This visual setting would not be reactive, depending on the content of the adjacent cells, but rather an ON/OFF toggle. I am not sure whether there would be some potential third alternative (and based on what? Based on the adjacent cell being empty?).

By avoiding the "automatic" part of the request, the reaction would not be (so) "volatile".

FWIW, Google Sheets has 3 "wrap text" settings for each cell:

* The usual wrap text that we know in Calc and other spreadsheet tools.
* Clip.
* Text overflow.

I have not been able to reproduce the request from comment 0 with any of these 3 settings in GSheets. They only react differently when the adjacent cell is empty.

Additionally, these 3 wrapping options are independent of the alignment for the cell, at least in terms of the available icons in the toolbar. I have not tested each possible combination to see their respective results.

The requested change is how Excel behaves. A long string in A1 is cut off with some text in B1 but will be shown anyway if B becomes hidden. It's independent from alignment settings (except Fill, which always cuts off at the cell border).

I see no good reason to not do it.

(In reply to Heiko Tietze from comment #6)
> I see no good reason to not do it.

What about the potential performance loss, as I mentioned in prior comments? Calc would need to "listen" to such changes in other columns, and the resulting rendering of text would change according to the hide/show status of adjacent columns, and also according to content of the visually-adjacent columns (from both sides, depending on alignment). This is the effect similar to having "volatile" formulas I would be worried about.

Thank you Heiko for confirming what to me seemed obvious.

I'm not familiar with the implementation details, but `Calc would need to "listen" to such changes in other columns` suggests an ongoing process. Columns are hidden once, and then rarely displayed again. If hiding takes a noticeable amount of time, I think that's quite acceptable because it's the direct result of a user action impacting an entire column. Is it that what you're worried about @ady?

(In reply to Dan Dascalescu from comment #8)
> Thank you Heiko for confirming what to me seemed obvious.
> 
> I'm not familiar with the implementation details, but `Calc would need to
> "listen" to such changes in other columns` suggests an ongoing process.
> Columns are hidden once, and then rarely displayed again. If hiding takes a
> noticeable amount of time, I think that's quite acceptable because it's the
> direct result of a user action impacting an entire column. Is it that what
> you're worried about @ady?

Whether one user claims it is a one-time thing, or instead a frequent action, is not relevant, as each user has its own needs and workflow. Assuming the frequency of this kind of action would be a mistake. And then we also have the amount of rows to consider too.

It is not an ongoing process. Just as with volatile functions (which are "expensive"), every time you change either the content or the width or the show/hide status of a cell (or range of cells/columns), the visually-adjacent columns would/might need an adjustment (on both sides).

IOW, when you change one cell/column, more items (in comparison to the current situation) in your spreadsheet would have to pay attention to what happens, and then react accordingly.

This is why I said that having this react _automatically_ is not the same as having the user acting on a setting _manually_. This is similar to how the normal "wrap text" attribute acts: it is a _manual_ _one-time_ reaction to activating the "wrap text" property, and not an automatic permanent reaction according to all-and-every-single change surrounding the cell, nor according to the same cell either.

I would be in favor of adding different settings to the "wrap text" mode (see GSheets), but I am not convinced (yet) that an automatic permanent change according to the surrounding changes is so desirable. Unfortunately, I have no way to test on Excel these days in order to compare with it.

I am not a developer, so I have no way to know how much actual performance impact this change would have, in case it gets implemented as an automatic permanent revision of what happens around a cell/column. I am only pointing out that there will be some kind of impact; it is not free.

Now let's leave this matter to actual discussion between (UX and other) developers, until they come up with a decision.

I've a developer (though not an LO developer).

Yes, when a column is shown or hidden, the visibility of the cells to the next of it needs to be recalculated. The same recalculation happens when a column is deleted. Clearly the performance impact there is minor (I have never seen it in practice, and I've reported plenty of bugs (https://bugs.documentfoundation.org/buglist.cgi?email1=dascalescu&emailreporter1=1&emailtype1=substring&list_id=1702597&order=changeddate%20DESC%2C), including very subtle performance once (e.g. #131859).

I think the main issue about changing the behavior is the modification of the display for existing documents, without any warning to the user.

IMO, the possible performance problems are surely solvable, because it seems that the cases where you need to modify the display are limited to show hide column(s).

Perhaps it could be a concern, if the cells of the hidden columns were massively modified by macro.

(In reply to m_a_riosv from comment #11)
> I think the main issue about changing the behavior is the modification of
> the display for existing documents, without any warning to the user.

The default behavior and setting should still be the same as has been for 3 decades. Older spreadsheets should look the same (unless manually changing the setting/behavior and re-saving).

In addition, compatibility with other spreadsheet tools (that might or might not support such new attribute) is also relevant.

ATM we don't even know whether ODF can support such "wrap text modes".

I support the request change as per the bug title, because:

1. Hidden should mean hidden, i.e. the sheet presents as though the column did not exist. Otherwise it's effectively width-0.

2. Like Heiko mentioned in comment #6, MSO parity

I am not worried about breakage, for two reasons:

1. Whoever uses hidden columns must expect users to sometimes unhide the columns, and plan for how their sheet will display when that happens.

2. Whoever uses hidden columns should expect the file to also work in MS Excel, where the behavior is different.

3. One can achieve the width-0 before with a literal width-0, non-hidden, column, so the breakage can be rectified relatively easily.

Created attachment 193204 [details]
Calc document exhibiting the bug - column B is hidden

This document is the result of following the reproduction instructions in the opening comment.

Hi Miguel,
(In reply to m_a_riosv from comment #11)
> I think the main issue about changing the behavior is the modification of
> the display for existing documents, without any warning to the user.
Personally I would not mind if the behavior changes from 

    A   C    D
  ###|    | <foo> |
     |    |       |
to

    A   C    D
  applepie| <foo> |
     |    |       |
Honestly I think I would have avoided such a situation to exist.
If we have no indication of serious problems, I would suggest changing is useful.

We discussed the topic in the design meeting and welcome the suggestion.

Based on the discussion here it might be the best to make the new feature optionally. Having this option as compatibility flag makes it a bit hard to find, but on the other hand clutters the tab as view option.

(In reply to Heiko Tietze from comment #16)
> Based on the discussion here it might be the best to make the new feature
> optionally. Having this option as compatibility flag makes it a bit hard to
> find, but on the other hand clutters the tab as view option.

I'm not sure this is a "View" item. As in GSheets, this is one variant/mode on Wrap Text cell format (Format > (cell) Wrapping > overflow/wrap/clip).

A note on GSheets: the behavior of the "Overflow" variant in GSheets seems to be what is requested in this report; the "Clip" variant makes the text always clipped within the cell size (with or without having content on adjacent cells).

So, in terms of compatibility (also back-compatibility with older Calc versions), Calc _might_ need 4 variants, the 4th being the current behavior (i.e. clip when the adjacent cell is not blank empty).


BTW, generally speaking, items in the "View" menu were not supposed to be part of the document itself (i.e. not saved to the document), but rather they were supposed to affect the way the spreadsheet is seen on the specific system. Unfortunately, this has been modified more than once, and now some items in the View menu are saved to the document itself.

Example: Hiding a column is located under the Format menu (hence, saved to the document), not in View.


I hope someone in the UX Team will make explicitly clear (here in the report) whether this new _format_ item (which is a variant/mode of Wrap Text, as in GSheets), is expected to be saved to the document itself (resulting in the same cell _format_ on other systems), or instead this is supposed to be just some kind of presentation/rendering/viewing/display modification, not to be saved on the document.

(In reply to ady from comment #17)
> in GSheets, this is one variant/mode on Wrap Text cell format...
And yet the recommendation is to have it either on as Excel does or off as we do so far.

(In reply to Heiko Tietze from comment #18)
> (In reply to ady from comment #17)
> > in GSheets, this is one variant/mode on Wrap Text cell format...
> And yet the recommendation is to have it either on as Excel does or off as
> we do so far.

Are you saying that Excel has a different behavior than GSheets when setting the relevant Wrapping mode?

Also, please address the matter of Format vs View. Adding this to View will lead to confusion.