bug#6933: 24.0.50; fringe-mode value of `half' is broken

bug#6933: 24.0.50; fringe-mode value of `half' is broken

[Drew Adams]

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'
 

bug#6933: 24.0.50; fringe-mode value of `half' is broken

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@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.

bug#6933: 24.0.50; fringe-mode value of `half' is broken

[Drew Adams]

> > 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.

bug#6933: 24.0.50; fringe-mode value of `half' is broken

[Chong Yidong]

Eli Zaretskii <eliz@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.

bug#6933: 24.0.50; fringe-mode value of `half' is broken

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Drew Adams <drew.adams@oracle.com>, 6933@debbugs.gnu.org
> Date: Sat, 04 Sep 2010 14:34:47 -0400
> 
> Eli Zaretskii <eliz@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).

bug#6933: 24.0.50; fringe-mode value of `half' is broken

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6933-done@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.