GNOME Bugzilla – Bug 165061
sort of a column leaves first entry untouched in certain instances
Last modified: 2005-06-05 00:15:25 UTC
Copy a column of text (unsorted names, in my case) out of a list in which the cells have been formatted with borders all around. It seems that the top cell being copied must either border another cell above it which has a heavy frame about that cell, or it itself must have a heavy border. Paste into a new space, then sort using the A->Z button. If the topmost name _should_ move, it doesn't. Trying this with a simple numeric list seems to give the same results. If the heavy border is replaced with a normal border at that point, the effect lasts. If the border is removed, the effect disappears.
I believe this is a feature, not a bug. If you use the sort dialog (via data->sort) the behaviour will be as you expect. You will note that you could select that the selection has a header. If you do that header (first cell) will not be sorted. If you use the buttons on the toolbar, gnumeric tries to test whether there is a header or not. The bold border indicates that there likely is a header.
Hmmm. I don't see this automatic detection as a desirable feature, then. I was quite unaware of that capability in the first place (sorting while ignoring headers), and wouldn't want it unless I specifically were working with such information. I'd be curious to know the statistical likelihood of having a number as a header for a bunch of numbers... Also, I point out that the original cell highlighted in bold was _above_ the one copied, The copy came in with no top border rather than anything bold. The distinction being made by gnumeric is whether the borders are different, not bold vs. normal. An "open top" apparently makes it a likely header. ?? I suggest to the developers that options such as this be turned off by default. People who live and die using them should be aware of/expect their availability, and be able to turn them on for defaults. One might envision a small configuration tool which had a page full of these "hidden" features for exactly that purpose. In this way, those of us closer to catastrophic ignorance won't get blindsided. Thanks for the information, Andreas! :)
I am one of the developers and agree with you. Until your bug report I wasn't aware of this feature either. Unfortunately, there is probably some reason or request for it.
I can see the problem. We were using saying that style_A != style_B => a is a header. This is too strong a condition. I've written a weaker version for 1.5.2 that is more reasonable. However, it's still possible to fake it out by assigning a top border to B rather than a bottom to A. I tend to agree with you that we should disable the feature. The potential trouble is larger than the benefits. However, it would violate XL finger feel. Please post to the list and let's get some feedback. It's a close call.
After more consideration I've decided to leave this enabled. The new semantics are smart enough to be right most of the time.