Re: Customize fringe widths

[Kim F. Storm]

Eli Zaretskii <address@hidden> writes:

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

I wasn't aware of that.

Maybe the function should have a left/right parameter and set that
fringe only, e.g.
        (set-fringe-width frame 'left 10)
        (set-fringe-width frame 'right 20)

[at a later time, the FRAME parameter could accept a BUFFER as well].

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

FWIW, I fully agree!


> >   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.
>
Because the existing code explicitly makes an effort to ensure that the
fringe (left+right together) occupies an integral number of columns.

Here is the comment for FRAME_X_FRINGE_COLS from xterm.h:

/* Total width of fringes reserved for drawing truncation bitmaps,
   continuation bitmaps and alike.  The width is in canonical char
   units of the frame.  This must currently be the case because window
   sizes aren't pixel values.  If it weren't the case, we wouldn't be
   able to split windows horizontally nicely.  */


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

I agree, and clipping is definitely the easy thing to do.

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

This is what I have done now.
 
> 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.

Ok, I'll keep it as a frame parameter for now.

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

Ok, will do so.

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

We could change indicate-empty-lines to have additional values:

If 'right, show in right fringe if present;
if 'left, show in left fringe if present;
otherwise, if non-nil, show in left fringe if present, else in right fringe if 
present.