[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fringe frame parameters, default values

From: Kim F. Storm
Subject: Re: Fringe frame parameters, default values
Date: 06 Dec 2001 11:58:34 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Richard Stallman <address@hidden> writes:

> It is better than the current implementation because the value
> is always a number, never nil.  And the value always scales
> reasonably with a change in font.
>     then I will still have to adjust the fringe widths so that they occupy
>     an intergral number of frames, i.e. that actual widths ratios would be
>     0.75 and 1.25 -- so it is still not possible to see what the configured
>     values are!
> That is already true, right?  So using columns as units won't
> be any improvement here, but it also won't make things any worse.
> Meanwhile, if you specify fringe widths that add up to an integer, you
> know they won't be adjusted, right?  This is the right solution, I
> believe.

I do agree that this is more *consistent* than the current
implementation, but I don't think it is *better*, for the following

Since the fringe is only used for the display of a fixed set of
bitmaps, the goal is typically to make the fringes just wide enough
to show those bitmaps.  I.e. the normal calculation of the widths
is *not* a ratio of the column width - it is *solely* based on the
bitmap widths, but rounded up to an integral number of columns.

Suppose we start with a font whose width is equal to or a little more
than the bitmap width, this means that the default setting of the
fringe width would be 1.0 for both the left and right fringe.

However, if we start with a font which is half the width of the bitmaps,
the default ratio for the bitmap widths should be 2.0 (or more) to allow
the fringes to be wide enough to show the bitmaps.

And if we started with a font which is double (or more) the width of
the bitmaps, we would use a ratio of 0.5 as the default.

So we definitely need to have the default setting for the fringe
widths to be something *different* from a fixed ratio (say 1.0).  This
is what is achieved with the current default of nil, which means to
calculate the minimum required fringe widths.

Now, IMO, the same arguments above can be repeated when setting the
value of the fringe width parameters to a certain ratio of the font

Suppose I always want to force the left fringe to be as narrow as
possible to minimize the `visually wasted' space in the left margin.

The current bitmaps all have a fixed width of 8 pixels, so with the
current implementation, I can achieve this simply by setting the left
margin to -8 and the right margin to nil.

With your method, I would have to manually determine the proper
ratio to use for my current font, i.e. if the font width happens
to be 11, I would have use a ratio of 0.72 for the left fringe and
1.28 for the right fringe to ensure I would get a left fringe of 8
pixels and a right fringe of 14 pixels (hoping that the rounding
of the ratio doesn't give me 7 and 15 pixels instead).

And if I change the font for some reason, I will have to recalculate
the ratios.

So while using ratios might be more consistent, it is also much harder
to use - so it would be a step in the wrong direction IMO.!

> Note that when we generalize frame sizes so that they don't have to be
> integral, we will probably also eliminate the requirement that the
> fringe widths must add to an integer.

Which takes away one of the major arguments for using ratios (that they
should add up to an integer).

And we already measure border-width and internal-border-width in pixels.

Also, when we remove the above restriction, I suppose that we are going
to allow scroll bars to have non-integral widths as well.  In that case,
I would much prefer to be able to specify that width in pixels rather
than a ratio - to ensure that all my scroll-bars get the same width
independent on the font which happens to be used on a specific frame!

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]