Re: Customize fringe widths

[Eli Zaretskii]

On 19 Nov 2001, Kim F. Storm wrote:

> Here is the preliminary documentation string for x-set-fringes:
> 
>   x-set-fringes is a built-in function.
>   (x-set-fringes FRAME &optional LEFT-WIDTH RIGHT-WIDTH)

First, I suggest the name x-set-fringe, since we don't actually use
the plural form of `fringe' anywhere, but instead mean `fringe' to
mean both the left and right area.  Maybe even x-set-fringe-width.

More importantly, I'd like to suggest a policy of not inventing new
functions that are supposed to be called by Lisp programs and whose
name begins with "x-", unless they are truly X-specific.  It bothers
me to read Windows or Mac sources which define x-do-something
functions.  Let's reserve the x-* names for internal functions with
X-specific guts.

(This is a design decision, so please wait for Richard to comment on
that; I don't think this was ever discussed before, it's just my
opinion.)

>   Set the width of fringes for FRAME.
>   FRAME nil means use the selected frame.
>   The optional LEFT-WIDTH argument specifies the width of the left fringe.
>   The optional RIGHT-WIDTH argument specifies the width of the right fringe.

Please specify the units of WIDTH, and please take into account that
some day character terminals may wish to implement the fringe.

>   The actual size of the fringes is adjusted so that together, they occupy an
>   integral number of columns.

Why not use whatever the arguments specify?  That way, you won't
surprise the caller.

> 1) If the fringe width is less than the width of the bitmap, should
> the bitmap be clipped, or should the fringe width be adjusted to be
> able to hold the widest bitmap?

We should clip the bitmaps, IMHO.  Just doing what the caller said is
normally the best policy, unless it's somehow impossible or very hard.

> 2) If I set the width of a fringe to zero, the corresponding
> truncation/continuation glyphs are not shown.
> 
> It might be sensible to fall back to using the 20.x truncation glyphs,
> but this doesn't seem to be so simple, as the code for X seems to
> implicitly assume the existence of the fringes.
> 
> However, it could also be argued that if the fringes are explicitly
> removed, then the truncation/continuation information simply isn't
> visible.

I think the fringe width (and its effect on the bitmaps displayed
there) and the old method of displaying the truncation/continuation
glyphs should be two independent features.  In other words, if they
specified zero-width fringe, don't show the glyphs.

> 3) It actually looks more sensible to adjust the fringe widths (and
> perhaps the bitmaps) on a per-buffer basis, rather than per-frame.
> 
> But there are many other things which should be per-buffer rather than
> per-frame, so this should probably wait until we know how to fix this
> in general.

Right.  Currently, lots of things in frame's param_alist might benefit
from being buffer-local (e.g., faces), but, if we decide to do that,
it should be part of redesigning the whole thing, not just a
fringe-specific feature.

> 4) As is the case for most of the code for X in xterm and xfns, there
> is almost identical code for w32 and mac.
> 
> If I change this for X, is it assumed that I will also make the same
> changes for w32 and mac (which I cannot test), or can I depend on the
> maintainers of the w32 and mac ports to 'pick up the pieces' ?

It's better to change the other platforms' code as well.  Just give
the maintainers a heads-up when you commit the changes, to alert them
to potential breakage.  (Testing the changes on those two platforms
before committing is even nicer, but that's not a requirement.)

> 5) If the left fringe is removed, it is easy to show the 'empty line
> indicator' in the right fringe.  I already tried this, and it looks ok.

Again, I think this should be a separate feature.