emacs-devel
[Top][All Lists]
Advanced

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

Re: unnecessary fringe-indicators defcustom creates trouble


From: Luc Teirlinck
Subject: Re: unnecessary fringe-indicators defcustom creates trouble
Date: Mon, 1 Aug 2005 16:18:00 -0500 (CDT)

Richard Stallman wrote:

       Another problem is that the first line of the indicate-empty-lines
       docstring is pretty self-explanatory.  So somebody setting this
       through Custom may not click on MORE and see the warning about first
       setting fringe-indicators to `other'.

   To avoid small problem risks like that is probably impossible.
   It would not be worth making a major change because of this.
   Can you think of nay small change to avoid this risk?

I do not believe that getting rid of a cumbersome redundant variable
is a major change.  It was not available in 21.4, so it is not an
incompatible change.  Maybe a few CVS users may have set it, but if
you use CVS, you know that it is subject to change.  On the other
hand, indicate-empty-lines has been available and well documented for
some time now, in released versions, and many users will have set it.
They now will have to customize some other variable, just to have
their indicate-empty-lines customization respected.

If you really want to keep the fringe-indicators monstrosity at all
costs, then I suggest making `other' the default for
fringe-indicators, which would allow to use custom-initialize-default
as the :initialize function, because `other' does not require the :set
function to be called.  The resulting default behavior would stay the
same as it is now, no indicators of any type.  I would put
`fringe-indicators' in a user-invisible menu-bar-internal Custom group,
thereby avoiding confusion for Custom users customizing the fringe
group (by having several options to customize the same thing).

People would not have to do anything special to customize
`indicate-empty-lines' and `indicate-fringe-boundaries' through Custom
or in .emacs and they would only need to be warned in the docstrings
that if they also customize it in a different way using the menu bar,
then the menu bar will prevail.

Sincerely,

Luc.




reply via email to

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