After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 165061 - sort of a column leaves first entry untouched in certain instances
sort of a column leaves first entry untouched in certain instances
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2005-01-24 07:01 UTC by kay_jay
Modified: 2005-06-05 00:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description kay_jay 2005-01-24 07:01:17 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.
Comment 1 Andreas J. Guelzow 2005-01-24 16:37:56 UTC
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.
Comment 2 kay_jay 2005-01-24 22:42:42 UTC
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!  :)

Comment 3 Andreas J. Guelzow 2005-01-25 23:28:25 UTC
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.
Comment 4 Jody Goldberg 2005-05-29 05:25:07 UTC
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.
Comment 5 Jody Goldberg 2005-06-05 00:15:25 UTC
After more consideration I've decided to leave this enabled.  The new semantics
are smart enough to be right most of the time.