emacs-devel
[Top][All Lists]
Advanced

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

Re: Should `revert-buffer' preserve text-scaling by default?


From: Karl Fogel
Subject: Re: Should `revert-buffer' preserve text-scaling by default?
Date: Mon, 02 Dec 2019 16:29:25 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On 02 Dec 2019, Eli Zaretskii wrote:
>If we want to consider changing the default, IMO it would be better to
>add a defcustom that will start at nil (i.e. the default stays as it
>was before), and will in the future become non-nil if that's what
>people want.

Well, that would be progress, at least.  I would definitely set it :-).

What is the process by which we might eventually decide to change the default 
to non-nil (that is, to *not* resetting modes)?

In other words, how will the mere passage of time affect our willingness to 
change the default interactive behavior?  Is it that the existence of the 
variable will make it easy for us to ask the question (six months from now or 
whenever) "Hey, folks, did you know about this new defcustom and did you 
consciously decide whether to set it?"  We can easily ask that question before 
implementing the variable, though.  If the idea is we would post to some 
forum(s) and ask, then let's just do those posts now and ask whether people 
would like `revert-buffer' to stop resetting modes by default.

(I'm not sure which forums those would be, other than this one.  There's no 
"emacs-users" mailing list listed at 
https://savannah.gnu.org/mail/?group=emacs.)

I understand the general principle of proceeding cautiously.  My question is 
how introducing this defcustom is a step along any particular road -- how it is 
part of "proceeding"?  Maybe by people reading the NEWS entry about the new 
defcustom?  In that case, maybe we should solicit input directly from the NEWS 
entry, so we have more information to work with when we're later considering 
whether to change its default value.

Once we decide what we're doing here, I'm happy to implement it, by the way.

Best regards,
-Karl



reply via email to

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