GNU bug report logs - #6933
24.0.50; fringe-mode value of `half' is broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6933 in the body.
You can then email your comments to 6933 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; fringe-mode value of `half' is broken
Date: Fri, 27 Aug 2010 17:16:26 -0700

emacs -Q
 
M-x fringe-mode
Enter `half'.
 
The fringe values (both left and right) should each be 5, according to
the code and comments.  Instead, it is still 8, as shown by
(frame-parameters).  There is no difference in behavior between `half'
and `default'.  Dunno whether this is Windows-specific.

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-08-16 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
 

Message #8 received at 6933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 6933 <at> debbugs.gnu.org
Subject: Re: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Sat, 28 Aug 2010 11:45:36 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Fri, 27 Aug 2010 17:16:26 -0700
> 
> emacs -Q
>  
> M-x fringe-mode
> Enter `half'.
>  
> The fringe values (both left and right) should each be 5, according to
> the code and comments.  Instead, it is still 8, as shown by
> (frame-parameters).  There is no difference in behavior between `half'
> and `default'.  Dunno whether this is Windows-specific.

This happens because fringe.el has this customization form for "half"
in the defcustom for fringe-mode:

		 (const :tag "Half width" (5 . 5))

And the doc string for fringe-mode says this, among the rest:

                               This command may round up the left and
    right width specifications to ensure that their sum is a multiple
    of the character width of a frame.

So 5 is rounded up to 8, and the rest is history.

I don't know why the values are 5 instead of 4.  The default fringe
width is 8 on all GUI displays, so half of that should have been 4,
not 5.  Maybe I'm missing some subtlety here.

