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

Previous Next

Full log

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.

Previous Next

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