Can someone please check on X whether (fringe-mode '(4 . 4)) does TRT?
If it does, I think we should use 4 instead of 5 in the above
defcustom.

Message #11 received at 6933 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 6933 <at> debbugs.gnu.org
Subject: RE: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Sat, 28 Aug 2010 08:15:29 -0700

> > emacs -Q
> >  
> > M-x fringe-mode
> > Enter `half'.
> >  
> > The fringe values (both left and right) should each be 5, 
> > according to the code and comments.  Instead, it is still 8,
> > as shown by (frame-parameters).  There is no difference in behavior 
> > between `half' and `default'.  Dunno whether this is Windows-specific.
> 
> This happens because fringe.el has this customization form for "half"
> in the defcustom for fringe-mode:
> 
> 		 (const :tag "Half width" (5 . 5))
> 
> And the doc string for fringe-mode says this, among the rest:
> 
>                                This command may round up the left and
>     right width specifications to ensure that their sum is a multiple
>     of the character width of a frame.
> 
> So 5 is rounded up to 8, and the rest is history.
> 
> I don't know why the values are 5 instead of 4.  The default fringe
> width is 8 on all GUI displays, so half of that should have been 4,
> not 5.  Maybe I'm missing some subtlety here.
> 
> Can someone please check on X whether (fringe-mode '(4 . 4)) does TRT?
> If it does, I think we should use 4 instead of 5 in the above
> defcustom.

Thanks.  Default is 8; half is 5, which results in 8 (same as default); and
minimal is 4.  If we have 3 values (choices) and the default is 8, then the
values should ideally give 3 different appearances (effects).  Neither {8,8,4}
and {8,4,4} is a good set.

But since both minimal and half show both left and right fringes, and the sum
must be a multiple of the frame char width (default 8), that doesn't leave a lot
of choice. Presumably, for both minimal and half you want the left and right to
be the same, and 8/2 = 4.

So I guess there is no good solution.  But perhaps this could be better
explained in the doc.  I'd suggest making half be 4, at least, since users
expect it to be less than default (whole) in appearance.  It is less
disconcerting if users see no difference between half and minimal when using the
default frame-char size: "minimal" does not imply less than half, but "half"
implies less than whole (default).

Also, "default" might not be the best term here.  I don't have a great
suggestion, however.  Maybe "full", "whole", or "maximal", but each of those has
its drawbacks too.

Message #14 received at 6933 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6933 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Sat, 04 Sep 2010 14:34:47 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> This happens because fringe.el has this customization form for "half"
> in the defcustom for fringe-mode:
>
> 		 (const :tag "Half width" (5 . 5))
>
> And the doc string for fringe-mode says this, among the rest:
>
>                                This command may round up the left and
>     right width specifications to ensure that their sum is a multiple
>     of the character width of a frame.
>
> So 5 is rounded up to 8, and the rest is history.
>
> I don't know why the values are 5 instead of 4.  The default fringe
> width is 8 on all GUI displays, so half of that should have been 4,
> not 5.  Maybe I'm missing some subtlety here.
>
> Can someone please check on X whether (fringe-mode '(4 . 4)) does TRT?
> If it does, I think we should use 4 instead of 5 in the above
> defcustom.

(4 . 4) seems to work fine for me on X.

Message #19 received at 6933-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 6933-done <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Fri, 17 Sep 2010 23:14:36 +0200

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 6933 <at> debbugs.gnu.org
> Date: Sat, 04 Sep 2010 14:34:47 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > This happens because fringe.el has this customization form for "half"
> > in the defcustom for fringe-mode:
> >
> > 		 (const :tag "Half width" (5 . 5))
> >
> > And the doc string for fringe-mode says this, among the rest:
> >
> >                                This command may round up the left and
> >     right width specifications to ensure that their sum is a multiple
> >     of the character width of a frame.
> >
> > So 5 is rounded up to 8, and the rest is history.
> >
> > I don't know why the values are 5 instead of 4.  The default fringe
> > width is 8 on all GUI displays, so half of that should have been 4,
> > not 5.  Maybe I'm missing some subtlety here.
> >
> > Can someone please check on X whether (fringe-mode '(4 . 4)) does TRT?
> > If it does, I think we should use 4 instead of 5 in the above
> > defcustom.
> 
> (4 . 4) seems to work fine for me on X.

I changed fringe.el to use (4 . 4).  So this bug should be fixed now
(revno 101464).

Message #20 received at 6933-done <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>, "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: 6933-done <at> debbugs.gnu.org
Subject: RE: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Fri, 17 Sep 2010 15:25:59 -0700

> I changed fringe.el to use (4 . 4).  So this bug should be fixed now
> (revno 101464).

What about the confusing name `default' and the doc?

The doc string for the function `fringe-mode' mentions the rounding, but the doc
string for the option (customization) does not mention it.  Users will not
understand what happens - i.e. what has been discussed in this thread.

`default' probably should be renamed.  It is not just a default: `half'
presumably takes its meaning from the meaning of `default'.  I suggested "full",
"whole", or "maximal", but perhaps something even better can be found.  The
clearest doc about the fringe is the Elisp manual, and that refers to this as
the "standard" width. That is better than `default'.

To tell the truth, I'm still not clear on the meaning of default here. On the
one hand, the Elisp manual (but not any of the other fringe doc) says that it
means _whatever width is needed to show the fringe bitmaps_:

"standard fringe width, which is the width needed to display the fringe bitmaps"

That suggests that it is a function of the fringe bitmaps, not a constant width.

And the fact that we use nil for this, instead of just an actual default number
(e.g. 8) would also seem to indicate that it is not a hard-coded number (else
why not use 8?).  Being the size needed to show the fringe bitmaps suggests that
it can vary depending on the available bitmaps (their size).  Is that really
possible, or is it always in fact 8 - in its effect?

And if the effect of a `default' (nil) value can vary that way, then presumably
`half' would always be half of its effective value (modulo any needed rounding).
Is that really the case, or is `half' always 4 (now)?  IOW, if nil makes the
fringe width change if the "fringe bitmaps" change size, then does `half' follow
suit?  (I don't think so.)

But if that is not correct, if in fact both `default' and `half', in their
effect, always produce the same widths (8 and 4), then I do not see why we offer
those symbolic values at all.  In that case, why not just have a single numeric
value that users can customize and whose default value is 8?  (And also of
course allow for left/right only, as is done now.)

You can tell that this is still not clear to me, even after looking at the code
and all of the doc.  That in itself should indicate that at the least the doc is
not so wonderful.  The Elisp manual is clearest here and seems to provide the
info needed for a user in Customize.  If the manual is correct, and if no design
change is in order (e.g. we don't get rid of some of the value-menu
possibilities), then the other doc, in particular the Customize doc, should say
what the Elisp manual says.

But as I say, if `default' and `half' are, in their effect, just hard-coded
numeric widths, then let's get rid of those value-menu and `interactive' spec
choices.  There is no need for a value of nil unless it actually does let the
fringe be different in different contexts (e.g. bitmap size).

And even if `default' does in fact allow for variable fringe size, it seems that
`half' does not in any case.  In that case `half' is not always half of the
standard width (`default'), even when there is no rounding.  My impression,
looking at the code, is that `half' simply means a width of 4 (modulo rounding)
- always, even if nil (`default') might change to handle different size bitmaps
(which also does not seem to be true).

Can we settle this?  First the question about whether `default' (nil) actually
lets the fringe width change depending on the bitmap size - as the Elisp manual
suggests: "the width needed to display the fringe bitmaps".

If the answer to that is no, so that `default' always acts the same as a width
of 8, then let's get rid of `default'.  And even if the answer is yes, what
about `half' - doesn't that always act the same as a value of 4?  If yes, then
let's get rid of `half'.

If both `default' (nil) and `half' (4 . 4) always act the same as 8 and 4, then
let's just let users specify such a numeric value in Customize.  In that case
there is no purpose in offering them also "default" and "half".

But what about the `interactive' spec for `fringe-mode' and `set-fringe-style'?
There we might still allow completion against symbolic choices, as now, and
translate to the underlying values.

But even then I wonder whether we shouldn't just allow as input either (a) an
integer (width), which would take care of `default', `half', and `minimal', or,
say, (b) a number preceded by `l' or `r', which takes care of `left-only' and
`right-only' (and additionally lets the user specify the left/right width,
something they cannot do now except via Customize).

I'm hoping that someone who understands this well reads this and DTRT: either
redesign this, if I'm right in suspecting that it is clunky, or at least clarify
the doc, if I'm wrong and the current design is ideal.

Thx.

Message #27 received at 6933-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 6933-done <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: Re: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Sat, 18 Sep 2010 11:49:04 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <6933-done <at> debbugs.gnu.org>
> Date: Fri, 17 Sep 2010 15:25:59 -0700
> 
> > I changed fringe.el to use (4 . 4).  So this bug should be fixed now
> > (revno 101464).
> 
> What about the confusing name `default' and the doc?

The original bug report was only about the effect of `half'.
Documentation is an unrelated issue.

> The doc string for the function `fringe-mode' mentions the rounding, but the doc
> string for the option (customization) does not mention it.

I added to the doc string of the defcustom a note about rounding.

> `default' probably should be renamed.  It is not just a default: `half'
> presumably takes its meaning from the meaning of `default'.  I suggested "full",
> "whole", or "maximal", but perhaps something even better can be found.  The
> clearest doc about the fringe is the Elisp manual, and that refers to this as
> the "standard" width. That is better than `default'.

I don't see a good reason for renaming the symbolic values.  Doing so
will surely cause back-compatibility issues, so IMO we need a really
good reason for such a change.

> "standard fringe width, which is the width needed to display the fringe bitmaps"
> 
> That suggests that it is a function of the fringe bitmaps, not a constant width.

They are constant for the time being, but may change in the future,
e.g. if we lift the current restriction of the display engine that
limits window width to an integral multiple of the canonical character
size.

> But as I say, if `default' and `half' are, in their effect, just hard-coded
> numeric widths, then let's get rid of those value-menu and `interactive' spec
> choices.  There is no need for a value of nil unless it actually does let the
> fringe be different in different contexts (e.g. bitmap size).

I don't think it's right to fix the choices on specific numbers.
Symbolic values allow us to change the underlying implementation in
the future without hurting compatibility.  The fact that some of the
documentation describes the current implementation is not necessarily
a good reason to remove future extensibility.

> Can we settle this?

Feel free to submit a separate bug report.  I'm not going to do
anything about this at this time, for the reasons stated above.

Message #28 received at 6933-done <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 6933-done <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: RE: bug#6933: 24.0.50; fringe-mode value of `half' is broken
Date: Sat, 18 Sep 2010 07:45:32 -0700

> > What about the confusing name `default' and the doc?
> 
> The original bug report was only about the effect of `half'.
> Documentation is an unrelated issue.

See my second mail for this report which clarifies things.  I specifically
mention problems with the doc and with `default'.

> I don't see a good reason for renaming the symbolic values.

They don't do what they say.  `half' is not necessarily half of `default', even
when one disregards rounding.  `default' itself is a misleading name.  The ELisp
manual calls it "standard", but even that is not great.  Apparently it is the
full width needed to display all fringe bitmaps.  If we kept a symbolic value
for this it should be something like `full'.

> Doing so will surely cause back-compatibility issues,

It is use only in interactive interfaces.

> so IMO we need a really good reason for such a change.
> 
> > "standard fringe width, which is the width needed to 
> > display the fringe bitmaps"
> >
> > That suggests that it is a function of the fringe bitmaps, 
> > not a constant width.
> 
> They are constant for the time being, but may change in the future,
> e.g. if we lift the current restriction of the display engine that
> limits window width to an integral multiple of the canonical character
> size.

We don't name things based on such maybe-one-day-everything-will-be-different
imaginings.  These names have long been giving the wrong impression (years).

> > But as I say, if `default' and `half' are, in their effect, 
> > just hard-coded numeric widths, then let's get rid of those
> > value-menu and `interactive' spec choices.  There is no need for a
> > value of nil unless it actually does let the
> > fringe be different in different contexts (e.g. bitmap size).
> 
> I don't think it's right to fix the choices on specific numbers.
> Symbolic values allow us to change the underlying implementation in
> the future without hurting compatibility.

See above. The choices that users have should reflect the actual behavior, not
some possible future behavior. The only real behaviors possible today and
forever into the past are fixed numeric values for left, right, or both.  The UI
should reflect that faithfully.  It should not be a UI for some imagined
alternative or future world.

> The fact that some of the documentation describes the current
> implementation is not necessarily a good reason to remove future
> extensibility.

The doc and UI should reflect the product's behavior, not some alternative
behavior some developer might be dreaming of.  That's a no-brainer.

> > Can we settle this?
> 
> Feel free to submit a separate bug report.  I'm not going to do
> anything about this at this time, for the reasons stated above.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.