The function y-or-n-p originally used to read only a small set of character commands. In Emacs 27.1 we changed it to use read-from-minibuffer, which means users now can easily switch out of the minibuffer while the question they were asked is still not answered. This could confuse some users, especially if they aren't used to working with recursive minibuffers. Richard tells me it happened to him several times. Would it make sense to add a user option to disallow switching from the minibuffer in the middle of y-or-n-p? Then people who get confused by this could set it to avoid the confusion.
> Would it make sense to add a user option to disallow switching from
> the minibuffer in the middle of y-or-n-p? Then people who get
> confused by this could set it to avoid the confusion.
I wonder what makes `y-or-n-p` special in this respect.
IOW, I think the answer is "yes, it would make sense" but I also think
this option should apply to other cases that `y-or-n-p`.
Maybe it could/should even apply to most uses of the minibuffer?
Stefan
* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-23 19:46]:
> > Would it make sense to add a user option to disallow switching from
> > the minibuffer in the middle of y-or-n-p? Then people who get
> > confused by this could set it to avoid the confusion.
>
> I wonder what makes `y-or-n-p` special in this respect.
> IOW, I think the answer is "yes, it would make sense" but I also think
> this option should apply to other cases that `y-or-n-p`.
>
> Maybe it could/should even apply to most uses of the minibuffer?
I would say as option yes, but not by default. It is useful for users
to be able to press various other keys, move to other windows to
consult references and then come back and answer yes or no questions
or other stuff. That is what I do all the time to give you one more
insight of user experience.
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org, Richard Stallman <rms@gnu.org>
> Date: Wed, 23 Dec 2020 11:45:46 -0500
>
> > Would it make sense to add a user option to disallow switching from
> > the minibuffer in the middle of y-or-n-p? Then people who get
> > confused by this could set it to avoid the confusion.
>
> I wonder what makes `y-or-n-p` special in this respect.
> IOW, I think the answer is "yes, it would make sense" but I also think
> this option should apply to other cases that `y-or-n-p`.
>
> Maybe it could/should even apply to most uses of the minibuffer?
Could be. However, y-or-n-p is somewhat special, in that it allowed
only very restricted set of things to type. By contrast
read-from-minibuffer always allowed switching out of the minibuffer.
>> > Would it make sense to add a user option to disallow switching from
>> > the minibuffer in the middle of y-or-n-p? Then people who get
>> > confused by this could set it to avoid the confusion.
>>
>> I wonder what makes `y-or-n-p` special in this respect.
>> IOW, I think the answer is "yes, it would make sense" but I also think
>> this option should apply to other cases that `y-or-n-p`.
>>
>> Maybe it could/should even apply to most uses of the minibuffer?
>
> Could be. However, y-or-n-p is somewhat special, in that it allowed
> only very restricted set of things to type. By contrast
> read-from-minibuffer always allowed switching out of the minibuffer.
So you're saying the only reason to treat `y-or-n-p` differently is to
avoid surprising old users?
Fair enough, but IIRC `y-or-n-p` is not the only function we changed
recently to use a minibuffer instead of an ad-hoc modal read-event loop,
so I suspect we might want to apply this new option to those other
functions as well.
Stefan
> From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: emacs-devel@gnu.org, rms@gnu.org > Date: Wed, 23 Dec 2020 13:11:53 -0500 > > >> Maybe it could/should even apply to most uses of the minibuffer? > > > > Could be. However, y-or-n-p is somewhat special, in that it allowed > > only very restricted set of things to type. By contrast > > read-from-minibuffer always allowed switching out of the minibuffer. > > So you're saying the only reason to treat `y-or-n-p` differently is to > avoid surprising old users? Old users who have the previous operation of y-or-n-p burned into their muscle memory, yes. > Fair enough, but IIRC `y-or-n-p` is not the only function we changed > recently to use a minibuffer instead of an ad-hoc modal read-event loop, > so I suspect we might want to apply this new option to those other > functions as well. I think you are right.
Eli Zaretskii <eliz@gnu.org> writes: > Would it make sense to add a user option to disallow switching from > the minibuffer in the middle of y-or-n-p? Then people who get > confused by this could set it to avoid the confusion. Yes, I think that makes sense (and as Stefan says, this should also work for the other char-reading functions that we've switched over). However, I do think it's likely that people who've switched this new user option on will find themselves in situations where they'll be going "but this time I do want to switch to another buffer". Would adding a new keystroke for switch-from-the-minibuffer-even-if-I-don't-usually-want-to make sense? Bound to some complicate keystroke people are unlikely to hit by mistake? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
On 23 Dec 2020, Eli Zaretskii wrote:
>The function y-or-n-p originally used to read only a small set of
>character commands. In Emacs 27.1 we changed it to use
>read-from-minibuffer, which means users now can easily switch out of
>the minibuffer while the question they were asked is still not
>answered.
>
>This could confuse some users, especially if they aren't used to
>working with recursive minibuffers. Richard tells me it happened to
>him several times.
>
>Would it make sense to add a user option to disallow switching from
>the minibuffer in the middle of y-or-n-p? Then people who get
>confused by this could set it to avoid the confusion.
I'm surprised that the intersection of these two sets is non-empty:
a) Users who would know enough to look for and set such an option.
b) Users who would be confused by what happens after they switch away from a y-or-n-p minibuffer in mid-question.
However, Richard is clearly in (a), and apparently he is in (b) as well. So there's an existence proof. I have no idea how many elements that set has, but if it has 1, it probably has more? So sure, given the recent behavior change in 27.1, having this option could be useful to them.
(And, though I know some disagree, I don't think there's much cost to adding little options like this. Emacs already has a zillion of them, so targeted reading and discovery are the strategy everyone already uses to find them anyway, which means adding a new one does not increase the complexity of Emacs in a problematic way IMHO.)
Best regards,
-Karl
> From: Karl Fogel <kfogel@red-bean.com> > Cc: emacs-devel@gnu.org, Richard Stallman <rms@gnu.org> > Date: Wed, 23 Dec 2020 15:53:59 -0400 > > I'm surprised that the intersection of these two sets is non-empty: > > a) Users who would know enough to look for and set such an option. > > b) Users who would be confused by what happens after they switch away from a y-or-n-p minibuffer in mid-question. They are confused because they don't expect to see what happens in that case. Imagine someone who can easily press a wrong key for some reason -- with the new implementation, instead of Emacs showing an error message and the user staying right where he or she was, he or she now find themselves in some situation they need to think how to get out of. > (And, though I know some disagree, I don't think there's much cost to adding little options like this. Emacs already has a zillion of them, so targeted reading and discovery are the strategy everyone already uses to find them anyway, which means adding a new one does not increase the complexity of Emacs in a problematic way IMHO.) What would you suggest instead?
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Would it make sense to add a user option to disallow switching from > the minibuffer in the middle of y-or-n-p? Then people who get > confused by this could set it to avoid the confusion. Please do! If you are happy with the current behavior, just don't set the option. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] If I had intentionally switched windors inside y-or-n-p, I would have known what to do next. But it happened without my noticing, and I never figured out why. It was only later, after some results I could not make sense of, that I realized I had switched windows somehow. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > Would it make sense to add a user option to disallow switching from
> > the minibuffer in the middle of y-or-n-p? Then people who get
> > confused by this could set it to avoid the confusion.
>
> Please do! If you are happy with the current behavior, just don't
> set the option.
This would also make sense as a general accessibility option. I have a
sensitive laptop and essential tremors. I often find that I've
accidentally hit the touchpad causing the cursor to jump to where the
mouse is. It takes a moment to get back to where I was. An option to
disable-switching-if-minibuffer-active would help.
--
David Masterson
> The function y-or-n-p originally used to read only a small set of > character commands. In Emacs 27.1 we changed it to use > read-from-minibuffer, which means users now can easily switch out of > the minibuffer while the question they were asked is still not > answered. In the Elisp manual we say that ‘yes-or-no-p’ requires more work from the user than ‘y-or-n-p’ and is appropriate for more crucial decisions. Now while 'yes-or-no-p' implements what is sometimes called a "modeless" or "non-modal" dialogue, our original 'y-or-n-p' implemented a "modal" dialogue where the user had no other choice but to answer the question immediately, possibly performing a few buffer scrolls in between. However, according to Wikipedia, modal dialogues are used "to command user awareness and to display emergency states" inherently contradicting what we say above. Maybe I'm the only one who sees a contradiction here. Still I'd suggest to allow users to separately choose for both, 'y-or-n-p' _and_ 'yes-or-no-p' dialogues, whether they want Emacs to handle them in a modal or non-modal way. And while we're there we could also try to relieve some of our .emacs files (mine included) of those (defalias 'yes-or-no-p 'y-or-n-p) by providing an option that accomplishes the necessary mapping. Thanks, martin
On Thu, Dec 24, 2020 at 5:53 AM Richard Stallman <rms@gnu.org> wrote:
>
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > Would it make sense to add a user option to disallow switching from
> > the minibuffer in the middle of y-or-n-p? Then people who get
> > confused by this could set it to avoid the confusion.
>
> Please do! If you are happy with the current behavior, just don't
> set the option.
To be honest I'd also welcome such an option that quits the
minibuffer input immediately after switching away from it to
another window. No just y-or-n-p: every minibuffer-prompt.
I realize I would lose the ability to go search in other buffers
for answers to the prompt being offered in the minibuffer, but I
\would still prefer it to the confusion of leaving something
hanging there. It always gets me, even after many years
of Emacs.
I'm sure there's are multiple Elisp snippets that achieve
this, I wonder if someone can think of a simple one and
post it here.
Thanks,
João
On 23 Dec 2020, Eli Zaretskii wrote:
>> (And, though I know some disagree, I don't think there's much cost
>> to adding little options like this. Emacs already has a zillion of
>> them, so targeted reading and discovery are the strategy everyone
>> already uses to find them anyway, which means adding a new one does
>> not increase the complexity of Emacs in a problematic way IMHO.)
>
>What would you suggest instead?
? I wasn't suggesting that we should take another course. I was agreeing with the original proposal, and offering more support for it by refuting one possible objection.
Best regards,
-Karl
> In the Elisp manual we say that > > ‘yes-or-no-p’ requires more work from the user than ‘y-or-n-p’ and > is appropriate for more crucial decisions. > > Now while 'yes-or-no-p' implements what is sometimes called a "modeless" > or "non-modal" dialogue, our original 'y-or-n-p' implemented a "modal" > dialogue where the user had no other choice but to answer the question > immediately, possibly performing a few buffer scrolls in between. > > However, according to Wikipedia, modal dialogues are used > > "to command user awareness and to display emergency states" > > inherently contradicting what we say above. Maybe I'm the only one who > sees a contradiction here. Still I'd suggest to allow users to > separately choose for both, 'y-or-n-p' _and_ 'yes-or-no-p' dialogues, > whether they want Emacs to handle them in a modal or non-modal way. Indeed. Here is a possible way to make the minibuffer modal: (defun minibuffer-lock () (when (active-minibuffer-window) (select-window (active-minibuffer-window)))) (add-hook 'post-command-hook #'minibuffer-lock) > And while we're there we could also try to relieve some of our .emacs > files (mine included) of those > > (defalias 'yes-or-no-p 'y-or-n-p) > > by providing an option that accomplishes the necessary mapping. One complication is that currently yes-or-no-p is implemented in C, so using a new user option in it is not straightforward.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Fair enough, but IIRC `y-or-n-p` is not the only function we changed > > recently to use a minibuffer instead of an ad-hoc modal read-event loop, > > so I suspect we might want to apply this new option to those other > > functions as well. > I think you are right. I agree too. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > However, according to Wikipedia, modal dialogues are used > "to command user awareness and to display emergency states" > inherently contradicting what we say above. Maybe I'm the only one who > sees a contradiction here. Emacs does not fit Wikipedia's general statement, but I don't see that it ought to fit. The idea of y-or-n-p and yes-or-no-p is that for less important questions, where saying yes by mistake is not so bad, you can answer in one character. When more confirmation should be required, we use yes-or-no-p so you must answer with four characters. It just happened that the former was easy to do by reading an event and the only easy way to do the latter was with a minibuffer. So the former turned out to be "modal" and the latter turned out not to be. But I don't see that that matters particularly. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> From: Juri Linkov <juri@linkov.net> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, Richard Stallman > <rms@gnu.org> > Date: Thu, 24 Dec 2020 22:47:07 +0200 > > Indeed. Here is a possible way to make the minibuffer modal: > > (defun minibuffer-lock () > (when (active-minibuffer-window) > (select-window (active-minibuffer-window)))) > > (add-hook 'post-command-hook #'minibuffer-lock) Would something like that work to give users an option discussed in this thread for y-or-n-p? If so, can you please show a patch for that? > > And while we're there we could also try to relieve some of our .emacs > > files (mine included) of those > > > > (defalias 'yes-or-no-p 'y-or-n-p) > > > > by providing an option that accomplishes the necessary mapping. > > One complication is that currently yes-or-no-p is implemented in C, > so using a new user option in it is not straightforward. What are the difficulties? You can call Lisp from C, given an option, which is what I think Martin asked for.
> Here is a possible way to make the minibuffer modal: > > (defun minibuffer-lock () > (when (active-minibuffer-window) > (select-window (active-minibuffer-window)))) > > (add-hook 'post-command-hook #'minibuffer-lock) That's too harsh because it would affect all minibuffer interactions. >> And while we're there we could also try to relieve some of our .emacs >> files (mine included) of those >> >> (defalias 'yes-or-no-p 'y-or-n-p) >> >> by providing an option that accomplishes the necessary mapping. > > One complication is that currently yes-or-no-p is implemented in C, > so using a new user option in it is not straightforward. I would just amend this part if (SCHARS (ans) == 3 && !strcmp (SSDATA (ans), "yes")) return unbind_to (count, Qt); if (SCHARS (ans) == 2 && !strcmp (SSDATA (ans), "no")) return unbind_to (count, Qnil); leaving dialog boxes and the rest alone. martin
> > However, according to Wikipedia, modal dialogues are used > > > "to command user awareness and to display emergency states" > > > inherently contradicting what we say above. Maybe I'm the only one who > > sees a contradiction here. > > Emacs does not fit Wikipedia's general statement, > but I don't see that it ought to fit. > > The idea of y-or-n-p and yes-or-no-p is that for less important > questions, where saying yes by mistake is not so bad, you can answer > in one character. When more confirmation should be required, we use > yes-or-no-p so you must answer with four characters. > > It just happened that the former was easy to do by reading an event and > the only easy way to do the latter was with a minibuffer. So the > former turned out to be "modal" and the latter turned out not to be. > > But I don't see that that matters particularly. It could have helped to establish guidelines for asking questions in a more consistent and less adhocish way. But since Eli here asked for an option to restore some previous behavior only, I won't insist further. martin
>> (defun minibuffer-lock () >> (when (active-minibuffer-window) >> (select-window (active-minibuffer-window)))) >> >> (add-hook 'post-command-hook #'minibuffer-lock) > > Would something like that work to give users an option discussed in > this thread for y-or-n-p? There are two orthogonal issues here: Whether to enable recursive minibuffers and whether to allow leaving the minibuffer window while asking a 'y-or-n-p' question. The above addresses the latter only. martin
>> Indeed. Here is a possible way to make the minibuffer modal: >> >> (defun minibuffer-lock () >> (when (active-minibuffer-window) >> (select-window (active-minibuffer-window)))) >> >> (add-hook 'post-command-hook #'minibuffer-lock) > > Would something like that work to give users an option discussed in > this thread for y-or-n-p? If so, can you please show a patch for > that? I thought that others wanted this to affect all minibuffer commands. How would it be possible to customize this behavior only for a subset of commands? >> > And while we're there we could also try to relieve some of our .emacs >> > files (mine included) of those >> > >> > (defalias 'yes-or-no-p 'y-or-n-p) >> > >> > by providing an option that accomplishes the necessary mapping. >> >> One complication is that currently yes-or-no-p is implemented in C, >> so using a new user option in it is not straightforward. > > What are the difficulties? You can call Lisp from C, given an option, > which is what I think Martin asked for. In Lisp it would be simpler to add to the beginning of 'yes-or-no-p': (if use-y-or-n-p (y-or-n-p prompt)
> Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>,
> emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 25 Dec 2020 09:42:10 +0100
>
> > Here is a possible way to make the minibuffer modal:
> >
> > (defun minibuffer-lock ()
> > (when (active-minibuffer-window)
> > (select-window (active-minibuffer-window))))
> >
> > (add-hook 'post-command-hook #'minibuffer-lock)
>
> That's too harsh because it would affect all minibuffer interactions.
Not if done only by the relevant commands/functions, right?
> Cc: emacs-devel@gnu.org, rms@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 25 Dec 2020 10:07:17 +0100
>
> >> (defun minibuffer-lock ()
> >> (when (active-minibuffer-window)
> >> (select-window (active-minibuffer-window))))
> >>
> >> (add-hook 'post-command-hook #'minibuffer-lock)
> >
> > Would something like that work to give users an option discussed in
> > this thread for y-or-n-p?
>
> There are two orthogonal issues here: Whether to enable recursive
> minibuffers and whether to allow leaving the minibuffer window while
> asking a 'y-or-n-p' question. The above addresses the latter only.
Isn't that enough to solve the problem which started this thread?
> From: Juri Linkov <juri@linkov.net> > Cc: rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org > Date: Fri, 25 Dec 2020 11:23:45 +0200 > > >> (defun minibuffer-lock () > >> (when (active-minibuffer-window) > >> (select-window (active-minibuffer-window)))) > >> > >> (add-hook 'post-command-hook #'minibuffer-lock) > > > > Would something like that work to give users an option discussed in > > this thread for y-or-n-p? If so, can you please show a patch for > > that? > > I thought that others wanted this to affect all minibuffer commands. > How would it be possible to customize this behavior only for a subset > of commands? Can't we add to post-command-hook only in the commands from that subset, and remove it when leaving the minibuffer? > >> One complication is that currently yes-or-no-p is implemented in C, > >> so using a new user option in it is not straightforward. > > > > What are the difficulties? You can call Lisp from C, given an option, > > which is what I think Martin asked for. > > In Lisp it would be simpler to add to the beginning of 'yes-or-no-p': > > (if use-y-or-n-p > (y-or-n-p prompt) You can do the same, almost literally, in C, can't you?
>> > (defun minibuffer-lock () >> > (when (active-minibuffer-window) >> > (select-window (active-minibuffer-window)))) >> > >> > (add-hook 'post-command-hook #'minibuffer-lock) >> >> That's too harsh because it would affect all minibuffer interactions. > > Not if done only by the relevant commands/functions, right? Wouldn't that mean that each of these commands/functions would have to establish its own "lock-environment" to ensure that a nested invocation of another command/function is not affected and, when returning from one recursive environment, the correct state of locking is restored? Maybe it's easy to do that but with our minibuffer windows jumping from one frame to another it doesn't look entirely trivial to me. martin
>> There are two orthogonal issues here: Whether to enable recursive >> minibuffers and whether to allow leaving the minibuffer window while >> asking a 'y-or-n-p' question. The above addresses the latter only. > > Isn't that enough to solve the problem which started this thread? I'm not sure. For example, we can currently nest an invocation of a 'yes-or-no-p' question within the scope of a 'y-or-n-p' question. This was impossible before and means that the user will either still be able to leave the minibuffer window even when it was locked by a 'y-or-n-p' (if we adopt the environmental solution I mentioned in the other thread) or that a nested 'yes-or-no-p' question no longer allows to leave the minibuffer window. Maybe these are just contrived cases but I have no idea how many similar, more realistic ones exist. martin
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I'm not sure. For example, we can currently nest an invocation of a > 'yes-or-no-p' question within the scope of a 'y-or-n-p' question. I'd like the old behavior for y-or-n-p, where any character not on the list of special ones will err out of it. With that behavior, the question about nesting yes-or-no-p inside won't matter. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Still I'd suggest to allow users to > > separately choose for both, 'y-or-n-p' _and_ 'yes-or-no-p' dialogues, > > whether they want Emacs to handle them in a modal or non-modal way. That would have these drawbacks * It would mean extra complexity to debug, maintain, and document * It would not directly provide the old behavior, only a basis for it. People who want that would have to implement that. Does anyone really WANT this generality, or is it generality for generality's sake? > Indeed. Here is a possible way to make the minibuffer modal: > (defun minibuffer-lock () > (when (active-minibuffer-window) > (select-window (active-minibuffer-window)))) I am not sure what behavior that would give. But I think it is NOT the behavior that y-or-n-p used to have, which was to reject unexpected answers. What was the reason for implementing this change in the single-character-answer commands? Who actually wanted the change in behavior? And for what use cases? If people really like the new behavior, I won't argue against it. But maybe we should turn it off by default, like recursive minibuffers. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > There are two orthogonal issues here: Whether to enable recursive > > minibuffers and whether to allow leaving the minibuffer window while > > asking a 'y-or-n-p' question. The above addresses the latter only. > Isn't that enough to solve the problem which started this thread? No. It would prevent some of the secondary confusion. But the basic confusion came from getting out of the y-or-n-p question. I'd like to have all those commands, which read one-character answers, use the old code and give exactly the old behavior. A little while ago I found that my minibuffer was displaying Unsent message being composed, erase it? (y or n) and I had no recollection of why. Nor was it easy to make it go away. Sure, I could have done it with C-], but C-] does not come to mind when I see that. I expect to answer y or n, but that doesn't work when the minibuffer is not selected. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[-- Attachment #1: Type: text/plain, Size: 2454 bytes --] If you are already speaking about y-or-no functions, I think they could get more friendlier interface: I wish there was a default, pre choosen value set by developr; either Y or N, marked in color and maybe capitalized and bound to Enter key, so user can just tapp the Enter to confirm the choice. Similar as how some shell scripts implement it. I think color draws eye to the choice, and just tapping Enter to confirm is just a convenience. User could still press y or n as of current of course. ________________________________ Från: Emacs-devel <emacs-devel-bounces+arthur.miller=live.com@gnu.org> för Richard Stallman <rms@gnu.org> Skickat: den 26 december 2020 11:24 Till: Juri Linkov <juri@linkov.net>; rudalics@gmx.at <rudalics@gmx.at> Kopia: eliz@gnu.org <eliz@gnu.org>; emacs-devel@gnu.org <emacs-devel@gnu.org> Ämne: Re: Confused by y-or-n-p [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Still I'd suggest to allow users to > > separately choose for both, 'y-or-n-p' _and_ 'yes-or-no-p' dialogues, > > whether they want Emacs to handle them in a modal or non-modal way. That would have these drawbacks * It would mean extra complexity to debug, maintain, and document * It would not directly provide the old behavior, only a basis for it. People who want that would have to implement that. Does anyone really WANT this generality, or is it generality for generality's sake? > Indeed. Here is a possible way to make the minibuffer modal: > (defun minibuffer-lock () > (when (active-minibuffer-window) > (select-window (active-minibuffer-window)))) I am not sure what behavior that would give. But I think it is NOT the behavior that y-or-n-p used to have, which was to reject unexpected answers. What was the reason for implementing this change in the single-character-answer commands? Who actually wanted the change in behavior? And for what use cases? If people really like the new behavior, I won't argue against it. But maybe we should turn it off by default, like recursive minibuffers. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) [-- Attachment #2: Type: text/html, Size: 4398 bytes --]
> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Sat, 26 Dec 2020 05:24:17 -0500
>
> What was the reason for implementing this change in the
> single-character-answer commands? Who actually wanted the change in
> behavior? And for what use cases?
AFAIR, the implementation was changed to provide the following
advantages:
. allow having history for single-character-answer commands
. avoid hiding the prompt when async messages arrive
> From: Richard Stallman <rms@gnu.org>
> Cc: rudalics@gmx.at, juri@linkov.net, emacs-devel@gnu.org
> Date: Sat, 26 Dec 2020 05:24:22 -0500
>
> A little while ago I found that my minibuffer was displaying
>
> Unsent message being composed, erase it? (y or n)
>
> and I had no recollection of why. Nor was it easy to make it go away.
> Sure, I could have done it with C-], but C-] does not come to mind
> when I see that. I expect to answer y or n, but that doesn't work
> when the minibuffer is not selected.
Does it work to type "C-x o" one or more times to get back into the
minibuffer? (I guess you will need to wait to the next time it
happens to check whether that solves the problem.)
* Richard Stallman <rms@gnu.org> [2020-12-26 13:25]:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > I'm not sure. For example, we can currently nest an invocation of a
> > 'yes-or-no-p' question within the scope of a 'y-or-n-p' question.
>
> I'd like the old behavior for y-or-n-p, where any character not on
> the list of special ones will err out of it. With that behavior,
> the question about nesting yes-or-no-p inside won't matter.
I hope that gets included as an option, as for the reason that user
shall not be locked in a minibuffer, it makes Emacs not accessible and
annoying. User has to have option to switch to other buffers, to
consult oneself or obtain more information before answering, and come
back, additionally ? for help shall be allowed and C-h m/k and other
info functions.
Maybe is good to introduce `y-or-n-p-modal' function that does that
for programmers who need that specific.
> I'd like the old behavior for y-or-n-p, where any character not on > the list of special ones will err out of it. With that behavior, > the question about nesting yes-or-no-p inside won't matter. The most simple approach to get the old behavior back is to restore the old code for 'y-or-n-p', rename it to something like 'y-or-n-p-old' and call it when an option like `y-or-n-p-use-old' is non-nil. martin
> What was the reason for implementing this change in the > single-character-answer commands? Who actually wanted the change in > behavior? And for what use cases? The old behavior was based on the assumption that the echo area and the minibuffer contents are always shown in one and the same window (at least wrt to one and the same frame). This design has the basic flaw that it will preclude forever showing echo area and minibuffer window in separate areas of the screen: Otherwise, users would be asked `yes-or-no-p' questions in one screen area, 'y-or-n-p' ones in another. Now why would separating echo area and minibuffer window be desirable? A main reason is that over the past years we started to show things in the echo area that we didn't show there before, with the consequence that prompts got more and more hidden by messages or some messages never even made it to the echo area in the first place. Ultimately, the time sharing approach crashed under the load of messages. So Eli started to visually separate the area where we prompt for user input from the area where we show messages. While this seems to work for most of our more experienced users, less experienced ones (including me) are now confused whenever they see a message that is completely unrelated to the current interaction appear after the prompt. We simply have never in our life seen a program put notifications and user input into one and the same screen line. Finally, Juri made a first stab in unifying the 'yes-or-no-p' and 'y-or-n-p' behaviors by handling both via reading from the minibuffer. This means that one can implement visual separation for these in the same way, hopefully also in separate screen areas. martin, with best wishes to father Edward
> > > Still I'd suggest to allow users to
> > > separately choose for both, 'y-or-n-p' _and_
> > > 'yes-or-no-p' dialogues, whether they want Emacs
> > > to handle them in a modal or non-modal way.
>
> That would have these drawbacks
> * It would mean extra complexity to debug, maintain, and document
> * It would not directly provide the old behavior, only a basis for it.
> People who want that would have to implement that.
>
> Does anyone really WANT this generality, or is it generality for
> generality's sake?
>
> > Indeed. Here is a possible way to make the minibuffer modal:
> > (defun minibuffer-lock ()
> > (when (active-minibuffer-window)
> > (select-window (active-minibuffer-window))))
>
> I am not sure what behavior that would give.
> But I think it is NOT the behavior that y-or-n-p used to
> have, which was to reject unexpected answers.
>
> What was the reason for implementing this change in the
> single-character-answer commands? Who actually wanted
> the change in behavior? And for what use cases?
>
> If people really like the new behavior, I won't argue against it.
> But maybe we should turn it off by default, like recursive minibuffers.
FWIW:
I opposed this new behavior. I think I was the only
one who did, but that impression might be wrong.
I opposed reading from the minibuffer for `y-or-n-p',
in part because it can break existing UI dialogs
(which may also involve the minibuffer at outer
levels), but also in part because of the reasons
you give (which are related).
I opposed wholesale replacement of uses of `read-key'
with use of the minibuffer. (Not that 100% wholesale
replacement has occurred, but I sense that a general
motivation in that direction has taken hold of the
movers and shakers.)
IIRC, this change was done in bug threads. I don't
think there was discussion in emacs-devel. (Apology
if I remember this wrong). In any case, as Eli is
wont to say, "That ship sailed long ago." Alas.
___
Emacs 27 introduced several changes involving use of
the minibuffer, which unfortunately have broken my
personal use of Emacs (as well as some of my libraries,
which are used by some other users).
I use a standalone minibuffer frame, and I have lots
of dialogs that let you interact in virtually any way
with other buffers, etc. while a minibuffer interaction
is in progress. E.g., for some commands that use the
minibuffer, you can hit keys that initiate sub-dialogs,
which can involve all kinds of things (and which
typically don't involve recursive minibuffers).
And the minibuffer, in my use, is very much an editing
buffer, i.e., most editing keys/commands act normally
there. I want it to continue to be general this way.
I think some simplifying lockdowns of certain behavior
have been clamped onto the minibuffer lately, based on
(1) some assumptions that apply to presumed common
interactions and expectations, and (2) attempts to "fix"
some (relatively corner?) cases. That's an impression
I have, and it's largely uninformed/ignorant, as I can't
really make use of Emacs since release 27.
So I don't use Emacs 27, and ditto for Emacs 28. I do
sometimes submit bug reports for 27, as a result of
looking into some questions from other users. But
those are mostly doc-bug reports.
Maybe, if I'm on the planet long enough and have
enough patience and interest, I'll eventually get to
the bottom of why I can't use Emacs 27+, what breaks
what, and find workarounds. I'm not there now, and
I don't foresee ever going/getting there, alas.
I use Emacs 26.3, and perhaps always will.
Just one (hardly typical) user.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] For now, I ask people to make an option to restore the old behavior of y-or-n-p and friends. Please do this! There will be plenty of time later to try out different ways of handling them and see what people like. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Does it work to type "C-x o" one or more times to get back into the > minibuffer? I don't know for certain, but even if it does, the change is still a screw. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Thanks. Now I see the reason for changing the internal mechanism for y-or-n-p and such like. I would still like to get the old behavior back. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> The most simple approach to get the old behavior back is to restore the
> old code for 'y-or-n-p', rename it to something like 'y-or-n-p-old' and
> call it when an option like `y-or-n-p-use-old' is non-nil.
This is exactly what we recently did for the function 'read-char-choice'.
Instead of changing its long-standing implementation that uses 'read-key',
we left it unchanged, and only changed its caller to rely on a different
function that uses the minibuffer to read a character.
The same way we could add a function with old implementation of 'y-or-n-p',
and depending on an option use either of them. So two new options are
needed: to select an implementation of y-or-n-p and and also an option
to choose either to use yes-or-no-p or y-or-n-p with shorter answers.
Or maybe just one variable with three choices: long answers with yes-or-no-p,
short answers with read-key, short answers with the minibuffer.
> This is exactly what we recently did for the function 'read-char-choice'. > Instead of changing its long-standing implementation that uses 'read-key', > we left it unchanged, and only changed its caller to rely on a different > function that uses the minibuffer to read a character. Do you mean 'dired-query' and 'zap-up-to-char'? > The same way we could add a function with old implementation of 'y-or-n-p', > and depending on an option use either of them. So two new options are > needed: to select an implementation of y-or-n-p and and also an option > to choose either to use yes-or-no-p or y-or-n-p with shorter answers. This would be OK I think. With the "use the old implementation" option going to Emacs 27.2 and the use 'y-or-n-p' instead of 'yes-or-no-p' to master. > Or maybe just one variable with three choices: long answers with yes-or-no-p, > short answers with read-key, short answers with the minibuffer. This would probably bother both conservative and more adventurous users with something they'd never want. martin
> From: Juri Linkov <juri@linkov.net>
> Cc: rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org
> Date: Sun, 27 Dec 2020 18:25:08 +0200
>
> The same way we could add a function with old implementation of 'y-or-n-p',
> and depending on an option use either of them. So two new options are
> needed: to select an implementation of y-or-n-p and and also an option
> to choose either to use yes-or-no-p or y-or-n-p with shorter answers.
Could you please make such a change?
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The same way we could add a function with old implementation of 'y-or-n-p', > and depending on an option use either of them. So two new options are > needed: to select an implementation of y-or-n-p and That is the right approach, but there are other places where Emacs asks for a one-character answer and I'd like them to go back to the old behavior also. Perhaps you need to do this at the level of read-char-choice. and also an option > to choose either to use yes-or-no-p or y-or-n-p with shorter answers. If someone wants that option I see no harm in providing it. Did anyone actually ask for it, or was it proposed simply in the search for more alternative behaviors? > Or maybe just one variable with three choices: long answers with yes-or-no-p, > short answers with read-key, short answers with the minibuffer. Ok, provided it is for all the one-character answers, not solely for y-or-n-p. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> there are other places where Emacs asks
> for a one-character answer and I'd like
> them to go back to the old behavior also.
+1
>> This is exactly what we recently did for the function 'read-char-choice'. >> Instead of changing its long-standing implementation that uses 'read-key', >> we left it unchanged, and only changed its caller to rely on a different >> function that uses the minibuffer to read a character. > > Do you mean 'dired-query' and 'zap-up-to-char'? Only 'dired-query'. 'zap-up-to-char' is a different case. >> The same way we could add a function with old implementation of 'y-or-n-p', >> and depending on an option use either of them. So two new options are >> needed: to select an implementation of y-or-n-p and and also an option >> to choose either to use yes-or-no-p or y-or-n-p with shorter answers. > > This would be OK I think. With the "use the old implementation" option > going to Emacs 27.2 and the use 'y-or-n-p' instead of 'yes-or-no-p' to > master. > >> Or maybe just one variable with three choices: long answers with yes-or-no-p, >> short answers with read-key, short answers with the minibuffer. > > This would probably bother both conservative and more adventurous users > with something they'd never want. I agree.
>> The same way we could add a function with old implementation of 'y-or-n-p',
>> and depending on an option use either of them. So two new options are
>> needed: to select an implementation of y-or-n-p and and also an option
>> to choose either to use yes-or-no-p or y-or-n-p with shorter answers.
>
> Could you please make such a change?
Martin suggested to add the "use the old implementation" option
to Emacs 27.2. Is it OK with you?
> > The same way we could add a function with old implementation of 'y-or-n-p', > > and depending on an option use either of them. So two new options are > > needed: to select an implementation of y-or-n-p and > > That is the right approach, but there are other places where Emacs asks > for a one-character answer and I'd like them to go back to the old > behavior also. > > Perhaps you need to do this at the level of read-char-choice. Maybe by adding to the beginning of read-char-choice: (if read-char-from-minibuffer (read-char-from-minibuffer ...) > and also an option > > to choose either to use yes-or-no-p or y-or-n-p with shorter answers. > > If someone wants that option I see no harm in providing it. > Did anyone actually ask for it, or was it proposed simply in the > search for more alternative behaviors? Many users asked for such option for easier customization instead of adding this unobvious setting to the init file: (fset 'yes-or-no-p 'y-or-n-p)
On December 28, 2020 10:52:08 AM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
> >> The same way we could add a function with old implementation of
> 'y-or-n-p',
> >> and depending on an option use either of them. So two new options
> are
> >> needed: to select an implementation of y-or-n-p and and also an
> option
> >> to choose either to use yes-or-no-p or y-or-n-p with shorter
> answers.
> >
> > Could you please make such a change?
>
> Martin suggested to add the "use the old implementation" option
> to Emacs 27.2. Is it OK with you?
Yes, thanks.
[-- Attachment #1: Type: text/plain, Size: 286 bytes --] >> > Could you please make such a change? >> >> Martin suggested to add the "use the old implementation" option >> to Emacs 27.2. Is it OK with you? > > Yes, thanks. Here is the first version of the patch for master. If generally it's OK, then it could be backported to Emacs 27.2: [-- Attachment #2: use-read-key.patch --] [-- Type: text/x-diff, Size: 6616 bytes --] diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el index 0f68b47073..f83824a272 100644 --- a/lisp/dired-aux.el +++ b/lisp/dired-aux.el @@ -145,7 +145,7 @@ dired--no-subst-explain (defun dired--no-subst-ask (char nb-occur details) (let ((hilit-char (propertize (string char) 'face 'warning)) (choices `(?y ?n ?? ,@(when details '(?^))))) - (read-char-from-minibuffer + (read-char-choice (format-message (ngettext "%d occurrence of `%s' will not be substituted. Proceed? (%s) " @@ -1380,7 +1380,7 @@ dired-query (format " [Type yn!q or %s] " (key-description (vector help-char))) " [Type y, n, q or !] "))) - (set sym (setq char (read-char-from-minibuffer prompt char-choices))) + (set sym (setq char (read-char-choice prompt char-choices))) (if (memq char '(?y ?\s ?!)) t))))) \f diff --git a/lisp/files.el b/lisp/files.el index 70d451cccf..637aaa130a 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -2141,7 +2141,7 @@ files--ask-user-about-large-file ("Yes" . ?y) ("No" . ?n) ("Open literally" . ?l))) - (read-char-from-minibuffer + (read-char-choice (concat prompt " (y)es or (n)o or (l)iterally ") '(?y ?Y ?n ?N ?l ?L))))) (cond ((memq choice '(?y ?Y)) nil) @@ -3538,7 +3538,7 @@ hack-local-variables-confirm ", or C-v/M-v to scroll"))) char) (if offer-save (push ?! exit-chars)) - (setq char (read-char-from-minibuffer prompt exit-chars)) + (setq char (read-char-choice prompt exit-chars)) (when (and offer-save (= char ?!) unsafe-vars) (customize-push-and-save 'safe-local-variable-values unsafe-vars)) (prog1 (memq char '(?! ?\s ?y)) diff --git a/lisp/subr.el b/lisp/subr.el index 384dbb25cf..592c633a35 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -2626,6 +2626,10 @@ read-number t))) n)) +(defvar read-char-choice-use-read-key nil + "Prefer `read-key' when reading a character by `read-char-choice'. +Otherwise, use the minibuffer.") + (defun read-char-choice (prompt chars &optional inhibit-keyboard-quit) "Read and return one of CHARS, prompting for PROMPT. Any input that is not one of CHARS is ignored. @@ -2636,6 +2640,8 @@ read-char-choice If you bind the variable `help-form' to a non-nil value while calling this function, then pressing `help-char' causes it to evaluate `help-form' and display the result." + (if (not read-char-choice-use-read-key) + (read-char-from-minibuffer prompt chars) (unless (consp chars) (error "Called `read-char-choice' without valid char choices")) (let (char done show-help (helpbuf " *Char Help*")) @@ -2673,7 +2679,7 @@ read-char-choice (keyboard-quit)))))))) ;; Display the question with the answer. But without cursor-in-echo-area. (message "%s%s" prompt (char-to-string char)) - char)) + char))) (defun sit-for (seconds &optional nodisp obsolete) "Redisplay, then wait for SECONDS seconds. Stop when input is available. @@ -2920,6 +2926,10 @@ y-or-n-p-insert-other (minibuffer-message "Please answer y or n") (sit-for 2))) +(defvar y-or-n-p-use-read-key nil + "Prefer `read-key' when answering a \"y or n\" question by `y-or-n-p'. +Otherwise, use the minibuffer.") + (defvar empty-history) (defun y-or-n-p (prompt) @@ -2980,6 +2990,41 @@ y-or-n-p use-dialog-box) (setq prompt (funcall padded prompt t) answer (x-popup-dialog t `(,prompt ("Yes" . act) ("No" . skip))))) + (y-or-n-p-use-read-key + ;; ¡Beware! when I tried to edebug this code, Emacs got into a weird state + ;; where all the keys were unbound (i.e. it somehow got triggered + ;; within read-key, apparently). I had to kill it. + (setq prompt (funcall padded prompt)) + (while + (let* ((scroll-actions '(recenter scroll-up scroll-down + scroll-other-window scroll-other-window-down)) + (key + (let ((cursor-in-echo-area t)) + (when minibuffer-auto-raise + (raise-frame (window-frame (minibuffer-window)))) + (read-key (propertize (if (memq answer scroll-actions) + prompt + (concat "Please answer y or n. " + prompt)) + 'face 'minibuffer-prompt))))) + (setq answer (lookup-key query-replace-map (vector key) t)) + (cond + ((memq answer '(skip act)) nil) + ((eq answer 'recenter) + (recenter) t) + ((eq answer 'scroll-up) + (ignore-errors (scroll-up-command)) t) + ((eq answer 'scroll-down) + (ignore-errors (scroll-down-command)) t) + ((eq answer 'scroll-other-window) + (ignore-errors (scroll-other-window)) t) + ((eq answer 'scroll-other-window-down) + (ignore-errors (scroll-other-window-down)) t) + ((or (memq answer '(exit-prefix quit)) (eq key ?\e)) + (signal 'quit nil) t) + (t t))) + (ding) + (discard-input))) (t (setq prompt (funcall padded prompt)) (let* ((empty-history '()) diff --git a/lisp/userlock.el b/lisp/userlock.el index ec76322337..249f40e9af 100644 --- a/lisp/userlock.el +++ b/lisp/userlock.el @@ -159,7 +159,7 @@ ask-user-about-supersession-threat (message "%s" prompt) (error "Cannot resolve conflict in batch mode")) (while (null answer) - (setq answer (read-char-from-minibuffer prompt choices)) + (setq answer (read-char-choice prompt choices)) (cond ((memq answer '(?? ?\C-h)) (ask-user-about-supersession-help) (setq answer nil)) diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el index 8250316bcc..bb5d26d29e 100644 --- a/lisp/wid-edit.el +++ b/lisp/wid-edit.el @@ -338,7 +338,7 @@ widget-choose '(display-buffer-in-direction (direction . bottom) (window-height . fit-window-to-buffer))) - (setq value (read-char-from-minibuffer + (setq value (read-char-choice (format "%s: " title) (mapcar #'car alist))))) (cdr (assoc value alist))))))
[-- Attachment #1: Type: text/plain, Size: 240 bytes --] > And while we're there we could also try to relieve some of our .emacs > files (mine included) of those > > (defalias 'yes-or-no-p 'y-or-n-p) > > by providing an option that accomplishes the necessary mapping. Maybe something like this: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: use-short-answers.patch --] [-- Type: text/x-diff, Size: 1193 bytes --] diff --git a/lisp/cus-start.el b/lisp/cus-start.el index 2e8872341f..4376f9835e 100644 --- a/lisp/cus-start.el +++ b/lisp/cus-start.el @@ -302,6 +302,7 @@ minibuffer-prompt-properties--setter ;; fns.c (use-dialog-box menu boolean "21.1") (use-file-dialog menu boolean "22.1") + (use-short-answers menu boolean "28.1") (focus-follows-mouse frames (choice (const :tag "Off (nil)" :value nil) diff --git a/src/fns.c b/src/fns.c index 2de1d26dd3..128bd7af55 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2873,6 +2873,11 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0, return obj; } + if (use_short_answers) + { + return call1 (intern ("y-or-n-p"), prompt); + } + AUTO_STRING (yes_or_no, "(yes or no) "); prompt = CALLN (Fconcat, prompt, yes_or_no); @@ -5791,6 +5796,10 @@ syms_of_fns (void) this variable. */); use_file_dialog = true; + DEFVAR_BOOL ("use-short-answers", use_short_answers, + doc: /* Non-nil means `yes-or-no-p' uses shorter answers "y" or "n". */); + use_short_answers = false; + defsubr (&Sidentity); defsubr (&Srandom); defsubr (&Slength);
> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org, rudalics@gmx.at, rms@gnu.org
> Date: Mon, 28 Dec 2020 19:06:32 +0200
>
> Here is the first version of the patch for master. If generally it's OK,
> then it could be backported to Emacs 27.2:
Richard, can you please try this and tell if it gives good results?
Thanks.
> Maybe something like this: It's a bit more than just Non-nil means `yes-or-no-p' uses shorter answers "y" or "n". because short circuiting it to 'y-or-n-p' means it will also obey 'y-or-n-p-use-read-key'. martin
>> Here is the first version of the patch for master. If generally it's OK,
>> then it could be backported to Emacs 27.2:
>
> Richard, can you please try this and tell if it gives good results?
This is installed now in master, so Richard could try this.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > This is installed now in master, so Richard could try this. On Dec 31 I pulled master and built it. But I don't see any sign in it of code to read answers in the old way. I will test with that patch. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > This is installed now in master, so Richard could try this. It does not seem to be installed. On Dec 31 I did git pull and built it. But I don't see any sign in it of code to read answers in the old way. I will install that patch here and test it. I didn't mean to ask people to rush to install it -- I didn't think it was a hurry, so I just asked to be informed when it did get installed. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > This is installed now in master, so Richard could try this. It seems to work. I think that y-or-n-p-use-read-key should default to t. There is no hurry about making this change. After this is included in a release, we can ask users to try the value t for a week or two and tell us whether they like it. Then we can tell which default is best. By the way, I didn't mean to ask people to rush to install it -- I didn't think it was a hurry, so I just asked to be informed when it did get installed. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> From: Richard Stallman <rms@gnu.org> > Cc: eliz@gnu.org, rudalics@gmx.at, emacs-devel@gnu.org > Date: Sat, 02 Jan 2021 00:25:37 -0500 > > I think that y-or-n-p-use-read-key should default to t. > There is no hurry about making this change. Personally, I won't mind reversing the default, FWIW. > After this is included in a release, we can ask users > to try the value t for a week or two and tell us whether they like it. > Then we can tell which default is best. This is not practical, IME. Adoption of a new release by users is very slow; I wouldn't be surprised if a year passed before major distros made a new release their main one. E.g., we are still getting bug reports from people who use Emacs 25 and even 24, let alone 26, although Emacs 27.1 was released 5 months ago. So waiting for user reports could take a year or more, and by that time we will probably have the next minor release, so the setting becomes the de-facto standard that will be harder to change back. That is why changes in behavior are usually accompanied by a documented (in NEWS) way of getting the old behavior back. This way, users who want the old behavior can silently do that locally, and only very annoying behavior changes generate so many bug reports that we later consider reverting it.
Eli Zaretskii <eliz@gnu.org> writes: >> I think that y-or-n-p-use-read-key should default to t. >> There is no hurry about making this change. > > Personally, I won't mind reversing the default, FWIW. I think reversing the default would be less than optimal for two reasons: 1) The new behaviour is in Emacs 27, and flopping back to the Emacs 26 behaviour just sounds confusing, and 2) I think Emacs (by default) should avoid being "modal". Not being able to change buffers on a y-or-n-p question makes it differ from how Emacs behaves in almost all other circumstances, which makes it inconsistent. But those who prefer that behaviour, like Richard, now has an option to get that back. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I wrote > On Dec 31 I pulled master and built it. But I don't see any sign > in it of code to read answers in the old way. but later I found the code and tried it. It worked. Sometimes I "send" multiple versions of a message. Since they are only "sent" into a directory of files, which I will review later before going to bed. I don't worry about this; I figure I will delete the old versions. Last night I was falling asleep in my chair and didn't review them carefully enough. I apologize for the confusion. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> >> I think that y-or-n-p-use-read-key should default to t. > >> There is no hurry about making this change. > > > > Personally, I won't mind reversing the default, FWIW. > > I think reversing the default would be less than optimal for two > reasons: 1) The new behaviour is in Emacs 27, and flopping back to the > Emacs 26 behaviour just sounds confusing See - that's the problem with saying that Emacs can just go ahead and change stuff, because we can always backtrack later. The cement overshoes start to harden immediately. People then make arguments like that one: it's already been released, so we shouldn't, or we can't, change it back. "Less than optimal." "That ship has already sailed." "The horse is already out of the barn." > I think Emacs (by default) should avoid being > "modal". Not being able to change buffers on > a y-or-n-p question makes it differ from how > Emacs behaves in almost all other > circumstances, which makes it inconsistent. Yes, "almost all other". Emacs has _always_ been inconsistent in that way - by design. Emacs has always been modal in contexts where it's important to require an immediate answer, e.g. a confirmation. That's always been a general exception. ___ But note the difference with `yes-or-no-p'. On the one hand, it requires more typing, inviting more attention and limiting accidental mischoice. On the other hand, it does _not_ prevent delaying a response and performing other actions. Consider changing to another buffer, opening another file,getting some help, etc., while confirmation awaits: (let ((enable-recursive-minibuffers t)) (yes-or-no-p "Are you sure? ")) ___ Beyond that, what you say there, which I agree with as a general rule, flies in the face of recent _big_ changes wrt preventing keeping the minibuffer active, changing focus somewhere else, doing other stuff, and coming back to the minibuffer (or never coming back: `C-g'). That kind of interaction is super-important to my own use of Emacs. Now it's been impeded. Imposing a predetermined rule about focusing, making hard-coded assumptions about minibuffer interaction, prevents users from changing focus the way they want, and so doing what they want. It was wrong to assume that minibuffer interaction always follows, and should follow, some single, rigid pattern. On l'a niqué, le pauvre minibuffer. As a general rule, the minibuffer should not, in any way, be forced to be modal - wrt its focus or anything else. Not by default - modal behavior can be programmed for it, but that shouldn't be part of its general design.
> Date: Sat, 2 Jan 2021 09:06:55 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rudalics@gmx.at, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
>
> > I think reversing the default would be less than optimal for two
> > reasons: 1) The new behaviour is in Emacs 27, and flopping back to the
> > Emacs 26 behaviour just sounds confusing
>
> See - that's the problem with saying that Emacs
> can just go ahead and change stuff, because we
> can always backtrack later.
No one has said that, you are bringing up a strawman.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > ) The new behaviour is in Emacs 27, That change was released just a few months ago. So let's ask the users whether they like it. and flopping back to the > Emacs 26 behaviour just sounds confusing, Making the change was the potentially confusing step. We must be ready to reverse a change if people prefer the old way. Any argument which leads to the conclusion that we should be reluctant to do that is a reductio ad absurdam. If the users like this change, we should keep it. If they don't, we should revert it. Would someone be willing to run a poll about this? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Since y-or-n-p-use-read-key affects more than just y-or-n-p, perhaps it should be renamed to indicate that. I propose the name single-key-answers. but I am not entirely happy with it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > After this is included in a release, we can ask users > > to try the value t for a week or two and tell us whether they like it. > > Then we can tell which default is best. > This is not practical, IME. I beg to differ. Adoption of a new release by users is > very slow; I wouldn't be surprised if a year passed before major > distros made a new release their main one. E.g., we are still getting > bug reports from people who use Emacs 25 and even 24, let alone 26, > although Emacs 27.1 was released 5 months ago. That is true, but it may not be a problem. To get useful results, we don't need most of the community to switch. It is enough to get answers from a variety of users. I suggested asking users to try the value t for a week or two. (See quotation above.) That means, a user should not be too quick to reject the new setting; give the new feature a try for 10-15 days to see if it grows on you. Likewise, we should not be in a hurry about getting the answers. We can wait a few months if necessary while accumulating users' responses. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > I think reversing the default would be less than optimal for two > > reasons: 1) The new behaviour is in Emacs 27, and flopping back to the > > Emacs 26 behaviour just sounds confusing > See - that's the problem with saying that Emacs > can just go ahead and change stuff, because we > can always backtrack later. Your response is stated in a somewhat flip tone, but its point is valid. As you've stated, there is a lot of resistance to changing back. The dynamic that results is this: * A few people decide to make a UI change, which many have not noticed. * Some people eventually notice it in master, or in a release, and maybe people start objecting. * At that point there is resistance to changing back. The end result is a tendency to make changes because a few people are in favor of them, and then it is hard to avoid them. Here is how I think it should work. * A few people decide to make a UI change, which many have not noticed. * Someone points out that such a change should be discussed on emacs-devel. So they do that, before installation. * If some are opposed, they install the feature with a variable to enable it, disabled by default. * Some time later -- it need not be soon -- poll the users and see who likes it _and why_. Maybe change the default. This will (1) eliminate the bad dynamic, (2) result in installing these features quickly but with a variable to enable, and (3) in a reasonable period adopt a default based on knowing who likes the feature. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, emacs-devel@gnu.org, juri@linkov.net > Date: Sun, 03 Jan 2021 01:03:00 -0500 > > > > After this is included in a release, we can ask users > > > to try the value t for a week or two and tell us whether they like it. > > > Then we can tell which default is best. > > Adoption of a new release by users is > > very slow; I wouldn't be surprised if a year passed before major > > distros made a new release their main one. E.g., we are still getting > > bug reports from people who use Emacs 25 and even 24, let alone 26, > > although Emacs 27.1 was released 5 months ago. > > That is true, but it may not be a problem. To get useful results, we > don't need most of the community to switch. It is enough to get > answers from a variety of users. Which users should they be, and how do we find them and reach out to them? They should definitely be users who have the just-released version installed, which is why I mentioned the observation that the process of upgrading to a new version is slow and takes many moons. > Likewise, we should not be in a hurry about getting the answers. We > can wait a few months if necessary while accumulating users' > responses. Let's say we have half a dozen of such features, and we need to wait for the answers for a few months about each one of them. Who can have a long enough attention span to manage such a polling system? who can keep track of all those features even though we could switch branches and release a couple of versions in-between? If someone volunteers to do the job, then I'm okay with trying that, although I'm skeptical as to success chances. If no one volunteers, I don't see how we could do something like that. We don't even have a forum for conducting such polls, let alone a tried and working procedure.
> From: Richard Stallman <rms@gnu.org> > Cc: larsi@gnus.org, eliz@gnu.org, rudalics@gmx.at, > emacs-devel@gnu.org, juri@linkov.net > Date: Sun, 03 Jan 2021 01:06:18 -0500 > > The dynamic that results is this: > > * A few people decide to make a UI change, which many have not noticed. > > * Some people eventually notice it in master, or in a release, and maybe > people start objecting. > > * At that point there is resistance to changing back. The resistance is understandable, but when this happens on master, and the objections are valid and supported by enough people, we usually augment or revert the change. When this happens in a released version, the resistance is justifiably stronger. But those cases should be (and are, IME) very rare. > The end result is a tendency to make changes because a few people > are in favor of them, and then it is hard to avoid them. There's no need and no justification for such generalizations based on a single incident. The adverse results you describe are extremely rare in practice. In some cases (some people say too many) the situation is actually the exact opposite: changes are being discussed "to death" and sometimes never implemented due to controversy. However, most changes are discussed by suitable groups of people, the various opinions are heard, and we usually try to accommodate them in the solution that is actually installed. So there's no need to present an isolated and exceptional incident as if it were the rule. > * A few people decide to make a UI change, which many have not noticed. > > * Someone points out that such a change should be discussed on > emacs-devel. So they do that, before installation. That is being done already, where we see it necessary. However, I see no reason to single out emacs-devel as the only medium suitable for such discussions. The Emacs issue tracker is another valid medium for that. Some changes are so significant that we do indeed decide to move them to emacs-devel, but I see no reason to do that for every behavior change. Moving a discussion has its downsides: depending on your MUA you can lose the threading capabilities; some people fail to notice and continue sending messages to the bug list; some people start cross-posting to both lists and thus increase the noise level; future forensics will be harder because references to discussions on emacs-devel are incomplete; etc. Thus, we insist on moving the discussions to emacs-devel only for significant enough issues -- and which ones are significant is a judgment call. > * If some are opposed, they install the feature with a variable to > enable it, disabled by default. This is already being done: every backward-incompatible change is either required to become compatible, or, if that's not feasible, to provide a way to get back the old behavior. In some rare cases this doesn't happen, but such mistakes are rare exceptions, they aren't the rule. > * Some time later -- it need not be soon -- poll the users and see who > likes it _and why_. Maybe change the default. Volunteers are welcome to step forward and take upon themselves the responsibilities for conducting such polls. Failing that, I don't see how we can promise doing this as a matter of routine.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > When this happens in a released version, the resistance is justifiably > stronger. But those cases should be (and are, IME) very rare. My point is that they are not so rare -- there is a systematic tendency for that to happen. I am proposing a systematic way to make them less likely, by helping people take notice that a UI change is being proposed, so they can object quickly. > situation is actually the exact opposite: changes are being discussed > "to death" and sometimes never implemented due to controversy. My proposal will help with that problem too. Instead of waiting for a resolution of the dispute, we should install the change with a user option variable to enable the new behavior. That bypasss the dispute. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > However, I see no reason to single out emacs-devel as the only medium > suitable for such discussions. The Emacs issue tracker is another > valid medium for that. It may be "valid" in principle, but it is no a wise choice for changes in the Emacs command interface. If we want to be confident that users will notice plans for changes, and say if they object, before the change is in a release, we are obliged to help users notice. > > * Some time later -- it need not be soon -- poll the users and see who > > likes it _and why_. Maybe change the default. > Volunteers are welcome to step forward and take upon themselves the > responsibilities for conducting such polls. Failing that, I don't see > how we can promise doing this as a matter of routine. That's not difficult. People who want to make the new behavior the default will be motivated to conduct the inquiry. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> I am proposing a systematic way to make them less likely, by helping
> people take notice that a UI change is being proposed, so they can
> object quickly.
In most cases, the reaction to UI changes is to complain about the
change because it's ... different. That makes for very poor arguments,
*especially* when the change is discussed without people having actually
tried it out for a while to see how it plays out in practice after the
initial "bump".
So, IMO always discussing such changes before implementing the change
may be systematic but it is definitely not the best solution.
Stefan
> That's not difficult. People who want to make the new behavior the default
> will be motivated to conduct the inquiry.
More likely, they'll just be discouraged to contribute and will focus on
Spacemacs, Doom, etc... instead.
Stefan
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I am proposing a systematic way to make them less likely, by helping
>> people take notice that a UI change is being proposed, so they can
>> object quickly.
>
> In most cases, the reaction to UI changes is to complain about the
> change because it's ... different. That makes for very poor arguments,
> *especially* when the change is discussed without people having actually
> tried it out for a while to see how it plays out in practice after the
> initial "bump".
>
> So, IMO always discussing such changes before implementing the change
> may be systematic but it is definitely not the best solution.
I agree completely.
To my mind, people running the bleeding edge (i.e. master) also
implicitly agree to test out new feature changes before they are
released. So here's a suggestion: perhaps we should think about
sometimes carrying out time-boxed experiments on the master branch in
controversial cases. For example: we add this keybinding now, to be
revisited in 14/21/30 days and then a final discussion is taken to keep
or revert it once people have gotten some experience with it.
I think this could work better than encouraging people to apply patches
or use a branch, since the people opposing them are less likely to do
so. (And anyone who *really* don't want to participate can of course
still just revert that commit locally and carry on as before until the
experiment is over.)
This should be in the interest also of opponents of the change. They
now have a very strong argument against discussing it further: "we tried
it on master and it was very unpopular so please don't beat this dead
horse".
(Of course, this would require people to also keep an open mind and a
willingness to change, or it will just be automatically shot down in the
next round of discussions. Not sure what, if anything, can be done
about that.)
Richard Stallman <rms@gnu.org> writes: > I am proposing a systematic way to make them less likely, by helping > people take notice that a UI change is being proposed, so they can > object quickly. Three out of five Emacs maintainers have now weighed in (at some length, in total), that they don't think your proposal would be helpful in practice, so I think it's time to let this go. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
> To my mind, people running the bleeding edge (i.e. master) also > implicitly agree to test out new feature changes before they are > released. So here's a suggestion: perhaps we should think about > sometimes carrying out time-boxed experiments on the master branch in > controversial cases. For example: we add this keybinding now, to be > revisited in 14/21/30 days and then a final discussion is taken to keep > or revert it once people have gotten some experience with it. I tried that once when I wanted people to test whether horizontal scroll bars work on their machines. It didn't take long to read the first "gentle" request on this list about how to switch them off ... martin
martin rudalics <rudalics@gmx.at> writes: > I tried that once when I wanted people to test whether horizontal scroll > bars work on their machines. It didn't take long to read the first "gentle" > request on this list about how to switch them off ... I hope you gently told them where to go. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
>> I tried that once when I wanted people to test whether horizontal scroll >> bars work on their machines. It didn't take long to read the first "gentle" >> request on this list about how to switch them off ... > > I hope you gently told them where to go. :-) I told them how to switch them off - they didn't even bother to look for the knob themselves. But it taught me the lesson to never ever try such a thing again. The toughest resistance always comes from veterans and fellow developers ... martin
>> The dynamic that results is this: >> >> * A few people decide to make a UI change, which many have not noticed. >> >> * Some people eventually notice it in master, or in a release, and >> maybe people start objecting. >> >> * At that point there is resistance to changing back. > > The resistance is understandable, but when this happens on master, and > the objections are valid and supported by enough people, we usually > augment or revert the change. > I don't think it's "enough people"; it is, rather, "important enough people" ;-) >> * If some are opposed, they install the feature with a variable to >> enable it, disabled by default. > > This is already being done: every backward-incompatible change is either > required to become compatible, or, if that's not feasible, to provide a > way to get back the old behavior. In some rare cases this doesn't > happen, but such mistakes are rare exceptions, they aren't the rule. > That's not correct, see for example the thread "Stop frames stealing eachothers' minibuffers!", in which the longstanding behavior of Emacs' minibuffers, which are arguably a central piece of Emacs' UI, is being modified on the pretext that it is "unsystematic", without any argument, and in spite of the fact that hundreds and thousands of users have been using it without complaining about that supposed "unsystematicity". I repeatedly explained that the old behavior should remain available. Initially the change explicitly removed the old behavior: "The old [behavior] is no longer available." The latest patch sent yesterday, only promises to "approximate" the old behavior.
>> I am proposing a systematic way to make them less likely, by helping
>> people take notice that a UI change is being proposed, so they can
>> object quickly.
>
> In most cases, the reaction to UI changes is to complain about the
> change because it's ... different. That makes for very poor arguments,
> *especially* when the change is discussed without people having actually
> tried it out for a while to see how it plays out in practice after the
> initial "bump".
>
I agree with you, but I think you are missing Richard's main point: any
significant UI change should either require setting a variable, or provide
a way to disable the new behavior / re-enable to old behavior. Because it
is always possible that, after having actually tried out a new behavior
for a while, people dislike it. For example because they use Emacs in a
way that was not envisioned by the developer who implemented the UI
change, and that this UI change breaks their configuration, which relied
on the old behavior.
I can't speak for everyone, but I think one of the reasons people use and
like Emacs is that it is stable. Breaking its stability unavoidably
creates frictions.
An simple and good example is the :extend attribute, which was added in
Emacs 27. People who liked the old behavior simply had to add an ":extend
t" attribute to a number of faces in their configuration, and that's all.
Hello, Gregory. On Mon, Jan 04, 2021 at 10:28:25 +0000, Gregory Heytings via Emacs development discussions. wrote: > >> The dynamic that results is this: > >> * A few people decide to make a UI change, which many have not noticed. > >> * Some people eventually notice it in master, or in a release, and > >> maybe people start objecting. > >> * At that point there is resistance to changing back. > > The resistance is understandable, but when this happens on master, and > > the objections are valid and supported by enough people, we usually > > augment or revert the change. > I don't think it's "enough people"; it is, rather, "important enough > people" ;-) > >> * If some are opposed, they install the feature with a variable to > >> enable it, disabled by default. > > This is already being done: every backward-incompatible change is either > > required to become compatible, or, if that's not feasible, to provide a > > way to get back the old behavior. In some rare cases this doesn't > > happen, but such mistakes are rare exceptions, they aren't the rule. > That's not correct, see for example the thread "Stop frames stealing > eachothers' minibuffers!", in which the longstanding behavior of Emacs' > minibuffers, which are arguably a central piece of Emacs' UI, is being > modified on the pretext that it is "unsystematic", without any argument, > and in spite of the fact that hundreds and thousands of users have been > using it without complaining about that supposed "unsystematicity". There has been argument, on that other thread, which you have taken part in, and which now extends to nearly 200 posts. That few people complained about the old behaviour is not a strong argument against improving it. Many improvements to Emacs are made without being prompted by widespread complaints. > I repeatedly explained that the old behavior should remain available. > Initially the change explicitly removed the old behavior: "The old > [behavior] is no longer available." The latest patch sent yesterday, only > promises to "approximate" the old behavior. It would thus appear that you are an "important enough person". I put the old behaviour back as a result of your representations, despite not understanding why anybody might want it. However, since I've tidied up the C code appreciably, I cannot guarantee that this behaviour is 100% the same as the old, hence the use of the word "approximate". Have you tried this patch out, yet? If there is anything in the "approximation" which is not close enough, perhaps you could point out what, so that I might fix it. Thanks! -- Alan Mackenzie (Nuremberg, Germany).
martin rudalics <rudalics@gmx.at> writes:
>>> I tried that once when I wanted people to test whether horizontal scroll
>>> bars work on their machines. It didn't take long to read the first "gentle"
>>> request on this list about how to switch them off ...
>>
>> I hope you gently told them where to go. :-)
>
> I told them how to switch them off - they didn't even bother to look for
> the knob themselves. But it taught me the lesson to never ever try such
> a thing again. The toughest resistance always comes from veterans and
> fellow developers ...
My 2 cents,
I may be wrong but to my observation the toughest resistance comes
typically from few veterans who hardly ever wrote a patch, not
developers. Given the day is 24H people doing development just can't
physically commit all this time arguing for one way or the other for
sustained periods of time.
The result is that often developers just (sadly) fall back on writing
patches as this is perceived to be more useful.
Andrea
>> That's not correct, see for example the thread "Stop frames stealing >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' >> minibuffers, which are arguably a central piece of Emacs' UI, is being >> modified on the pretext that it is "unsystematic", without any >> argument, and in spite of the fact that hundreds and thousands of users >> have been using it without complaining about that supposed >> "unsystematicity". > > There has been argument, on that other thread, which you have taken part > in, and which now extends to nearly 200 posts. > I haven't seen a single argument in that thread to remove the current behavior. I've only seen an argument that you (and only you AFAICS) don't like it. > > That few people complained about the old behaviour is not a strong > argument against improving it. Many improvements to Emacs are made > without being prompted by widespread complaints. > I never ever objected the idea of improving the minibuffer behavior. I strongly objected the idea of removing its longstanding behavior. >> I repeatedly explained that the old behavior should remain available. >> Initially the change explicitly removed the old behavior: "The old >> [behavior] is no longer available." The latest patch sent yesterday, >> only promises to "approximate" the old behavior. > > It would thus appear that you are an "important enough person". > No, quite the contrary. > > I put the old behaviour back as a result of your representations, > despite not understanding why anybody might want it. > That's the problem I mentioned in my other email: "because [some users] use Emacs in a way that was not envisioned by the developer who implemented the UI change, and that this UI change breaks their configuration, which relied on the old behavior". We cannot know what kind of exotic things people do with Emacs, and the only way to ensure that it is stable is to keep the old behavior alongside the new one, at least for some time. Some time later (one or two major releases later, say) the old behavior can of course be deprecated, with a target release when this will happen. That gives users the time to adapt their libraries and configurations. But all of a sudden removing the old behavior and installing a new one is IMO wrong. > > However, since I've tidied up the C code appreciably, I cannot guarantee > that this behaviour is 100% the same as the old, hence the use of the > word "approximate". > > Have you tried this patch out, yet? If there is anything in the > "approximation" which is not close enough, perhaps you could point out > what, so that I might fix it. Thanks! > Not yet, I'll do that, but can't promise when. But the problem is that I am now, and everybody else is now, in a situation where we have to spend a lot of time testing various combinations of commands and to describe what doesn't work anymore, which inevitably leads to very long and boring mails and discussions.
Hello, Gregory. On Mon, Jan 04, 2021 at 11:35:19 +0000, Gregory Heytings via Emacs development discussions. wrote: > >> That's not correct, see for example the thread "Stop frames stealing > >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' > >> minibuffers, which are arguably a central piece of Emacs' UI, is being > >> modified on the pretext that it is "unsystematic", without any > >> argument, and in spite of the fact that hundreds and thousands of users > >> have been using it without complaining about that supposed > >> "unsystematicity". > > There has been argument, on that other thread, which you have taken part > > in, and which now extends to nearly 200 posts. > I haven't seen a single argument in that thread to remove the current > behavior. I've only seen an argument that you (and only you AFAICS) don't > like it. I suggest you reread that thread, long though it is, with some care. There were strong arguments expressed there, for improving the then current behaviour. > > That few people complained about the old behaviour is not a strong > > argument against improving it. Many improvements to Emacs are made > > without being prompted by widespread complaints. > I never ever objected the idea of improving the minibuffer behavior. I > strongly objected the idea of removing its longstanding behavior. As I have just said, your objections have been taken into account and acted upon. I don't really want to get drawn here into detailled discussion which really belongs on that other thread, but would point out that that "longstanding behaviour" which you seem so attached to appears to be an ad hoc unsystematic mess resulting from a lack of systematic attention. I have now given it that attention. > >> I repeatedly explained that the old behavior should remain available. > >> Initially the change explicitly removed the old behavior: "The old > >> [behavior] is no longer available." The latest patch sent yesterday, > >> only promises to "approximate" the old behavior. > > It would thus appear that you are an "important enough person". > No, quite the contrary. Forgive me if I become uncustomarily blunt and personal, but it seems you are determined to find the worst possible interpretation of everything, and your replies to so many posts take on an unusually negative tone. I put the old behaviour back specifically to please you and others like you, yet your reaction, rather than to thank me, is to criticise that it is "only an approximation". And that before you have even tried it out. Dealing with such negativity is an emotionally draining experience for me, and I suspect I am not alone here. One way of coping with this would be to ignore your posts entirely, but I don't want to do that. Would you please try to be more positive in your posts, and try to work together with people to achieve goals, rather than antagonising them. Thanks! > > I put the old behaviour back as a result of your representations, > > despite not understanding why anybody might want it. > That's the problem I mentioned in my other email: "because [some users] > use Emacs in a way that was not envisioned by the developer who > implemented the UI change, and that this UI change breaks their > configuration, which relied on the old behavior". We cannot know what > kind of exotic things people do with Emacs, and the only way to ensure > that it is stable is to keep the old behavior alongside the new one, at > least for some time. Some time later (one or two major releases later, > say) the old behavior can of course be deprecated, with a target release > when this will happen. That gives users the time to adapt their libraries > and configurations. But all of a sudden removing the old behavior and > installing a new one is IMO wrong. The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy even of being called a behaviour. > > However, since I've tidied up the C code appreciably, I cannot guarantee > > that this behaviour is 100% the same as the old, hence the use of the > > word "approximate". > > Have you tried this patch out, yet? If there is anything in the > > "approximation" which is not close enough, perhaps you could point out > > what, so that I might fix it. Thanks! > Not yet, I'll do that, but can't promise when. But the problem is that I > am now, and everybody else is now, in a situation where we have to spend a > lot of time testing various combinations of commands and to describe what > doesn't work anymore, which inevitably leads to very long and boring mails > and discussions. How is that a problem? Nobody is forcing you into such discussions. At the cutting edge of development, there are bound to be new things, there are bound to be old things let go, and there are bound to be controversies. That is the very essence of development. People are grateful for the feedback you give, but nobody is forcing you into doing anything. -- Alan Mackenzie (Nuremberg, Germany).
>> I haven't seen a single argument in that thread to remove the current >> behavior. I've only seen an argument that you (and only you AFAICS) >> don't like it. > > I suggest you reread that thread, long though it is, with some care. > There were strong arguments expressed there, for improving the then > current behaviour. > There are arguments to _improve_ the current behavior, that is, to provide other behaviors, and I agree with these arguments. But there are no arguments to _remove_ the current behavior, which should either remain the default or be available by setting a variable. > > Forgive me if I become uncustomarily blunt and personal, but it seems > you are determined to find the worst possible interpretation of > everything, and your replies to so many posts take on an unusually > negative tone. > That was not at all my intention, I'm sorry if you have perceived it as such. > > Would you please try to be more positive in your posts, and try to work > together with people to achieve goals, rather than antagonising them. > Thanks! > I believe that's what I did, I initially pointed you the difference between the use of the echo area and the minibuffer inside isearch, I gave you a number of possible improved behaviors, and I already spend quite some time testing your patch and providing you with feedback. I don't think this can be considered as an "antagonising" behavior. > > I don't really want to get drawn here into detailled discussion which > really belongs on that other thread, but would point out that that > "longstanding behaviour" which you seem so attached to appears to be an > ad hoc unsystematic mess resulting from a lack of systematic attention. > [...] > The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy > even of being called a behaviour. > These are very strong statements. I understand that this is what it seems to you, and I would even say that to a certain extent I agree with you, but again, you don't know whether others rely on what you consider to be a mess in their libraries or configurations. >> But the problem is that I am now, and everybody else is now, in a >> situation where we have to spend a lot of time testing various >> combinations of commands and to describe what doesn't work anymore, >> which inevitably leads to very long and boring mails and discussions. > > How is that a problem? Nobody is forcing you into such discussions. > At the cutting edge of development, there are bound to be new things, > there are bound to be old things let go, and there are bound to be > controversies. That is the very essence of development. People are > grateful for the feedback you give, but nobody is forcing you into doing > anything. > I don't feel forced to do anything. I was only pointing the fact that those who object the removal of a behavior are in a position that their feedback will look like bikeshedding. This would not happen if the old behavior remained available; the discussion would then be more constructive, around the question "what is the best default behavior".
On 04.01.2021 11:55, martin rudalics wrote:
> The toughest resistance always comes from veterans and
> fellow developers ...
Then that's part of the culture that we'll need to change, to be able to
enact changes and test them well.
Perhaps if there is a general understanding that any new feature or
change added to master have a trial period and won't necessarily stay
with us, the feedback will be more reserved and more constructive.
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, larsi@gnus.org, juri@linkov.net, > drew.adams@oracle.com, emacs-devel@gnu.org > Date: Mon, 04 Jan 2021 00:16:55 -0500 > > > When this happens in a released version, the resistance is justifiably > > stronger. But those cases should be (and are, IME) very rare. > > My point is that they are not so rare -- there is a systematic tendency > for that to happen. What is the basis for your impression that such a tendency exists? Any cases besides this single one? "Systematic" is a pretty strong word in this context, it would mean we make backward-incompatible changes basically all the time. I don't have such an impression. In fact, we are frequently accused in the opposite: that we change the defaults too slowly. > I am proposing a systematic way to make them less likely, by helping > people take notice that a UI change is being proposed, so they can > object quickly. We need to consider the cost of your proposal as well as its benefits. I think the costs are too high, given the scarcity of the problems the proposal aims at fixing, the significant effort it will impose on the head maintainers, and the adverse effect on development pace. > > situation is actually the exact opposite: changes are being discussed > > "to death" and sometimes never implemented due to controversy. > > My proposal will help with that problem too. Instead of waiting for a > resolution of the dispute, we should install the change with a user > option variable to enable the new behavior. That is already happening where the change seems to be controversial or a too radical departure from long-time behavior. > That bypasss the dispute. It doesn't. At best, it just changes the subject of the dispute to whether the new behavior should be the default. At worst, people keep arguing about the necessity of the change, even though it can be disabled. I didn't bring up this particular aspect to complain about it, because complaining about it in an open project where development discussions are public is pointless: anyone can start a discussion about any issue related to Emacs, and we allow and encourage that as part of our policy. I brought that up to point out that some -- quite a few -- opine that we have too many discussions already. Which in my view means we have a balanced situation: some think we have too few discussions, others think we have too many. Increasing the discussion will thus tilt the balance -- not necessarily for the better.
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, larsi@gnus.org, juri@linkov.net, > drew.adams@oracle.com, emacs-devel@gnu.org > Date: Mon, 04 Jan 2021 00:17:28 -0500 > > > However, I see no reason to single out emacs-devel as the only medium > > suitable for such discussions. The Emacs issue tracker is another > > valid medium for that. > > It may be "valid" in principle, but it is no a wise choice for changes > in the Emacs command interface. If we want to be confident that users > will notice plans for changes, and say if they object, before the > change is in a release, we are obliged to help users notice. Users don't track emacs-devel, either. In fact, most users nowadays don't like to use mailing lists at all. Moreover, the effect of a change is not necessarily clear from the discussions, not unless the reader knows enough about Emacs internals. So I don't see how forcing discussions to happen on emacs-devel will reach the goal of helping users notice important changes and object in time. It might help you personally, and a few others, but that's a far cry from "users", IMO. > > > * Some time later -- it need not be soon -- poll the users and see who > > > likes it _and why_. Maybe change the default. > > > Volunteers are welcome to step forward and take upon themselves the > > responsibilities for conducting such polls. Failing that, I don't see > > how we can promise doing this as a matter of routine. > > That's not difficult. People who want to make the new behavior the default > will be motivated to conduct the inquiry. If they are motivated enough, we don't need any rules for that, we just should continue behaving as we did, because starting a discussion on emacs-devel about any issue related to Emacs is always possible (and happens already).
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 4 Jan 2021 08:54:37 +0100
> Cc: juri@linkov.net, rudalics@gmx.at, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
> larsi@gnus.org, drew.adams@oracle.com
>
> [...] here's a suggestion: perhaps we should think about sometimes
> carrying out time-boxed experiments on the master branch in
> controversial cases. For example: we add this keybinding now, to be
> revisited in 14/21/30 days and then a final discussion is taken to
> keep or revert it once people have gotten some experience with it.
I don't mind having such a process, provided that someone volunteers
to manage it: identify and announce the relevant changes, keep track
of the time-box of each one of them, initiate a discussion when the
time is up, etc. It's a non-trivial amount of work.
Eli Zaretskii <eliz@gnu.org> writes: >> [...] here's a suggestion: perhaps we should think about sometimes >> carrying out time-boxed experiments on the master branch in >> controversial cases. For example: we add this keybinding now, to be >> revisited in 14/21/30 days and then a final discussion is taken to >> keep or revert it once people have gotten some experience with it. > > I don't mind having such a process, Me neither -- I think it sounds like something we should try out. > provided that someone volunteers to manage it: identify and announce > the relevant changes, keep track of the time-box of each one of them, > initiate a discussion when the time is up, etc. It's a non-trivial > amount of work. I think the most natural person to manage the process would be the person that's proposing the change. That is, we don't really need much formalism around this. To take the already-mentioned case as an example -- Martin wanted to have us try out horizontal scroll bars to see whether they work, so he'd flip them on, and announce on emacs-devel "these default to on for a week, and then we'll discuss". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
> Date: Mon, 04 Jan 2021 10:28:25 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: emacs-devel@gnu.org
>
> * If some are opposed, they install the feature with a variable to enable it, disabled by default.
>
> This is already being done: every backward-incompatible change is either required to become compatible, or, if that's not feasible, to provide a way to get back the old behavior. In some rare cases this doesn't happen, but such mistakes are rare exceptions, they aren't the rule.
>
> That's not correct, see for example the thread "Stop frames stealing eachothers' minibuffers!", in which the longstanding behavior of Emacs' minibuffers, which are arguably a central piece of Emacs' UI, is being modified on the pretext that it is "unsystematic", without any argument, and in spite of the fact that hundreds and thousands of users have been using it without complaining about that supposed "unsystematicity".
>
> I repeatedly explained that the old behavior should remain available. Initially the change explicitly removed the old behavior: "The old [behavior] is no longer available." The latest patch sent yesterday, only promises to "approximate" the old behavior.
That's because the original behavior was deemed buggy. We don't
provide compatibility options to get old bugs back.
As it turned out, what Alan considered buggy behavior was not
necessarily so, therefore he now tries to provide a better backward
compatibility. As the bug is still being actively worked on, it is
premature ti draw any definitive conclusions from it relevant to the
current discussion.
Also, we should recognize that some changes are deep enough to make
100% backward compatibility impractical or even infeasible. That
doesn't mean such changes should be automatically rejected.
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>, monnier@iro.umontreal.ca,
> rms@gnu.org, juri@linkov.net, rudalics@gmx.at, emacs-devel@gnu.org,
> drew.adams@oracle.com
> Date: Mon, 04 Jan 2021 16:17:46 +0100
>
> > provided that someone volunteers to manage it: identify and announce
> > the relevant changes, keep track of the time-box of each one of them,
> > initiate a discussion when the time is up, etc. It's a non-trivial
> > amount of work.
>
> I think the most natural person to manage the process would be the
> person that's proposing the change. That is, we don't really need much
> formalism around this.
I don't mind that, either, but what about people who submit changes,
but don't intend to stick around long enough to see this process
through? Someone will have to step in and do it for them.
>> I don't mind having such a process, > Me neither -- I think it sounds like something we should try out. Indeed, it's something we do on a regular basis, but we only do it for changes we presume won't be rejected. I think it would indeed be beneficial to change our habits in this regard and allow ourselves more "daring" changes, with the understanding that there is a higher probability that we may have to revert the default behavior. [ FWIW, I also think there are changes we should keep enabled only on `master` *until* they stop being unpopular. I'm specifically thinking of things like removal of obsolete features. E.g. we could have features obsolete since Emacs-25 removed from `master` right now, but with a way to get them back on-demand, and with the understanding that they will still be present in the Emacs-28 release. ] > I think the most natural person to manage the process would be the > person that's proposing the change. That is, we don't really need much > formalism around this. Agred. > To take the already-mentioned case as an example -- Martin wanted to > have us try out horizontal scroll bars to see whether they work, so he'd > flip them on, and announce on emacs-devel "these default to on for a > week, and then we'll discuss". IME a week is not sufficient: - Many users don't update from `master` on a daily basis. - I `git fetch` daily from `master`, but I don't restart my Emacs sessions all the time (hell, I just tried `M-x emacs-uptime` and this Gnus-dedicated session "says 184 days, 18 hours, 28 minutes, 38 seconds"). - Especially for UI changes (i.e. changes which don't break code but break muscle memory), it often takes a good month of active use before I can honestly say whether I prefer the old or the new behavior (rather than just being irked by the change itself). So I think such changes should be introduced with: - An explicit announcement. - A clear way to get back the old behavior. - A trial period in the order 2-3 months. Stefan
> To take the already-mentioned case as an example -- Martin wanted to > have us try out horizontal scroll bars to see whether they work, so he'd > flip them on, and announce on emacs-devel "these default to on for a > week, and then we'll discuss". That's a pipe dream. My announcement back then was: Note that horizontal scrollbars are turned on by default on all builds that support them. This is the only way I see to get them at least some initial coverage. If you utterly dislike them (or do not use scrollbars at all) please use the idiom (when (fboundp 'horizontal-scroll-bar-mode) (horizontal-scroll-bar-mode -1)) I intend to disable horizontal scrollbars by default in the next weeks. What could I have done more? martin
> Forgive me if I become uncustomarily blunt and personal, but it seems you > are determined to find the worst possible interpretation of everything, > and your replies to so many posts take on an unusually negative tone. Forgive me Alan but > The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy > even of being called a behaviour. has a rather negative tone too. Gregory provided some interesting insights into how Emacs did (mis-)behave in this regard and I think that they help us to soon see a state that satisfies most of us. martin
> I agree with you, but I think you are missing Richard's main point: any
> significant UI change should either require setting a variable, or provide
> a way to disable the new behavior / re-enable to old behavior.
I don't think that was Richard's point: we always go to great lengths to
make it possible to get back the old behavior (even for changes where
the impact is quite minor).
E.g. with respect to `y-or-n-p`, I think we already all agree that there
should be a way to recover the previous "modal" behavior. We just need
someone to implement it (ideally while still preserving the improvement
of the new minibuffer-based code).
Stefan
> E.g. with respect to `y-or-n-p`, I think we already all agree that there > should be a way to recover the previous "modal" behavior. We just need > someone to implement it (ideally while still preserving the improvement > of the new minibuffer-based code). IIUC Juri has done that in commit cd4a51695fddf2a76ae9ed71efa8bfb4a515b32e. martin
martin rudalics <rudalics@gmx.at> writes: > That's a pipe dream. My announcement back then was: > > Note that horizontal scrollbars are turned on by default on all builds > that support them. This is the only way I see to get them at least some > initial coverage. If you utterly dislike them (or do not use scrollbars > at all) please use the idiom > > (when (fboundp 'horizontal-scroll-bar-mode) > (horizontal-scroll-bar-mode -1)) > > I intend to disable horizontal scrollbars by default in the next weeks. > > What could I have done more? Hm. I must be missing something -- I skimmed the (quite long) "Changes in frame/window code" thread now, and I don't see any push-back on this? Just a lot of discussion about various glitches on various systems (which you seemed to fix very quickly)? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefankangas@gmail.com>,
> rms@gnu.org, juri@linkov.net, rudalics@gmx.at, emacs-devel@gnu.org,
> drew.adams@oracle.com
> Date: Mon, 04 Jan 2021 12:17:41 -0500
>
> [ FWIW, I also think there are changes we should keep enabled only on
> `master` *until* they stop being unpopular. I'm specifically
> thinking of things like removal of obsolete features. E.g. we could
> have features obsolete since Emacs-25 removed from `master` right
> now, but with a way to get them back on-demand, and with the
> understanding that they will still be present in the Emacs-28
> release. ]
AFAIU, this would need a more complicated procedure for cutting a
release branch: some commits would need to be reverted on the release
branch. How will we keep the record of those commits? And where is
the confidence that reverting a commit months after it was pushed will
not break Emacs, e.g. because some later commits depend on that?
Unless I completely misunderstand what you propose technically, I
think this idea is too hard to implement, at least as long as we have
only two active branches active at any given time.
> (And anyone who *really* don't want to participate can of course
> still just revert that commit locally and carry on as before until the
> experiment is over.)
No need to revert, there should be a variable, or some other way to disable it.
>> [ FWIW, I also think there are changes we should keep enabled only on
>> `master` *until* they stop being unpopular. I'm specifically
>> thinking of things like removal of obsolete features. E.g. we could
>> have features obsolete since Emacs-25 removed from `master` right
>> now, but with a way to get them back on-demand, and with the
>> understanding that they will still be present in the Emacs-28
>> release. ]
>
> AFAIU, this would need a more complicated procedure for cutting
> a release branch: some commits would need to be reverted on the
> release branch.
No, I was thinking of changing `make-obsolete` and friends so they
undefine (or refrain from defining) the function/variable. They could
do so by testing `emacs-version` (or some other way to detect the
`master` code) along with some extra config vars (e.g. a var to force
the behavior globally on way or the other or only for some
functions/variables).
I think this would require some finer control for variables, since it's
frequent for obsolete vars to still appear in the code (in order to
support code that makes use of that variable), but at least for
functions it should be quite straightforward.
It would definitely not require any special handling when cutting the
release branch or anything like that (since, as you point out, that
would be completely impractical).
Stefan
> Since y-or-n-p-use-read-key affects more than just y-or-n-p, > perhaps it should be renamed to indicate that. There is another variable that affects other cases: read-char-choice-use-read-key. > I propose the name single-key-answers. but I am not > entirely happy with it. Its name should be consistent with another variable use-short-answers that could be used to replace yes-or-no-p with y-or-n-p. These two should have names that preclude confusion between their meanings. Also use-short-answers could be used by the existing variable read-answer-short.
> That's a pipe dream. My announcement back then was: [...] > What could I have done more? Nothing. But if we together decide we want to encourage such experiments, then the reaction to people's complaints should provide better moral support to the implementer (you in this case) ;-) Stefan
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org, stefankangas@gmail.com, rms@gnu.org, juri@linkov.net,
> rudalics@gmx.at, emacs-devel@gnu.org, drew.adams@oracle.com
> Date: Mon, 04 Jan 2021 13:02:15 -0500
>
> I was thinking of changing `make-obsolete` and friends so they
> undefine (or refrain from defining) the function/variable. They could
> do so by testing `emacs-version` (or some other way to detect the
> `master` code) along with some extra config vars (e.g. a var to force
> the behavior globally on way or the other or only for some
> functions/variables).
That's fine, but then such a mechanism can handle only a small portion
of the changes that can be perceived as incompatible with past
behavior. For example, the change which started this thread cannot be
easily handled that way, because it is not about making something
obsolete.
Most of the changes we are talking about don't obsolete anything.
We should also consider the effects of this on code readability. It
is unexpected to have make-obsolete undefine its subject, let alone do
it or not depending on some under-the-hood magic.
> Hm. I must be missing something -- I skimmed the (quite long) "Changes > in frame/window code" thread now, and I don't see any push-back on this? > Just a lot of discussion about various glitches on various systems > (which you seemed to fix very quickly)? At least Bug#18167 comes to my mind. There were more complaints IIRC. martin
>>>> * If some are opposed, they install the feature with a variable to >>>> enable it, disabled by default. >>> >>> This is already being done: every backward-incompatible change is >>> either required to become compatible, or, if that's not feasible, to >>> provide a way to get back the old behavior. In some rare cases this >>> doesn't happen, but such mistakes are rare exceptions, they aren't the >>> rule. >> >> That's not correct, see for example the thread "Stop frames stealing >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' >> minibuffers, which are arguably a central piece of Emacs' UI, is being >> modified on the pretext that it is "unsystematic", without any >> argument, and in spite of the fact that hundreds and thousands of users >> have been using it without complaining about that supposed >> "unsystematicity". >> >> I repeatedly explained that the old behavior should remain available. >> Initially the change explicitly removed the old behavior: "The old >> [behavior] is no longer available." The latest patch sent yesterday, >> only promises to "approximate" the old behavior. > > That's because the original behavior was deemed buggy. We don't provide > compatibility options to get old bugs back. As it turned out, what Alan > considered buggy behavior was not necessarily so, therefore he now tries > to provide a better backward compatibility. > It did not "turn out", I explained in detail that the behavior that Alan considered buggy was not at all buggy before he started working on this. And I fear that trying to provide a better backward compatibility after having removed the code of the old behavior is doomed to fail, it will most likely result in an endless bug report / bug fix loop. > > As the bug is still being actively worked on, it is premature ti draw > any definitive conclusions from it relevant to the current discussion. > I do believe it is relevant. The general pattern is similar to the y-or-n-p one, in that the code of an UI behavior is removed and replaced by another one. It is also, I think (but it's just a feeling, I did not follow the discussions at that time), similar to the changes in Emacs 27 about which Drew loudly complained and that make Emacs 27 unuseable for him. What could have been done instead is to add some new code next to the existing one to conditionally provide a new behavior, with an easy way for users who prefer / need the old behavior to revert the change. If this had been done with y-or-n-p, this thread would simply not exist. If this had been done with the new minibuffer behavior, the "Stop frames stealing each other's minibuffers" thread would be very different. And the consequence of that pattern is what Richard fears: my comments, which can be summarized as "please do not remove the old behavior", are perceived by Alan almost as a personal attack. This would not happen if we were doing what Richard suggests.
>> I agree with you, but I think you are missing Richard's main point: any
>> significant UI change should either require setting a variable, or
>> provide a way to disable the new behavior / re-enable to old behavior.
>
> I don't think that was Richard's point: we always go to great lengths to
> make it possible to get back the old behavior (even for changes where
> the impact is quite minor).
>
> E.g. with respect to `y-or-n-p`, I think we already all agree that there
> should be a way to recover the previous "modal" behavior. We just need
> someone to implement it (ideally while still preserving the improvement
> of the new minibuffer-based code).
>
No always, alas. With respect to y-or-n-p, there is now indeed an
agreement that there should be a way to recover the old behavior. But
IIUC, Richard's point is that this possibility should have been present
since the beginning, when the new behavior was introduced, without waiting
for objections.
What happened is (1) behavior A is removed and replaced by behavior B, (2)
enough people object this change, (2) behavior B is implemented again.
What could have happened instead is (1) behavior B is implemented, next to
behavior A, with a way to choose between them, (2) at some point, possibly
immediately, the default behavior is changed from A to B, (3) if after
some time it becomes clear that behavior A is not used anymore, it is
deprecated, and later again removed.
Having both behaviors available at the same time is also, I believe, a
necessary condition for a fruitful comparison and discussion. Otherwise
the discussion is about the merits of a removed behavior vs. the new
behavior instead of about the merits of a behavior A vs. a behavior B.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > That is true, but it may not be a problem. To get useful results, we > > don't need most of the community to switch. It is enough to get > > answers from a variety of users. > Which users should they be, and how do we find them and reach out to > them? One obvious way is to post an announcement on various mailing lists, asking people to repost it. People will respond. > They should definitely be users who have the just-released version > installed, which is why I mentioned the observation that the process > of upgrading to a new version is slow and takes many moons. That's why I suggest waiting before we ask. > Let's say we have half a dozen of such features, and we need to wait > for the answers for a few months about each one of them. Who can have > a long enough attention span to manage such a polling system? I propose a distributed system which needs no management. The people who advocate changing the default to enable a given feature will probably speak up about it. We just need a rule about the minimum time to wait after the release. If they don't speak up, that suggests that having the new option is sufficient ;-}. > who can > keep track of all those features even though we could switch branches > and release a couple of versions in-between? Those little turns in the road won't intefere with their memory of where they want to go. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I agree with you, but I think you are missing Richard's main point: any > significant UI change should either require setting a variable, or provide > a way to disable the new behavior / re-enable to old behavior. Because it > is always possible that, after having actually tried out a new behavior > for a while, people dislike it. Yes, that is true. It is also possible that, after having actually tried out a new behavior for a while, people find they like it (although they expected beforehand they would not). The plan I propose will help us find out what people think of the feature after really trying it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > So here's a suggestion: perhaps we should think about > sometimes carrying out time-boxed experiments on the master branch in > controversial cases. For example: we add this keybinding now, to be > revisited in 14/21/30 days and then a final discussion is taken to keep > or revert it once people have gotten some experience with it. That's fine with me, but there should be a variable to enable the changed behavior. That makes the experiment painless for everyone else. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Three out of five Emacs maintainers have now weighed in (at some length, > in total), that they don't think your proposal would be helpful in > practice, so I think it's time to let this go. We can't "let it go". A combination of our practices adds up to a system that will install some UI changes without having much of a discussion about it. And then, once they are released, it is "too late" to argue to revert them. There are many ways we could fix this, but we need to fix it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > To my mind, people running the bleeding edge (i.e. master) also > implicitly agree to test out new feature changes before they are > released. It makes sense in principle. I am willing to experience the new feature changes before they are released. But I build the current master only a few times a year, so I don't see them all fast enough. > So here's a suggestion: perhaps we should think about > sometimes carrying out time-boxed experiments on the master branch in > controversial cases. For example: we add this keybinding now, to be > revisited in 14/21/30 days and then a final discussion is taken to keep > or revert it once people have gotten some experience with it. If I saw a message about that, I would try to build the latest sources soon so I could comment. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I repeatedly explained that the old behavior should remain available. > Initially the change explicitly removed the old behavior: "The old > [behavior] is no longer available." I don't understand what the "stealing minibuffers" issue is about -- I don't use Emacs on a graphical terminal normally -- but I agree in principle with this point. Alan wrote: > Have you tried this patch out, yet? If there is anything in the > "approximation" which is not close enough, perhaps you could point out > what, so that I might fix it. Thanks! In principle that's a valid way of bringing back the old behavior as an option. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Eli Zaretskii <eliz@gnu.org> writes: > I don't mind that, either, but what about people who submit changes, > but don't intend to stick around long enough to see this process > through? Someone will have to step in and do it for them. I guess the person who commits the patch is the natural person to do it then... but in my experience, things like this is almost exclusively done by the regular developers. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Stefan Monnier <monnier@iro.umontreal.ca> writes: > No, I was thinking of changing `make-obsolete` and friends so they > undefine (or refrain from defining) the function/variable. They could > do so by testing `emacs-version` (or some other way to detect the > `master` code) along with some extra config vars (e.g. a var to force > the behavior globally on way or the other or only for some > functions/variables). It's an interesting idea... but I'm not sure we have sufficient obsoletion discipline to do this "mechanically". That is, most things that are obsoleted will be removed on schedule, but some things are so prevalent in the wild that they have to linger for a longer time. We could mark those few things in a different way, though. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
martin rudalics <rudalics@gmx.at> writes: >> Hm. I must be missing something -- I skimmed the (quite long) "Changes >> in frame/window code" thread now, and I don't see any push-back on this? >> Just a lot of discussion about various glitches on various systems >> (which you seemed to fix very quickly)? > > At least Bug#18167 comes to my mind. There were more complaints IIRC. There will always be complaints, especially from people who aren't paying attention to emacs-devel, but I don't see that as a major stumbling block. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Hello, Martin. On Mon, Jan 04, 2021 at 18:21:19 +0100, martin rudalics wrote: > > Forgive me if I become uncustomarily blunt and personal, but it seems you > > are determined to find the worst possible interpretation of everything, > > and your replies to so many posts take on an unusually negative tone. > Forgive me Alan but > > The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy > > even of being called a behaviour. > has a rather negative tone too. It does, but it's about a thing, not a person's actions. Does it disturb anybody? Does it disturb you? That's a genuine question. If so, I will be more careful to avoid repeating the disturbance in the future. > Gregory provided some interesting insights into how Emacs did > (mis-)behave in this regard and I think that they help us to soon see > a state that satisfies most of us. He did indeed. He has pointed out some bugs, too, which has been most helpful, and for which I am grateful. I do still find his manner of expression difficult to deal with. > martin -- Alan Mackenzie (Nuremberg, Germany).
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --] On Tue, Jan 05, 2021 at 10:48:18AM +0000, Alan Mackenzie wrote: > Hello, Martin. > > On Mon, Jan 04, 2021 at 18:21:19 +0100, martin rudalics wrote: > > > Forgive me if I become uncustomarily blunt and personal, but it seems you > > > are determined to find the worst possible interpretation of everything, > > > and your replies to so many posts take on an unusually negative tone. > > > Forgive me Alan but > > > > The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy > > > even of being called a behaviour. > > > has a rather negative tone too. > > It does, but it's about a thing, not a person's actions. Does it > disturb anybody? Does it disturb you? That's a genuine question. If > so, I will be more careful to avoid repeating the disturbance in the > future. This is from the peanut gallery, and from many a past experience. Take into account that whoever is proposing a change has gone through a possibly taxing experience and has had to muster quite a bit of enthusiasm to follow through. So criticising his/her baby might land, on the other side as a critique of the person him/herself. That doesn't mean, of course, that critique is impossible: on the contrary, that's the only way we (people and things) get better. So... critique away! But use as much empathy in that as you can summon. And, on the original topic, just to illustrate my background a bit: I'm one of those who appreciate infinitely Emacs' relative stability. As a comparison: I've just had a Firefox update. The way the URL bar works changed subtly -- a double-click doesn't leave the URL selected anymore (among other things too subtle to put a name on, but too annoying to just ignore). The expletives I wrote on my personal diary are NSFW. I was, and still am, in rage. Why do they have to change every little thing, just because? This is the contrary of user-empowering. CADT [1], and so on ad so forth. But this way of seeing things is just there, it is my first impression, it is important to understand things. But I feel the duty to distill it in a constructive way before throwing it at any other human being. It's a difficlut balance, but I think it's worth it. We humans are a messy bunch, it seems :) Cheers [1] https://www.jwz.org/doc/cadt.html - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
Hello, Gregory. On Mon, Jan 04, 2021 at 22:17:51 +0000, Gregory Heytings via Emacs development discussions. wrote: > >>>> * If some are opposed, they install the feature with a variable to > >>>> enable it, disabled by default. > >>> This is already being done: every backward-incompatible change is > >>> either required to become compatible, or, if that's not feasible, to > >>> provide a way to get back the old behavior. In some rare cases this > >>> doesn't happen, but such mistakes are rare exceptions, they aren't the > >>> rule. > >> That's not correct, see for example the thread "Stop frames stealing > >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' > >> minibuffers, which are arguably a central piece of Emacs' UI, is being > >> modified on the pretext that it is "unsystematic", without any > >> argument, and in spite of the fact that hundreds and thousands of users > >> have been using it without complaining about that supposed > >> "unsystematicity". > >> I repeatedly explained that the old behavior should remain available. > >> Initially the change explicitly removed the old behavior: "The old > >> [behavior] is no longer available." The latest patch sent yesterday, > >> only promises to "approximate" the old behavior. > > That's because the original behavior was deemed buggy. We don't provide > > compatibility options to get old bugs back. As it turned out, what Alan > > considered buggy behavior was not necessarily so, therefore he now tries > > to provide a better backward compatibility. > It did not "turn out", I explained in detail that the behavior that Alan > considered buggy was not at all buggy before he started working on this. I don't think you "explained" at all, and certainly not before I started working on it - I initiated the discussion with a proposed patch so as to minimise the risk of just wasting people's time with bikeshedding. The word "explain" would entail you speaking with some special insight, some special knowledge, some authority. I don't think you had any of these, hence making the use of the word "explain" wrong. Indeed, I found it offensive for that reason. You were just expressing your point of view, one amongst several, that's all. > And I fear that trying to provide a better backward compatibility after > having removed the code of the old behavior is doomed to fail, it will > most likely result in an endless bug report / bug fix loop. You keep referring to an "old behaviour" that I removed, as though there were something coherent, something valuable, something worth keeping. I don't think there's anything of the kind. I think the former behaviour just happened by accident as a result of people working on other things, and nobody consciously made it happen. I am now consciously trying to fix it. If you've argued for an old behaviour on its merits, possibly in the thread "stealing eachother's minibuffers", could you perhaps point out the place in that thread, so that I can read it again. > > As the bug is still being actively worked on, it is premature ti draw > > any definitive conclusions from it relevant to the current discussion. > I do believe it is relevant. > The general pattern is similar to the y-or-n-p one, in that the code of an > UI behavior is removed and replaced by another one. It is also, I think > (but it's just a feeling, I did not follow the discussions at that time), > similar to the changes in Emacs 27 about which Drew loudly complained and > that make Emacs 27 unuseable for him. > What could have been done instead is to add some new code next to the > existing one to conditionally provide a new behavior, ..... That could not have been done, due to the state of the code in minibuf.c, in particular, due to the lack of any coherent "existing behaviour". > .... with an easy way for users who prefer / need the old behavior to > revert the change. If this had been done with y-or-n-p, this thread > would simply not exist. If this had been done with the new minibuffer > behavior, the "Stop frames stealing each other's minibuffers" thread > would be very different. > And the consequence of that pattern is what Richard fears: my comments, > which can be summarized as "please do not remove the old behavior", are > perceived by Alan almost as a personal attack. No. I see them as a misperception of the state of Emacs on your part. > This would not happen if we were doing what Richard suggests. -- Alan Mackenzie (Nuremberg, Germany).
> A combination of our practices adds up to a system that will install
> some UI changes without having much of a discussion about it.
I see no evidence of that.
Maybe there is no discussion *prior* to the change, but if the change
ends up being controversial, there is pretty much always a discussion
(long) before the next release.
Stefan
> Date: Mon, 04 Jan 2021 22:17:51 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: emacs-devel@gnu.org > > I repeatedly explained that the old behavior should remain available. Initially the change explicitly removed the old behavior: "The old [behavior] is no longer available." The latest patch sent yesterday, only promises to "approximate" the old behavior. > > That's because the original behavior was deemed buggy. We don't provide compatibility options to get old bugs back. As it turned out, what Alan considered buggy behavior was not necessarily so, therefore he now tries to provide a better backward compatibility. > > It did not "turn out", I explained in detail that the behavior that Alan considered buggy was not at all buggy before he started working on this. I don't see the relevance of this. We are talking about the process, so the details of who said what and when to make the developer aware that the presumed buggy behavior isn't -- those details aren't important for the purposes of the current discussions, and not naming the person(s) who contributed to this doesn't mean their contribution is not acknowledged. > As the bug is still being actively worked on, it is premature ti draw any definitive conclusions from it relevant to the current discussion. > > I do believe it is relevant. > > The general pattern is similar to the y-or-n-p one, in that the code of an UI behavior is removed and replaced by another one. The UI didn't change at all in the case of minibuffer tracking. The commands are still the same commands. What changed is the behavior of Emacs in response to these commands. That _is_ different from the y-or-n-p case. > It is also, I think (but it's just a feeling, I did not follow the discussions at that time), similar to the changes in Emacs 27 about which Drew loudly complained and that make Emacs 27 unuseable for him. We don't really know what makes Emacs 27 unusable for Drew, because we don't have enough information regarding the problems he faces, and no one else reported anything similar, so it seems. So I cannot see how the issue of Emacs 27's usability for Drew can support any conclusions yet. > What could have been done instead is to add some new code next to the existing one to conditionally provide a new behavior, with an easy way for users who prefer / need the old behavior to revert the change. If this had been done with y-or-n-p, this thread would simply not exist. If this had been done with the new minibuffer behavior, the "Stop frames stealing each other's minibuffers" thread would be very different. Like I said, sometimes changes run so deep that providing options to get the precise past behavior is not feasible. E.g., see the example of the bidi display.
> Date: Mon, 04 Jan 2021 22:18:04 +0000 > Cc: emacs-devel@gnu.org > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > I don't think that was Richard's point: we always go to great lengths to make it possible to get back the old behavior (even for changes where the impact is quite minor). > > E.g. with respect to `y-or-n-p`, I think we already all agree that there should be a way to recover the previous "modal" behavior. We just need someone to implement it (ideally while still preserving the improvement of the new minibuffer-based code). > > No always, alas. Yes, not always. It isn't feasible nor wise to do that "always", so please don't insist on such unrealistic goals. But in the vast majority of cases, we do go to great lengths (some say too great) to provide an option to get the old behavior back. This list and the bug list are replete with examples of that. > With respect to y-or-n-p, there is now indeed an agreement that there should be a way to recover the old behavior. But IIUC, Richard's point is that this possibility should have been present since the beginning, when the new behavior was introduced, without waiting for objections. It is impossible to promise that no one will ever make good-faith mistakes like this. The important point is to have procedures in place to detect such mistakes and fix them, without imposing too much overhead on the development. > What happened is (1) behavior A is removed and replaced by behavior B, (2) enough people object this change, (2) behavior B is implemented again. > > What could have happened instead is (1) behavior B is implemented, next to behavior A, with a way to choose between them, (2) at some point, possibly immediately, the default behavior is changed from A to B, (3) if after some time it becomes clear that behavior A is not used anymore, it is deprecated, and later again removed. The changes in the process proposed for making such cases rarer would cause a significant slowdown of the Emacs development, so my conclusion is that those proposals are unjustified given the small number of incidents that would presumably call for those changes. > Having both behaviors available at the same time is also, I believe, a necessary condition for a fruitful comparison and discussion. Otherwise the discussion is about the merits of a removed behavior vs. the new behavior instead of about the merits of a behavior A vs. a behavior B. It is very easy to compare without having both behaviors in the same binary: just keep old binaries around. That's what I do, and it allows me to quickly see what was past behavior, and even perform a quick "bisection" when some new problem is reported. Highly recommended.
> From: Richard Stallman <rms@gnu.org>
> Cc: rudalics@gmx.at, juri@linkov.net, emacs-devel@gnu.org
> Date: Tue, 05 Jan 2021 01:25:59 -0500
>
> > > That is true, but it may not be a problem. To get useful results, we
> > > don't need most of the community to switch. It is enough to get
> > > answers from a variety of users.
>
> > Which users should they be, and how do we find them and reach out to
> > them?
>
> One obvious way is to post an announcement on various mailing lists,
> asking people to repost it. People will respond.
>
> > They should definitely be users who have the just-released version
> > installed, which is why I mentioned the observation that the process
> > of upgrading to a new version is slow and takes many moons.
>
> That's why I suggest waiting before we ask.
>
> > Let's say we have half a dozen of such features, and we need to wait
> > for the answers for a few months about each one of them. Who can have
> > a long enough attention span to manage such a polling system?
>
> I propose a distributed system which needs no management. The people
> who advocate changing the default to enable a given feature will
> probably speak up about it. We just need a rule about the minimum
> time to wait after the release.
>
> If they don't speak up, that suggests that having the new option is
> sufficient ;-}.
You are describing something that is already happening. In the vast
majority of cases new features don't become the default, they are
introduced as opt-in features and announced in NEWS. We consider
making them the default after several releases, if and when people
start asking us to enable a feature by default.
This is so even if the new feature is compatible with past behavior.
New features that break compatibility with past behavior are highly
unlikely to be turned on by default, much less so than features that
are deemed compatible.
My conclusion is that what you are proposing regarding the
introduction of new features into official releases already happens,
and there's no need for any changes in the process and the rules we
are using for that, in order to support what you'd like to see.
Once again, mistakes can happen, so please don't bring up this or that
single incident as evidence that the above description is incorrect or
skewed, unless you are prepared to argue that the mistakes happen too
often, and produce evidence of such high frequency. A single incident
is not evidence strong enough that the process is flawed, and doesn't
justify complicating the process with additional rules associated with
high overhead.
(How to avoid mistakes during development, where some change is deemed
compatible and non-problematic whereas in fact it isn't, is a separate
issue, unrelated to the release process and the way we handle changes
in the defaults from release to release. But that is not the issue
you raised in the message to which I'm responding.)
> From: Richard Stallman <rms@gnu.org>
> Cc: monnier@iro.umontreal.ca, juri@linkov.net, rudalics@gmx.at,
> eliz@gnu.org, emacs-devel@gnu.org, larsi@gnus.org,
> drew.adams@oracle.com
> Date: Tue, 05 Jan 2021 01:33:50 -0500
>
> > So here's a suggestion: perhaps we should think about
> > sometimes carrying out time-boxed experiments on the master branch in
> > controversial cases. For example: we add this keybinding now, to be
> > revisited in 14/21/30 days and then a final discussion is taken to keep
> > or revert it once people have gotten some experience with it.
>
> That's fine with me, but there should be a variable to enable the
> changed behavior. That makes the experiment painless for everyone else.
It is impractical to make a variable for every change in behavior.
In some cases the change itself is a variable: for example
introduction of a new option or a new binding gives you that variable
as a side effect.
In other cases we think we are fixing a bug or a confusing or
incorrect behavior. In these cases we don't provide variables to get
back the incorrect behavior, nor should we.
In yet other cases the changes are so deep and significant that
providing backward compatibility would impose an impossible toll that
makes the entire changeset impractical.
The rare problematic cases are when the judgment call about the nature
of the change turns out to be a mistake. We should try to minimize
such mistakes, but introducing a rule that _every_ change should
necessarily come with a variable to disable or revert it is a cure
that is much worse than the disease. I'm against such absurd
measures.
To be practical, a rule like this would need to come with some
elaborate set of allowed exceptions, and that will undoubtedly trigger
endless discussions about whether this or that particular change is or
isn't an exception (because adding such compatibility shims is never a
job developers like). We have such disputes already, because we do
attempt to provide such options where deemed necessary. The proposed
rule will make that much worse, so I'm against such an absolute rule.
> From: Richard Stallman <rms@gnu.org> > Cc: eliz@gnu.org, rudalics@gmx.at, juri@linkov.net, > drew.adams@oracle.com, emacs-devel@gnu.org > Date: Tue, 05 Jan 2021 01:33:57 -0500 > > > Three out of five Emacs maintainers have now weighed in (at some length, > > in total), that they don't think your proposal would be helpful in > > practice, so I think it's time to let this go. > > We can't "let it go". A combination of our practices adds up to a > system that will install some UI changes without having much of a > discussion about it. And then, once they are released, it is "too > late" to argue to revert them. I don't think the above is a balanced description of the reality. We have a single incident, or maybe a small number of them, where the process failed to spot a problematic change in time for it to be fixed before the release. So we are fixing it later. That's not what the "system" is, that's a rare exception. Mistakes happen, and will continue to happen, no matter what procedures we will install. Let's not exaggerate the significance of a single incident, and let's not draw drastic conclusions from it that blow the issue out of proportions, because that never leads to sound decisions. > There are many ways we could fix this, but we need to fix it. The problems are rare, so the proposed solutions should not unduly complicate the existing process, which in the vast majority of the cases does work, and works well. I invite you to read the NEWS for the few recent releases looking for behavior changes that have a documented way of disabling them, and for changes that are opt-in to begin with. _That_ is what the "system" produces, not the one or two rare exceptions.
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, rms@gnu.org,
> juri@linkov.net, rudalics@gmx.at, emacs-devel@gnu.org,
> drew.adams@oracle.com
> Date: Tue, 05 Jan 2021 09:16:57 +0100
>
> > I don't mind that, either, but what about people who submit changes,
> > but don't intend to stick around long enough to see this process
> > through? Someone will have to step in and do it for them.
>
> I guess the person who commits the patch is the natural person to do it
> then... but in my experience, things like this is almost exclusively
> done by the regular developers.
I have enough examples to the contrary to make me skeptical.
In any case, suppose you are wrong, and the responsible person fails
to do this job, do we have Plan B? Or do we allow this process to
fail? If the latter, then we don't really have any guarantee that
this will work, do we?
> It does, but it's about a thing, not a person's actions. Does it > disturb anybody? Does it disturb you? That's a genuine question. If > so, I will be more careful to avoid repeating the disturbance in the > future. I'm using such jargon myself (and almost immediately repent it because somebody must have written that code before) so it usually doesn't disturb me. But in the present situation it was not diplomatic to use it. martin
>> It is also, I think (but it's just a feeling, I did not follow the
>> discussions at that time), similar to the changes in Emacs 27 about
>> which Drew loudly complained and that make Emacs 27 unuseable
>> for him.
>
> We don't really know what makes Emacs 27 unusable for Drew, because we
> don't have enough information regarding the problems he faces, and no
> one else reported anything similar, so it seems. So I cannot see how
> the issue of Emacs 27's usability for Drew can support any conclusions
> yet.
I too don't understand why while in dozens of libraries Drew routinely
adds backward-compatible aliases such as
(when (= emacs-major-version 27)
(defun y-or-n-p ()
pre-27 body ...
but not in this case.
>
> You are describing something that is already happening. In the vast
> majority of cases new features don't become the default, they are
> introduced as opt-in features and announced in NEWS. We consider making
> them the default after several releases, if and when people start asking
> us to enable a feature by default.
>
I agree with you that this is already happening in the vast majority of
cases, so why would it be problematic to make this a rule, that in
principle any change to Emacs' behavior should provide a way to re-enable
the old behavior? IIUC that's all Richard wants. Of course that rule
would not apply to bugfixes, and exceptions would be possible with the
explicit approval of a maintainer.
>> Having both behaviors available at the same time is also, I believe, a
>> necessary condition for a fruitful comparison and discussion. Otherwise
>> the discussion is about the merits of a removed behavior vs. the new
>> behavior instead of about the merits of a behavior A vs. a behavior B.
>
> It is very easy to compare without having both behaviors in the same
> binary: just keep old binaries around. That's what I do, and it allows
> me to quickly see what was past behavior, and even perform a quick
> "bisection" when some new problem is reported. Highly recommended.
>
That's what I do, too. But you can't expect regular users to do this to
compare two behaviors in order to give feedback.
> I agree with you that this is already happening in the vast majority of
> cases, so why would it be problematic to make this a rule, that in principle
> any change to Emacs' behavior should provide a way to re-enable the old
> behavior? IIUC that's all Richard wants. Of course that rule would not
> apply to bugfixes, and exceptions would be possible with the explicit
> approval of a maintainer.
The problem is that I disagree with your "Of course": the whole
difficulty is to decide which change falls in this category.
The problem is not that we don't follow the rule or that we don't have
such a rule. It's that there's no hard-and-fast way to decide where
that rule should apply: it's a judgment call and often this call is
non-trivial (what one person calls "feature" qualifies as "bug fix" for
another, what should be a cosmetic change may end up unexpectedly
changing behavior), which is why sometimes it takes feedback from users
to realize we got it wrong.
Stefan
> Date: Wed, 06 Jan 2021 00:14:33 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> > It is very easy to compare without having both behaviors in the same
> > binary: just keep old binaries around. That's what I do, and it allows
> > me to quickly see what was past behavior, and even perform a quick
> > "bisection" when some new problem is reported. Highly recommended.
>
> That's what I do, too. But you can't expect regular users to do this to
> compare two behaviors in order to give feedback.
Why not? This is not about any user, this is about people who track
the Emacs development.
> Date: Wed, 06 Jan 2021 00:14:21 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: rms@gnu.org, rudalics@gmx.at, emacs-devel@gnu.org, juri@linkov.net
>
> > You are describing something that is already happening. In the vast
> > majority of cases new features don't become the default, they are
> > introduced as opt-in features and announced in NEWS. We consider making
> > them the default after several releases, if and when people start asking
> > us to enable a feature by default.
>
> I agree with you that this is already happening in the vast majority of
> cases, so why would it be problematic to make this a rule, that in
> principle any change to Emacs' behavior should provide a way to re-enable
> the old behavior?
Because the fact it's already happening means we already have the
necessary rules, and adding more rules that restrict how we develop
Emacs is an unnecessary overhead.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > It may be "valid" in principle, but it is no a wise choice for changes > > in the Emacs command interface. If we want to be confident that users > > will notice plans for changes, and say if they object, before the > > change is in a release, we are obliged to help users notice. > Users don't track emacs-devel, either. In fact, most users nowadays > don't like to use mailing lists at all. You are right that most users don't pay attention to the work we are doing while we are doing it. They will not comment on it. Thus we have been talking, all along, about the users that do pay attention, and might comment on proposed changes. The words you quoted above refer to them, too. > So I don't see how forcing > discussions to happen on emacs-devel will reach the goal of helping > users notice important changes and object in time. It will give help all the users who follow emacs-devel to take note of a proposed change. That is what we presume will happen, but it isn't happening reliably. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > That's not difficult. People who want to make the new behavior the default > > will be motivated to conduct the inquiry. > If they are motivated enough, we don't need any rules for that, we > just should continue behaving as we did, because starting a discussion > on emacs-devel about any issue related to Emacs is always possible > (and happens already). You CAN start a discussion on emacs-devel, but in order to be aware there is a need for one, you would need to subscribe to bug-gnu-emacs AND follow discussion of dealing with a particular bug. The point of my rule simply to ensure that the readers of emacs-devel see that there is an interface change is being proposed. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > My point is that they are not so rare -- there is a systematic tendency > > for that to happen. > What is the basis for your impression that such a tendency exists? I've pointed out the steps of the pathway. 1. A bug is reported. Most of us are not interested in fixing that bug so we don't read the messages about it. 2. People discussing it in the bug thread propose and agree on a certain change. 3. It happens to be a change in user interface. 4. They implement it without ever discussing it on emacs-devel. 5. Before we notice the change, a new release is made. 6. Some of us object and we are told, "Because this change has been in a release, we will not undo it (or even revert the default) unless there are strong objections." How often does this happen? I don't know. But why let it happen? I have proposed several ways to avoid it. I'm not wedded to any of them; I just want to stop it from happening again. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > My proposal will help with that problem too. Instead of waiting for a > > resolution of the dispute, we should install the change with a user > > option variable to enable the new behavior. > That is already happening where the change seems to be controversial > or a too radical departure from long-time behavior. That's good. But it suggests that the spectre of "interminable dispute" has been exaggerated. If people are getting tired of a dispute, they will get behind the solution of "install it with an option" and we will go ahead with that. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > To take the already-mentioned case as an example -- Martin wanted to > have us try out horizontal scroll bars to see whether they work, so he'd > flip them on, and announce on emacs-devel "these default to on for a > week, and then we'll discuss". That would satisfy me, because it would be announced on emacs-devel. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > I think the most natural person to manage the process would be the > > person that's proposing the change. That is, we don't really need much > > formalism around this. > I don't mind that, either, but what about people who submit changes, > but don't intend to stick around long enough to see this process > through? Someone will have to step in and do it for them. Before doing this time-boxed feature test, we would ask the people pushing for the change to accept the responsibility to follow it up, with a given schedule. If they don't want to do that, the test doesn't start. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > IME a week is not sufficient: > - Many users don't update from `master` on a daily basis. > - I `git fetch` daily from `master`, but I don't restart my Emacs > sessions all the time (hell, I just tried `M-x emacs-uptime` and this > Gnus-dedicated session "says 184 days, 18 hours, 28 minutes, 38 > seconds"). I update from master every few months. Building it takes a day. Because there are occasional complications, I don't even do git pull unless I'm ready to spend a while dealing with the consequences. I do now know how to deal with those complications, but it may take time. > So I think such changes should be introduced with: > - An explicit announcement. > - A clear way to get back the old behavior. > - A trial period in the order 2-3 months. Fine with me. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Note that horizontal scrollbars are turned on by default on all builds > that support them. This is the only way I see to get them at least some > initial coverage. If you utterly dislike them (or do not use scrollbars > at all) please use the idiom > (when (fboundp 'horizontal-scroll-bar-mode) > (horizontal-scroll-bar-mode -1)) > I intend to disable horizontal scrollbars by default in the next weeks. It seems good to me. Just because someone grumbled does not imply it was your fault. Perhaps it would have been good to ask Eli to announce it. That would have gained more respect for the test. If someone did grumble, we (Eli, you, I, ...) could have responded that the reason to run the development version is so you can help by trying it out. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > E.g. with respect to `y-or-n-p`, I think we already all agree that there > > should be a way to recover the previous "modal" behavior. We just need > > someone to implement it (ideally while still preserving the improvement > > of the new minibuffer-based code). > IIUC Juri has done that in commit cd4a51695fddf2a76ae9ed71efa8bfb4a515b32e. Thank you, Juri. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Its name should be consistent with another variable > use-short-answers that could be used to replace > yes-or-no-p with y-or-n-p. These two should have names > that preclude confusion between their meanings. > Also use-short-answers could be used by the existing variable > read-answer-short. That might be good, but needs working out the details. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Having both behaviors available at the same time is also, I believe, a > necessary condition for a fruitful comparison and discussion. Otherwise > the discussion is about the merits of a removed behavior vs. the new > behavior instead of about the merits of a behavior A vs. a behavior B. It certainly helps people recognize what they prefer if they can switch back and forth between the two. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
>> I agree with you that this is already happening in the vast majority of
>> cases, so why would it be problematic to make this a rule, that in
>> principle any change to Emacs' behavior should provide a way to
>> re-enable the old behavior? IIUC that's all Richard wants. Of course
>> that rule would not apply to bugfixes, and exceptions would be possible
>> with the explicit approval of a maintainer.
>
> The problem is that I disagree with your "Of course": the whole
> difficulty is to decide which change falls in this category.
>
> The problem is not that we don't follow the rule or that we don't have
> such a rule. It's that there's no hard-and-fast way to decide where
> that rule should apply: it's a judgment call and often this call is
> non-trivial (what one person calls "feature" qualifies as "bug fix" for
> another, what should be a cosmetic change may end up unexpectedly
> changing behavior), which is why sometimes it takes feedback from users
> to realize we got it wrong.
>
A rule is not a mathematical law, it's an action guideline. Such a rule
would avoid having developers start working on something thinking that
scratching the current state of affairs to create something they believe
is better without thinking about backwards compatibility is okay.
This does happen, and this can lead and does lead to unnecessary disputes
(one is underway), that could be avoided with such a rule.
By the way, the feedback in this case came from Richard, who wanted the
old behavior back, and he got it back in a few days. I'm curious whether
this would have happened if the feedback had been sent by a random user.
>>> It is very easy to compare without having both behaviors in the same
>>> binary: just keep old binaries around. That's what I do, and it
>>> allows me to quickly see what was past behavior, and even perform a
>>> quick "bisection" when some new problem is reported. Highly
>>> recommended.
>>
>> That's what I do, too. But you can't expect regular users to do this
>> to compare two behaviors in order to give feedback.
>
> Why not? This is not about any user, this is about people who track the
> Emacs development.
>
One of the things Richard had in mind in his proposal was "poll the users
and see who likes [the new behavior] _and why_". Perhaps I misunderstood
what he meant, but for me "the users" is much broader than "people who
track the Emacs development".
Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> writes: > A rule is not a mathematical law, it's an action guideline. No, a rule is obviously stronger than a guideline. Otherwise, you would have proposed a guideline. Which would be a fine proposal, and AFAICT equivalent to what we have already. > ... developers start working on something thinking that scratching the > current state of affairs to create something they believe is better > without thinking about backwards compatibility ... Do you have any evidence to back up the claim that this has happened? > By the way, the feedback in this case came from Richard, who wanted the > old behavior back, and he got it back in a few days. I'm curious whether > this would have happened if the feedback had been sent by a random user. Of course Richard's word has more weight than that of "a random user". This is expected in any project. (Guido in Python, Larry Wall in Perl, Linus in Linux, etc.) But in general, backwards compatibility complaints are taken seriously no matter the sender. In fact, this project sometimes goes to extreme lengths simply to maintain backwards-compatibility even in the most minor and inconsequential cases. But of course on occasion we trip up: we don't pay enough attention to this aspect, or we take it much too far. Both are equally bad, IMHO. To my mind, we need to take a balanced view. I don't see how a hard rule (or even a soft one) will help us do that better.
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org, > drew.adams@oracle.com, juri@linkov.net > Date: Wed, 06 Jan 2021 00:01:09 -0500 > > > Users don't track emacs-devel, either. In fact, most users nowadays > > don't like to use mailing lists at all. > > You are right that most users don't pay attention to the work we are > doing while we are doing it. They will not comment on it. > > Thus we have been talking, all along, about the users that do pay > attention, and might comment on proposed changes. The words you > quoted above refer to them, too. Then we are talking about some arbitrary sample of users on which we have no control. Thus, nothing prevents us from talking about another arbitrary sample: those who track both emacs-devel and the bug list. The life of the head maintainers is already complicated enough, so I object to making it significantly more complicated and time-consuming just because we want to save someone the trouble of reading another mailing list. > > So I don't see how forcing > > discussions to happen on emacs-devel will reach the goal of helping > > users notice important changes and object in time. > > It will give help all the users who follow emacs-devel to take note > of a proposed change. That is what we presume will happen, but it isn't > happening reliably. I see no reason to believe that the users who read emacs-devel, but don't read the bug list, are more important for getting feedback from than those who read both. I could make a case for the opposite, in fact. Btw, all the persons involved in the discussion of the y-or-n-p issue read both lists, AFAIK.
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org, > drew.adams@oracle.com, juri@linkov.net > Date: Wed, 06 Jan 2021 00:01:13 -0500 > > > If they are motivated enough, we don't need any rules for that, we > > just should continue behaving as we did, because starting a discussion > > on emacs-devel about any issue related to Emacs is always possible > > (and happens already). > > You CAN start a discussion on emacs-devel, but in order to be aware > there is a need for one, you would need to subscribe to bug-gnu-emacs > AND follow discussion of dealing with a particular bug. There's no need to subscribe to bug-gnu-emacs in order to read it. One can follow the list archives via the Web browser, for example, or use the debbugs Web interface. > The point of my rule simply to ensure that the readers of emacs-devel > see that there is an interface change is being proposed. The rule you propose has a price that I don't think we should pay. I personally simply cannot afford paying it. Reading the bug list is not a big deal, so people who want to be more involved are invited to do that. By contrast, the burden on Lars and myself to make sure we start a discussion about every change which might require it is considerable.
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org, > drew.adams@oracle.com, juri@linkov.net > Date: Wed, 06 Jan 2021 00:01:17 -0500 > > > What is the basis for your impression that such a tendency exists? > > I've pointed out the steps of the pathway. > > 1. A bug is reported. Most of us are not interested in fixing that bug > so we don't read the messages about it. > 2. People discussing it in the bug thread propose > and agree on a certain change. > 3. It happens to be a change in user interface. > 4. They implement it without ever discussing it on emacs-devel. > 5. Before we notice the change, a new release is made. > 6. Some of us object and we are told, "Because this change has been in a > release, we will not undo it (or even revert the default) unless there > are strong objections." > > How often does this happen? I don't know. Extremely rare, IME. > But why let it happen? If someone can come up with a solution that doesn't impose too heavy overhead, we should definitely consider it. None of the solutions proposed until now fulfills that requirement, so the simple solution I proposed -- to read bug-gnu-emacs in addition to emacs-devel -- still wins.
> From: Richard Stallman <rms@gnu.org>
> Cc: rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org,
> drew.adams@oracle.com, juri@linkov.net
> Date: Wed, 06 Jan 2021 00:01:20 -0500
>
> > > My proposal will help with that problem too. Instead of waiting for a
> > > resolution of the dispute, we should install the change with a user
> > > option variable to enable the new behavior.
>
> > That is already happening where the change seems to be controversial
> > or a too radical departure from long-time behavior.
>
> That's good. But it suggests that the spectre of "interminable
> dispute" has been exaggerated. If people are getting tired of
> a dispute, they will get behind the solution of "install it with
> an option" and we will go ahead with that.
You are forgetting the cases where such a variable is inappropriate,
for example if the person who proposes the change thinks the change
fixes a bug, or when such a variable is not feasible.
Besides, no one can be sure that people who get tired will implement
such a variable to stop the dispute. They are quite likely to give up
on the change instead.
> From: Richard Stallman <rms@gnu.org> > Cc: larsi@gnus.org, stefankangas@gmail.com, monnier@iro.umontreal.ca, > juri@linkov.net, rudalics@gmx.at, emacs-devel@gnu.org, > drew.adams@oracle.com > Date: Wed, 06 Jan 2021 00:01:30 -0500 > > > I don't mind that, either, but what about people who submit changes, > > but don't intend to stick around long enough to see this process > > through? Someone will have to step in and do it for them. > > Before doing this time-boxed feature test, we would ask the people pushing for > the change to accept the responsibility to follow it up, with a given > schedule. IME, this doesn't work with today's volunteer-based communities, including this one. We have no practical way of ensuring people assume such responsibilities, let alone keep their promises in that regard. We all have our Real Lives. This isn't a theory, it happens here in enough cases to be a real-life scenario we should take into account. > If they don't want to do that, the test doesn't start. Meaning that the change doesn't get installed? That'd be a serious blow to development, which is unjustified. The frequency of problems such as the current one is very low; by contrast, people submitting a change that looks useful and then disappearing happens all the time.
> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, eliz@gnu.org, stefankangas@gmail.com,
> juri@linkov.net, rudalics@gmx.at, emacs-devel@gnu.org,
> drew.adams@oracle.com
> Date: Wed, 06 Jan 2021 00:02:48 -0500
>
> > So I think such changes should be introduced with:
> > - An explicit announcement.
> > - A clear way to get back the old behavior.
> > - A trial period in the order 2-3 months.
>
> Fine with me.
Fine with me, if someone volunteers to do this job. Failing that,
definitely not fine with me, as I cannot afford adding this to my
current burden of Emacs maintenance.
> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, eliz@gnu.org, juri@linkov.net,
> stefankangas@gmail.com, emacs-devel@gnu.org,
> drew.adams@oracle.com, monnier@iro.umontreal.ca
> Date: Wed, 06 Jan 2021 00:03:07 -0500
>
> Perhaps it would have been good to ask Eli to announce it.
> That would have gained more respect for the test.
I very much doubt that my announcement would carry much more weight
than Martin's.
More importantly, I have already so much to do with so little time to
do it that I'm glad about every opportunity I have to delegate to
someone else.
> 1. A bug is reported. Most of us are not interested in fixing that bug > so we don't read the messages about it. > 2. People discussing it in the bug thread propose > and agree on a certain change. > 3. It happens to be a change in user interface. > 4. They implement it without ever discussing it on emacs-devel. > 5. Before we notice the change, a new release is made. > 6. Some of us object and we are told, "Because this change has been in a > release, we will not undo it (or even revert the default) unless there > are strong objections." > > How often does this happen? I don't know. We know it happens extremely rarely. > But why let it happen? Because preventing it requires undue burden. The cure is worse than the disease. Stefan
> Date: Wed, 06 Jan 2021 09:41:09 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: emacs-devel@gnu.org, rudalics@gmx.at, Eli Zaretskii <eliz@gnu.org>,
> rms@gnu.org, juri@linkov.net
>
> A rule is not a mathematical law, it's an action guideline.
That's not the kind of "rule" we are discussing here, please re-read
the thread from its beginning. I said long ago that I'm okay with a
guideline (and we actually already have it and act on it).
The proposed rule is very different: it says that if the announcement
and the discussion didn't happen, the change cannot go in.
> Date: Wed, 06 Jan 2021 09:41:27 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>
> That's what I do, too. But you can't expect regular users to do this to compare two behaviors in order to give feedback.
>
> Why not? This is not about any user, this is about people who track the Emacs development.
>
> One of the things Richard had in mind in his proposal was "poll the users and see who likes [the new behavior] _and why_". Perhaps I misunderstood what he meant, but for me "the users" is much broader than "people who track the Emacs development".
We are talking about people who read emacs-devel, because we'd prefer
detecting any such problems before we release them. So I don't see
how is that "much broader" than those who track Emacs development and
can keep several past versions for comparison.
And even if you are talking about the released versions, the normal
Emacs installation procedure leaves the previous binary available for
invocation; you need to explicitly "make uninstall" to remove it.
Does installing from a binary distro (as opposed to from sources built
locally) remove previous versions nowadays?
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 6 Jan 2021 12:06:44 +0100
> Cc: rudalics@gmx.at, Eli Zaretskii <eliz@gnu.org>, juri@linkov.net, rms@gnu.org,
> emacs-devel@gnu.org
>
> But in general, backwards compatibility complaints are taken seriously
> no matter the sender. In fact, this project sometimes goes to extreme
> lengths simply to maintain backwards-compatibility even in the most
> minor and inconsequential cases.
>
> But of course on occasion we trip up: we don't pay enough attention to
> this aspect, or we take it much too far. Both are equally bad, IMHO.
> To my mind, we need to take a balanced view. I don't see how a hard
> rule (or even a soft one) will help us do that better.
100% agreement.
> No, a rule is obviously stronger than a guideline.
Some rules are stronger than guidelines, no doubt,
however one might define rule, guideline, and
strength for each.
A guideline is a rule. A rule is not necessarily
a guideline.
Effective strength of a rule doesn't necessarily
come from the rule itself; it comes from its
enforcement.
Put differently, just what's meant by the strength
of a rule?
In country X they have very strict driving speed
limits. But the enforcement is limited. Every
few years they clamp down further on the amount
of blood alcohol allowed. But without enforcing
such a "strong" rule the additional "strength" is
meaningless.
> And even if you are talking about the released versions, the normal
> Emacs installation procedure leaves the previous binary available for
> invocation; you need to explicitly "make uninstall" to remove it.
> Does installing from a binary distro (as opposed to from sources built
> locally) remove previous versions nowadays?
Usually, yes. Sometimes there is a package foobar-8.1.0 and additional
foobar6-6.7.1, foobar7-7.9.12, i.e., installing foobar installs the
current version (8.1.0) but separate packages are provided for older
versions and you can have all of them installed in parallel, but that's
mostly done for libraries where some other package only works with
version 6 but not 7 or 8.
And from a distro packager's point of view, the additional
user-convenience of enabling users to compare emacs version X against
the current version surely doesn't justify the added maintenance costs.
Bye,
Tassilo
> From: Tassilo Horn <tsdh@gnu.org> > Date: Wed, 06 Jan 2021 16:46:41 +0100 > > > Does installing from a binary distro (as opposed to from sources built > > locally) remove previous versions nowadays? > > Usually, yes. Sometimes there is a package foobar-8.1.0 and additional > foobar6-6.7.1, foobar7-7.9.12, i.e., installing foobar installs the > current version (8.1.0) but separate packages are provided for older > versions and you can have all of them installed in parallel, but that's > mostly done for libraries where some other package only works with > version 6 but not 7 or 8. Not sure we are on the same page. I meant the following situation: . I installed foobar, which brought me foobar-7.1.0, the latest version at that time . Time passes and I learn there's a newer version of foobar, 8.1.0. So I install foobar again, and that brings me foobar-8.1.0. But did installing foobar-8.1.0 remove the installation of foobar-7.1.0? With many packages, the program executables that come with the package have the same name 'foobar', so installing the new one would overwrite the old one. But building and installing Emacs installs 2 executables: 'emacs' and 'emacs-MM.NN'; installing a new version will overwrite 'emacs', but not the versioned 'emacs-MM.NN' binary, so it needs to be explicitly deleted to get rid of it. And then there are versioned subdirectories of /usr/share and /usr/libexec. Do distros forcibly remove those versioned files and directories when they install a new version? > And from a distro packager's point of view, the additional > user-convenience of enabling users to compare emacs version X against > the current version surely doesn't justify the added maintenance costs. In the case of Emacs, I see no additional costs if all they do is refrain from removing the files belonging to the previous versions. The costs are of the end-user. Thanks.
Eli Zaretskii <eliz@gnu.org> writes: > Not sure we are on the same page. I meant the following situation: > > . I installed foobar, which brought me foobar-7.1.0, the latest > version at that time > . Time passes and I learn there's a newer version of foobar, 8.1.0. > So I install foobar again, and that brings me foobar-8.1.0. > > But did installing foobar-8.1.0 remove the installation of > foobar-7.1.0? Yes. Indeed the emacs package (on my Arch install) installs both /usr/bin/emacs and /usr/bin/emacs-27.1 so it could keep the old version of the binary around, and also the lisp in /usr/share/emacs/27.1/. But then the question is when and how are those files eventually going to be removed? And what about the files in /usr/share/emacs/site-lisp/? If they were byte-compiled with the newer version, is there a guarantee they'll work in all the older versions? > Do distros forcibly remove those versioned files and directories when > they install a new version? Yes, as said. Usually the package manager has some database of package-<version> and the files it installed and will remove the files when the package version is removed in order to clean up. >> And from a distro packager's point of view, the additional >> user-convenience of enabling users to compare emacs version X against >> the current version surely doesn't justify the added maintenance >> costs. > > In the case of Emacs, I see no additional costs if all they do is > refrain from removing the files belonging to the previous versions. > The costs are of the end-user. They'd probably still receive bug reports for the old version. Bye, Tassilo
>> > So I think such changes should be introduced with:
>> > - An explicit announcement.
>> > - A clear way to get back the old behavior.
>> > - A trial period in the order 2-3 months.
>>
>> Fine with me.
>
> Fine with me, if someone volunteers to do this job. Failing that,
> definitely not fine with me, as I cannot afford adding this to my
> current burden of Emacs maintenance.
Not sure how others interpreted what I wrote, but AFAIK none of the
above three points imply extra work (just like you, I don't want extra
work). All it does is clarify that we can tentatively introduce changes
in defaults and when people complain about a change in UI, we may want
to tell them to "try it for a couple month" before deciding it should
be reverted.
Stefan
> From: Tassilo Horn <tsdh@gnu.org> > Cc: emacs-devel@gnu.org > Date: Wed, 06 Jan 2021 17:36:49 +0100 > > > But did installing foobar-8.1.0 remove the installation of > > foobar-7.1.0? > > Yes. Indeed the emacs package (on my Arch install) installs both > /usr/bin/emacs and /usr/bin/emacs-27.1 so it could keep the old version > of the binary around, and also the lisp in /usr/share/emacs/27.1/. But > then the question is when and how are those files eventually going to be > removed? When the user decides to do so, possibly never. E.g., I keep old versions of all the main programs I use: Emacs, GCC, GDB, and some others. It is handy to have when the last version turns out to have some grave bug, or when I want to know which version introduced some new feature or some exciting bug. Disk space is cheap nowadays, whereas my time is all but cheap. > And what about the files in /usr/share/emacs/site-lisp/? If > they were byte-compiled with the newer version, is there a guarantee > they'll work in all the older versions? Yes, we seldom if ever break backward compatibility, precisely so site-lisp doesn't need to be recompiled. (There's a versioned site-lisp subdirectory under /usr/share/emacs/XY.Z as well, for the packages that do depend on Emacs version.) > > Do distros forcibly remove those versioned files and directories when > > they install a new version? > > Yes, as said. Too bad. Thanks for the info.
> From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: rms@gnu.org, larsi@gnus.org, stefankangas@gmail.com, juri@linkov.net, > rudalics@gmx.at, emacs-devel@gnu.org, drew.adams@oracle.com > Date: Wed, 06 Jan 2021 11:44:26 -0500 > > >> > So I think such changes should be introduced with: > >> > - An explicit announcement. > >> > - A clear way to get back the old behavior. > >> > - A trial period in the order 2-3 months. > >> > >> Fine with me. > > > > Fine with me, if someone volunteers to do this job. Failing that, > > definitely not fine with me, as I cannot afford adding this to my > > current burden of Emacs maintenance. > > Not sure how others interpreted what I wrote, but AFAIK none of the > above three points imply extra work (just like you, I don't want extra > work). The "trial period" part is extra work: someone will have to manage that. If we are to have a rule that such a trial is required for every UI change, tracking all those trials so that they could end in time will be non-trivial. Remembering to announce such changes is also an annoying additional duty, albeit a smaller one. Basically, such a system is a lot of hassle for very little gains. Please show me another project that does something like that. > All it does is clarify that we can tentatively introduce changes > in defaults and when people complain about a change in UI, we may want > to tell them to "try it for a couple month" before deciding it should > be reverted. It wasn't clear you were proposing a trial _after_ installing a change. If people who complain about a change agree to the trial suggestion, it may work, but then what exactly did we change from what we have now? And as you well know, people who complain about this stuff want it reverted NOW.
> It wasn't clear you were proposing a trial _after_ installing a
> change. If people who complain about a change agree to the trial
> suggestion, it may work, but then what exactly did we change from what
> we have now? And as you well know, people who complain about this
> stuff want it reverted NOW.
That's the crux of my suggestion: we reply "yes you want it now, but
maybe you won't want it any more in two months time, so give it a chance".
Stefan
> How often does this happen? I don't know. Extremely rare, IME. Even if it is extremely rare, it might be worth considering it because it would or could reduce conflict, and animosity between parties.
> > Otherwise, you would have proposed a guideline. Which would be a fine > proposal, and AFAICT equivalent to what we have already. > Perhaps I did not look at the right place, but I do not see such a rule or guideline in CONTRIBUTE or elsewhere. What do you (and others) think of the following: Any change that matters to end-users should have an entry in etc/NEWS. *In principle, any such change should, unless it is an added feature, either require setting a variable to be enabled, or be reversible by setting a variable.* Try to start each NEWS entry with a sentence that summarizes the entry and takes just one line -- this will allow to read NEWS in Outline mode after hiding the body of each entry. >> ... developers start working on something thinking that scratching the >> current state of affairs to create something they believe is better >> without thinking about backwards compatibility ... > > Do you have any evidence to back up the claim that this has happened? > It happened with y-or-n-p; it would not have happened with the above guideline. It is happening in the "Stop frames stealing each other's minibuffers" thread, where it is not clear that the behavior that is being changed should remain available as is, next to other behaviors. Again this would not have happened with the above guideline. >> By the way, the feedback in this case came from Richard, who wanted the >> old behavior back, and he got it back in a few days. I'm curious >> whether this would have happened if the feedback had been sent by a >> random user. > > Of course Richard's word has more weight than that of "a random user". > This is expected in any project. (Guido in Python, Larry Wall in Perl, > Linus in Linux, etc.) > > But in general, backwards compatibility complaints are taken seriously > no matter the sender. In fact, this project sometimes goes to extreme > lengths simply to maintain backwards-compatibility even in the most > minor and inconsequential cases. > Of course I understand and expected that Richard's word has more weight. My fear was that if the same request had been made by someone else it would have been dismissed; I'm glad to read that this wouldn't have happened.
>
> Does installing from a binary distro (as opposed to from sources built
> locally) remove previous versions nowadays?
>
Yes, at least for Debian and Debian derived distributions. Up to and
including Emacs 25 it was possible to install more than one Emacs, the
packages names were different for each version (emacs21, ..., emacs25).
Debian doesn't do this anymore, the package is now just "emacs". I don't
know why they changed their policy.
> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: rms@gnu.org, rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org,
> drew.adams@oracle.com, juri@linkov.net
> Date: Wed, 06 Jan 2021 16:18:46 -0500
>
> > How often does this happen? I don't know.
>
> Extremely rare, IME.
>
> Even if it is extremely rare, it might be worth considering it because
> it would or could reduce conflict, and animosity between parties.
Of course, it's worth considering! I'm not against considering it,
I'm against the specific solutions that were proposed to improve the
situation: they are worse than the problem itself.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Maybe there is no discussion *prior* to the change, but if the change > ends up being controversial, there is pretty much always a discussion > (long) before the next release. Not always. We just had a case where there wasn't. I am simply trying to ensure that the discussion will happen before the next release. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > It is very easy to compare without having both behaviors in the same > > > binary: just keep old binaries around. Highly recommended. > > > > That's what I do, too. But you can't expect regular users to do this to > > compare two behaviors in order to give feedback. > Why not? This is not about any user, this is about people who track > the Emacs development. I keep old binaries around, because I know that the new build may have difficulties. (That happened to me in the past year.) People who are deeping into testing Emacs during development will find this a good thing to do. But testing by comparing two binaries won't be as convenient as testing by flipping a variable during one session. In one minute you can toggle the option variable and try your command again. You can try 10 minutes of editing this way and 10 minutes that way, without having to visit your files again. Making an option variable for each possibly controversial change is a favor to everyone. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > A rule is not a mathematical law, it's an action guideline. Such a rule > would avoid having developers start working on something thinking that > scratching the current state of affairs to create something they believe > is better without thinking about backwards compatibility is okay. +1. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The proposed rule is very different: it says that if the announcement > and the discussion didn't happen, the change cannot go in. That's not a big deal. Make the announcement, have the discussion, and then the change can go in -- perhaps with the addition of a user option to enable the change. Since adding the user option variable is meant to be a general solution, we may as well say that there's no need for the announcement or the discussion if there is aleady a user option variable to enable the change, and it is disabled by default. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Perhaps it would have been good to ask Eli to announce it. > > That would have gained more respect for the test. > I very much doubt that my announcement would carry much more weight > than Martin's. > More importantly, I have already so much to do with so little time to > do it that I'm glad about every opportunity I have to delegate to > someone else. I understand. Maybe all that's needed is for Martin not to feel worried about the fact tht a user seems to be angry. Don't worry about the feelings, just take note that one user did not like the change. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > You CAN start a discussion on emacs-devel, but in order to be aware > > there is a need for one, you would need to subscribe to bug-gnu-emacs > > AND follow discussion of dealing with a particular bug. > There's no need to subscribe to bug-gnu-emacs in order to read it. > One can follow the list archives via the Web browser, for example, or > use the debbugs Web interface. We are miscommunicating. You're talking about a technical question about how one reads those messages. I am talking about the time and work required to read all those messages -- which is why I don't read them. I can't afford that. > The rule you propose has a price that I don't think we should pay. I > personally simply cannot afford paying it. Reading the bug list is > not a big deal, In my incoming for 20 hours, there were 70 messages to bug-gnu-emacs and debbugs. I can't keep up. I am about to go to bed and I am 200 messages backlogged from today alone. When people are discussing fixing a bug that is just a technical issue, and they can do it fine without me, I delete the whole thread so I can have time to read my other mail. Based on what you've said, I'm sure you understand what this is like. so people who want to be more involved are invited to > do that. By contrast, the burden on Lars and myself to make sure we > start a discussion about every change which might require it is > considerable. I agree. I don't think that you, the maintainers, should have to do this. I don't think I suggested that. But we have seen so many subtopics I can't remember them all with confidence. Anyway, let's agree that you maintainers shouldn't have a burden from this. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> writes: >> Does installing from a binary distro (as opposed to from sources built >> locally) remove previous versions nowadays? >> > > Yes, at least for Debian and Debian derived distributions. Up to and > including Emacs 25 it was possible to install more than one Emacs, the > packages names were different for each version (emacs21, ..., emacs25). > Debian doesn't do this anymore, the package is now just "emacs". I don't > know why they changed their policy. Debian dropped their numbered packages to avoid bug reports for very old versions of Emacs, see e.g.: "plans to finally drop our emacsXY binary packages, and just have a single version of Emacs in the archive, so that we no longer have to deal with bugs due to someone still having emacs21 installed (David’s idea; Rob’s implementation; Sean’s mostly-helpful comments)" https://spwhitton.name/blog/entry/debconf17_reports/
Gregory Heytings <ghe@sdf.org> writes: > Perhaps I did not look at the right place, but I do not see such a rule or > guideline in CONTRIBUTE or elsewhere. What do you (and others) think of > the following: > > Any change that matters to end-users should have an entry in etc/NEWS. > *In principle, any such change should, unless it is an added feature, > either require setting a variable to be enabled, or be reversible by > setting a variable.* I am against such a change, for the reasons given in my previous message. >> Do you have any evidence to back up the claim that this has happened? > > It happened with y-or-n-p; it would not have happened with the above > guideline. I don't think the second part of that sentence logically follows from the first.
>> Perhaps I did not look at the right place, but I do not see such a rule >> or guideline in CONTRIBUTE or elsewhere. What do you (and others) >> think of the following: >> >> Any change that matters to end-users should have an entry in etc/NEWS. >> *In principle, any such change should, unless it is an added feature, >> either require setting a variable to be enabled, or be reversible by >> setting a variable.* > > I am against such a change, for the reasons given in my previous > message. > Which previous message? I don't see reasons against such a guideline in your previous message sent to this list. >>> Do you have any evidence to back up the claim that this has happened? >> >> It happened with y-or-n-p; it would not have happened with the above >> guideline. > > I don't think the second part of that sentence logically follows from > the first. > Just look at the entry for this change in NEWS.27 (and the read-char-from-minibuffer one), which does not explain how to revert it, unlike the three other entries in the "Minibuffer" section: *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer. *** Some commands that previously used 'read-char-choice' now read a character using the minibuffer by 'read-char-from-minibuffer'. It seems to me that the "Any change that matters to end-users should have an entry in etc/NEWS" rule in CONTRIBUTE, which is already applied successfully, is also a good way to distinguish changes that are potentially controversial from the others, hence the proposal above.
Gregory Heytings <ghe@sdf.org> writes: > Which previous message? I don't see reasons against such a guideline in > your previous message sent to this list. This is the relevant part: > But of course on occasion we trip up: we don't pay enough attention to > this aspect, or we take it much too far. Both are equally bad, IMHO. > To my mind, we need to take a balanced view. I don't see how a hard > rule (or even a soft one) will help us do that better.
> Date: Wed, 06 Jan 2021 23:57:02 +0000 > From: Gregory Heytings <ghe@sdf.org> > cc: Stefan Monnier <monnier@iro.umontreal.ca>, rudalics@gmx.at, > Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, rms@gnu.org, > juri@linkov.net > > Otherwise, you would have proposed a guideline. Which would be a fine proposal, and AFAICT equivalent to what we have already. > > Perhaps I did not look at the right place The right place to look is in the discussions of the various changes, where this guideline is voiced loud and clear. > but I do not see such a rule or guideline in CONTRIBUTE or elsewhere. What do you (and others) think of the following: CONTRIBUTE is not the right place for this. It is a document for contributors, not for Emacs maintainers, and it describes rules, not guidelines. It is also already too large, and we risk losing the attention of the "TL;DR" type of impatient readers. I'm not convinced that we should have a document with guidelines, IME it is very hard to formulate guidelines without risking too rigid interpretation by someone. > ... developers start working on something thinking that scratching the current state of affairs to create something they believe is better without thinking about backwards compatibility ... > > Do you have any evidence to back up the claim that this has happened? > > It happened with y-or-n-p The question was whether there's such a _tendency_, not whether there are exceptions from the rule. > It is happening in the "Stop frames stealing each other's minibuffers" thread No, it doesn't. In fact, the exact opposite happens there: an assumption that the existing behavior is a bug was later reversed based on feedback from you and others. > Again this would not have happened with the above guideline. Of course, it would: we will never have a rule to allow going back to buggy behavior, so as long as the past behavior is considered a bug, there can be no rule that prevents its removal without any compatibility shims. > My fear was that if the same request had been made by someone else it would have been dismissed Fear based on what? I invite you to read the discussions of such complaints, and see for yourself whether you have anything to that effect to fear of.
> From: Richard Stallman <rms@gnu.org> > Cc: larsi@gnus.org, rudalics@gmx.at, eliz@gnu.org, > emacs-devel@gnu.org, drew.adams@oracle.com, juri@linkov.net > Date: Thu, 07 Jan 2021 02:33:42 -0500 > > > Maybe there is no discussion *prior* to the change, but if the change > > ends up being controversial, there is pretty much always a discussion > > (long) before the next release. > > Not always. We just had a case where there wasn't. We will never be able to avoid such incidents in all cases. We are just people, and people make mistakes. It is wrong to try to achieve such unrealistic goals. > I am simply trying to ensure that the discussion will happen before > the next release. We cannot ensure it; see above. We can (and should) try lowering the probability of the discussion not happening, but the measures taken to that end should be on par with the frequency of those incidents. Heavy measures to fix very low-frequency incidents are unjustified, and will harm development for reasons that are not good enough to justify the harm.
> From: Richard Stallman <rms@gnu.org>
> Cc: ghe@sdf.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Thu, 07 Jan 2021 02:41:21 -0500
>
> Making an option variable for each possibly controversial change is
> a favor to everyone.
Which is why we are doing that in every case where we decide that the
change could be (or is) controversial.
> From: Richard Stallman <rms@gnu.org> > Cc: ghe@sdf.org, rudalics@gmx.at, juri@linkov.net, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Thu, 07 Jan 2021 02:52:59 -0500 > > > The proposed rule is very different: it says that if the announcement > > and the discussion didn't happen, the change cannot go in. > > That's not a big deal. Make the announcement, have the discussion, > and then the change can go in -- perhaps with the addition of a user > option to enable the change. We do all that already, just without the red tape. It is a big deal for me to add any unnecessary red tape, because it makes my already hard job significantly harder. > Since adding the user option variable is meant to be a general > solution, we may as well say that there's no need for the announcement > or the discussion if there is aleady a user option variable to enable > the change, and it is disabled by default. There we go: the slippery slope of having exceptions to the rule is already starting. We will be adding more and more exceptions, and then we will be endlessly discussing whether a given exception can or cannot be applied to a particular case. To what end?
> From: Richard Stallman <rms@gnu.org> > Cc: rudalics@gmx.at, larsi@gnus.org, juri@linkov.net, > drew.adams@oracle.com, emacs-devel@gnu.org > Date: Thu, 07 Jan 2021 02:53:09 -0500 > > > > You CAN start a discussion on emacs-devel, but in order to be aware > > > there is a need for one, you would need to subscribe to bug-gnu-emacs > > > AND follow discussion of dealing with a particular bug. > > > There's no need to subscribe to bug-gnu-emacs in order to read it. > > One can follow the list archives via the Web browser, for example, or > > use the debbugs Web interface. > > We are miscommunicating. You're talking about a technical question > about how one reads those messages. > > I am talking about the time and work required to read all those > messages -- which is why I don't read them. I can't afford that. Redirecting some of the discussion to emacs-devel will add to what you have to read, and add considerably. This present thread is a very good example of what happens when some controversial issue is being discussed: you will suddenly see a significant increase in the list traffic. Why do you think you will be able to afford that? It will be less than if you read all of bug-gnu-emacs, but why do you think it will be below the threshold of what you cannot afford? > > The rule you propose has a price that I don't think we should pay. I > > personally simply cannot afford paying it. Reading the bug list is > > not a big deal, > > In my incoming for 20 hours, there were 70 messages to bug-gnu-emacs > and debbugs. I wish I were in your shoes, then: in my incoming for the last 10 hours there were 136 messages. > I can't keep up. I am about to go to bed and I am 200 messages > backlogged from today alone. > > When people are discussing fixing a bug that is just a technical > issue, and they can do it fine without me, I delete the whole thread > so I can have time to read my other mail. > > Based on what you've said, I'm sure you understand what this is like. Of course, I do! I _am_ reading all of that: it's my job. If you are unable to read most of the traffic, based on some simple filtering of subjects, then I don't see how you can expect to be privy to important development decisions -- they many times hide in plain sight, and filtering based on which list they are posted to will not help. Maybe you expect Lars and myself to do the filtering job for you and others: analyze the issues, decide which ones are important enough, start threads with prominent enough Subject lines that draw attention, etc. But that is a large job, and it's unfair to expect us to do that for others, especially as we have no clear idea who sees what changes as worthy of their attention. People who have trouble keeping up with the traffic here, but still do want to be involved, should find their own local solutions: smart filtering, sophisticated tools to identify and flag messages that are worth reading, etc. Such tools and methods are not unheard of nowadays. We even have some of them in Emacs. Or people could write them for themselves. > so people who want to be more involved are invited to > > do that. By contrast, the burden on Lars and myself to make sure we > > start a discussion about every change which might require it is > > considerable. > > I agree. I don't think that you, the maintainers, should have to do this. Who will do it, then? I already said that if volunteers step up to this job, I certainly won't mind. Did someone volunteer and I missed that? > Anyway, let's agree that you maintainers shouldn't have a burden from this. Agreed.
> > Maybe there is no discussion *prior* to the change, but if the change
> > ends up being controversial, there is pretty much always a discussion
> > (long) before the next release.
>
> Not always. We just had a case where there wasn't. I am simply trying
> to ensure that the discussion will happen before the next release.
Yes, that's been clear from the beginning.
We just disagree,
Stefan
> > Maybe there is no discussion *prior* to the change, but if the change
> > ends up being controversial, there is pretty much always a discussion
> > (long) before the next release.
>
> Not always. We just had a case where there wasn't. I am simply trying
> to ensure that the discussion will happen before the next release.
[ Here's another take on it. ]
Feel free to do that,
Stefan
>> It is happening in the "Stop frames stealing each other's minibuffers"
>> thread
>
> No, it doesn't. In fact, the exact opposite happens there: an
> assumption that the existing behavior is a bug was later reversed based
> on feedback from you and others.
>
Alas, this is not what is happening there. The old behavior has been
lost, and the developer who initiated these changes still firmly believes
that the old behavior is "an ad hoc unsystematic mess, not worthy even of
being called a behaviour", that it is "chaotic", that it is an "abstruse
"design" [that] can only have arisen by accident", that it "would get
rejected out of hand, and indeed ridiculed" if it were proposed now. In
spite of this, an approximation of the old behavior is now planned, and
I'm supposed to document where that current approximation differs from the
old behavior, to fix the current approximation. There is of course no
chance that the behavior of an UI element as complex as the minibuffer
could ever be recovered by working that way.
> Alas, this is not what is happening there. The old behavior has been lost,
> and the developer who initiated these changes still firmly believes that
> the old behavior is "an ad hoc unsystematic mess, not worthy even of being
> called a behaviour", that it is "chaotic", that it is an "abstruse "design"
> [that] can only have arisen by accident", that it "would get rejected out
> of hand, and indeed ridiculed" if it were proposed now. In spite of this,
> an approximation of the old behavior is now planned, and I'm supposed to
> document where that current approximation differs from the old behavior, to
> fix the current approximation. There is of course no chance that the
> behavior of an UI element as complex as the minibuffer could ever be
> recovered by working that way.
I don't always agree with Alan, but I think in this case his analysis is
about right (tho his wording may be less diplomatic than I'd put it):
based on looking at the code, I think it's clear that the old behavior
was not the result of conscious design, but rather the result of ad-hoc
fixes for specific situations.
Based on the experience with the new code, I agree with you that the old
behavior, while ad-hoc, was a fairly good middle-ground. But I think
it's valuable to work back from that old ad-hoc solution and try and
re-implement it in a more "conscious design" way.
The end result will probably not be 100% identical, but it should help
us get a code we understand better, compared to the old code whose logic
was very much unclear.
IOW, I think the right way to look at it is as a refactoring, which
clarifies the code and brings new alternative behaviors.
Stefan
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > One of the things Richard had in mind in his proposal was "poll the users > and see who likes [the new behavior] _and why_". Perhaps I misunderstood > what he meant, but for me "the users" is much broader than "people who > track the Emacs development". I've made several different proposals. One of them includes that step. They're all aimed at trying to stop changes in default behavior from getting intentionally installed without giving at least the people on emacs-devel a chance to object before it is in a release. I realize that sometimes bug fixes cause a UI change as an unintentional byproduct. That's a different issue and I am not trying to do address it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> Date: Thu, 07 Jan 2021 23:34:09 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, rudalics@gmx.at,
> emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net
>
>
> >> It is happening in the "Stop frames stealing each other's minibuffers"
> >> thread
> >
> > No, it doesn't. In fact, the exact opposite happens there: an
> > assumption that the existing behavior is a bug was later reversed based
> > on feedback from you and others.
>
> Alas, this is not what is happening there. The old behavior has been
> lost, and the developer who initiated these changes still firmly believes
> that the old behavior is "an ad hoc unsystematic mess, not worthy even of
> being called a behaviour", that it is "chaotic", that it is an "abstruse
> "design" [that] can only have arisen by accident", that it "would get
> rejected out of hand, and indeed ridiculed" if it were proposed now. In
> spite of this, an approximation of the old behavior is now planned, and
> I'm supposed to document where that current approximation differs from the
> old behavior, to fix the current approximation. There is of course no
> chance that the behavior of an UI element as complex as the minibuffer
> could ever be recovered by working that way.
There's no contradiction between what I said and what you say, when we
consider what happens in practice. In practice Alan works on
providing an option to have the best approximation to past behavior
that is practical, given the extensive source code changes he has
done. That is consistent with the "best effort" nature of providing
backward compatibility in such cases, so I'm okay with that. We have
other cases where changes were so extensive that providing the 100%
backward-compatibility option is impractical. (This is one reason why
a dogmatic rule for providing such options is something I cannot agree
to.)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > >> Do you have any evidence to back up the claim that this has happened? > > > > It happened with y-or-n-p; it would not have happened with the above > > guideline. > I don't think the second part of that sentence logically follows from > the first. I think I was the first person to complain about it. An entry in etc/NEWS would probably not have come to my attention, since I don't check it regularly. But a posting on emacs-devel is something I would have noticed. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] With luck, the effort to reimplement something like the old behavior will work enough that everyone is more or less satisfied. How about if we give people a chance to try? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> From: Richard Stallman <rms@gnu.org>
> Cc: ghe@sdf.org, juri@linkov.net, rudalics@gmx.at,
> monnier@iro.umontreal.ca, eliz@gnu.org, emacs-devel@gnu.org
> Date: Sat, 09 Jan 2021 01:34:32 -0500
>
> I think I was the first person to complain about it. An entry in
> etc/NEWS would probably not have come to my attention, since I don't
> check it regularly. But a posting on emacs-devel is something I would
> have noticed.
Reading NEWS each time one updates from the development branch of the
repository is something we expect from every user. I suggest to start
reading it when you build a new development version: NEWS is our
standard way of announcing all the user-visible changes, and we invest
some serious effort in keeping it up-to-date and accurate.
>
> Based on the experience with the new code, I agree with you that the old
> behavior, while ad-hoc, was a fairly good middle-ground. But I think
> it's valuable to work back from that old ad-hoc solution and try and
> re-implement it in a more "conscious design" way.
>
> The end result will probably not be 100% identical, but it should help
> us get a code we understand better, compared to the old code whose logic
> was very much unclear.
>
> IOW, I think the right way to look at it is as a refactoring, which
> clarifies the code and brings new alternative behaviors.
>
I fully agree with you.
>>>> Do you have any evidence to back up the claim that this has happened?
>>>
>>> It happened with y-or-n-p; it would not have happened with the above
>>> guideline.
>
>> I don't think the second part of that sentence logically follows from
>> the first.
>
> I think I was the first person to complain about it. An entry in
> etc/NEWS would probably not have come to my attention, since I don't
> check it regularly. But a posting on emacs-devel is something I would
> have noticed.
>
The proposal was not to mention such changes in NEWS (which is already the
case), it was to use the existing criterion used to add entries in NEWS
("Any change that matters to end-users should have an entry in etc/NEWS",
see CONTRIBUTE) as a basis for an explicit guideline: "In principle, any
such change should, unless it is an added feature, either require setting
a variable to be enabled, or be reversible by setting a variable."
(The word "should" here has the meaning of RFC 2119: "This word [...]
mean[s] that there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be understood and
carefully weighed before choosing a different course.")
>
> With luck, the effort to reimplement something like the old behavior
> will work enough that everyone is more or less satisfied. How about if
> we give people a chance to try?
>
I'm an engineer, I don't believe in luck, I believe in care. The right
way to handle this problem is what Stefan said:
1. Start with the old code / behavior
2. Carefully refactor that code to make the implicit behavior explicit,
and to make room for other possible behaviors
3. Add other behaviors
> Date: Sat, 09 Jan 2021 09:34:26 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com,
> monnier@iro.umontreal.ca, rudalics@gmx.at, emacs-devel@gnu.org,
> juri@linkov.net
>
> 1. Start with the old code / behavior
>
> 2. Carefully refactor that code to make the implicit behavior explicit,
> and to make room for other possible behaviors
>
> 3. Add other behaviors
That isn't always possible in software engineering. Sometimes you
need to throw away the old code and rewrite it from scratch, using
what you perceive as the requirements as your guide. For example,
when the old code was written based on some restriction that you want
to lift, it can be impractical refactoring the code if too many of its
parts have that restriction implicitly hard-coded in the algorithm.
I've bumped into this a couple of times when I made the Emacs display
engine support bidirectional text.
Eli Zaretskii <eliz@gnu.org> writes: >> From: Richard Stallman <rms@gnu.org> >> Cc: ghe@sdf.org, juri@linkov.net, rudalics@gmx.at, >> monnier@iro.umontreal.ca, eliz@gnu.org, emacs-devel@gnu.org >> Date: Sat, 09 Jan 2021 01:34:32 -0500 >> >> I think I was the first person to complain about it. An entry in >> etc/NEWS would probably not have come to my attention, since I don't >> check it regularly. But a posting on emacs-devel is something I would >> have noticed. > > Reading NEWS each time one updates from the development branch of the > repository is something we expect from every user. I suggest to start > reading it when you build a new development version FWIW, after pulling changes, one can ask Git "What changed in NEWS since my last update?" like so: git diff @{1} etc/NEWS "@{1}" means "the previous value of the current branch" (cf. gitrevisions(7)). While I personally spend a few minutes reading every commit after fetching[1], I wouldn't fault anyone for not watching etc/NEWS conscientiously. All the ways I can think of[2] (that do not involve fiddling with Git) fail to limit their output to my last update, so they are not as user-friendly as ticking messages off a mailing list. A list like emacs-diffs focusing on etc/NEWS would make sense to me; it would be lower-volume than either bug-gnu-emacs or emacs-devel, so it would be harder for readers to miss (documented) user-facing changes. And such a list would expose those changes once they have taken a concrete form (committed patches, applied and ready to be tried out); this is easier to pick apart than week-long exchanges of dozens of messages, featuring half as many versions of one (or more) patch(es), all of them possibly dismissed because of unevocative subject lines. NB: these are just ideas to make user-facing changes more visible for people tracking the development branch; they are orthogonal to Gregory's tentative guideline of considering new user settings for every change worth mentioning in NEWS, to allow users to opt out of new features. [1] With some amount of arbitrary filtering, e.g. - Is there a bug ID? ⇒ skim (probably saw it on bug-gnu-emacs) - Does the title refer to platforms/packages I don't care about? ⇒ skim (maybe some nice coding tricks to glean from the diff) - Does the message contain a non-ChangeLog summary? ⇒ read it (less noisy than ChangeLog entries IMO) - Does the commit have NEWS entries? ⇒ read them (to learn about new knobs to tweak) - Does the commit touch on areas of personal interest? ⇒ read the diff [2] C-x p f etc/NEWS RET C-x v l https://git.savannah.gnu.org/cgit/emacs.git/log/etc/NEWS
> From: Kévin Le Gouguec <kevin.legouguec@gmail.com> > Cc: rms@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at, > stefankangas@gmail.com, ghe@sdf.org, juri@linkov.net, > monnier@iro.umontreal.ca > Date: Sat, 09 Jan 2021 15:06:15 +0100 > > > Reading NEWS each time one updates from the development branch of the > > repository is something we expect from every user. I suggest to start > > reading it when you build a new development version > > FWIW, after pulling changes, one can ask Git "What changed in NEWS since > my last update?" like so: > > git diff @{1} etc/NEWS > > "@{1}" means "the previous value of the current branch" > (cf. gitrevisions(7)). Why not git log -p --since="<last date I updated>" etc/NEWS ? It's easier, since it frees the user from remembering the tricky syntax of reflog-revisions. Or how about simply using "C-x h C-x v h" with NEWS the current buffer? One can stop reading when one gets to the date of the previous update from Git. > While I personally spend a few minutes reading every commit after > fetching[1], I wouldn't fault anyone for not watching etc/NEWS > conscientiously. I wouldn't, either. But people who are interested in tracking the development, not just in having the latest version, should do that, and if they don't, there should be little surprise that some developments are left unnoticed. Right? > A list like emacs-diffs focusing on etc/NEWS would make sense to me; Sure, if someone wants to set that up, and there are people who'd like to have that, why not? OTOH, it shouldn't be hard to subscribe to emacs-diffs and only read the changes to NEWS in it with some simple filter. This is Emacs, after all.
Eli Zaretskii <eliz@gnu.org> writes: >> git diff @{1} etc/NEWS >> >> "@{1}" means "the previous value of the current branch" >> (cf. gitrevisions(7)). > > Why not > > git log -p --since="<last date I updated>" etc/NEWS > > ? > > It's easier, since it frees the user from remembering the tricky > syntax of reflog-revisions. > > Or how about simply using "C-x h C-x v h" with NEWS the current > buffer? One can stop reading when one gets to the date of the > previous update from Git. Right; my suggestion came from assuming that (1) remembering the date of the previous update is bothersome (2) one can set an alias to hide away the reflog syntax (which I also won't fault anyone for not wanting to waste brain cells on): git config alias.wassup 'diff @{1} etc/NEWS' >> While I personally spend a few minutes reading every commit after >> fetching[1], I wouldn't fault anyone for not watching etc/NEWS >> conscientiously. > > I wouldn't, either. But people who are interested in tracking the > development, not just in having the latest version, should do that, > and if they don't, there should be little surprise that some > developments are left unnoticed. Right? Absolutely! I'm mostly pondering ways to make changes to NEWS easier to track, although I admit I don't think this would entirely solve the issues raised in the parent thread. > OTOH, it shouldn't be hard to subscribe to emacs-diffs and only read > the changes to NEWS in it with some simple filter. This is Emacs, > after all. That ought to work just as well, yes.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The proposal was not to mention such changes in NEWS (which is already the > case), it was to use the existing criterion used to add entries in NEWS > ("Any change that matters to end-users should have an entry in etc/NEWS", > see CONTRIBUTE) as a basis for an explicit guideline: "In principle, any > such change should, unless it is an added feature, either require setting > a variable to be enabled, or be reversible by setting a variable." I'm sorry I read too fast before. Now I see your idea, and I think it is a good one. One of my proposals is equivalent to adding this to your idea. If it is made reversible. then the people who add it should also post on emacs-devel about it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Which is why we are doing that in every case where we decide that the > change could be (or is) controversial. That is the intention. Some of my alternative proposals aim to systematically make sure to put it into practice. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Not always. We just had a case where there wasn't. I am simply trying > > to ensure that the discussion will happen before the next release. > Yes, that's been clear from the beginning. > We just disagree, The reason I think it matters whether the discussion happens before the next release, or after, is that I was told that after a release there is a presumption in favor of not reverting the change that was made. It adds up to a bureaucratic pitfall you can get stuck in for not reading all the bug report mail. We can't please everyone, but it is especially frustrating to be told that your complaint will be disregarded because it is too late. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, rudalics@gmx.at, eliz@gnu.org,
> emacs-devel@gnu.org, drew.adams@oracle.com, juri@linkov.net
> Date: Wed, 13 Jan 2021 10:57:36 -0500
>
> The reason I think it matters whether the discussion happens
> before the next release, or after, is that I was told that
> after a release there is a presumption in favor of not reverting
> the change that was made. It adds up to a bureaucratic pitfall you
> can get stuck in for not reading all the bug report mail.
>
> We can't please everyone, but it is especially frustrating to be told
> that your complaint will be disregarded because it is too late.
We never disregard such complaints. We just need a stronger reason to
make the change in that case, and it should be stronger as the time
since releasing the offending feature becomes longer.
The assumption is that if we didn't have a complaint during all the
time the features was on the development branch and then in the
pretests, it probably means most people are okay with it.
> > Its name should be consistent with another variable
> > use-short-answers that could be used to replace
> > yes-or-no-p with y-or-n-p. These two should have names
> > that preclude confusion between their meanings.
>
> > Also use-short-answers could be used by the existing variable
> > read-answer-short.
>
> That might be good, but needs working out the details.
Maybe also there is a need to add a separate option that
turns short y-or-n-p queries to long yes-or-no-p questions?
So when it's non-nil and y-or-n-p is called, it will redirect
the prompt to yes-or-no-p to ask a long yes-or-no question.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The assumption is that if we didn't have a complaint during all the > time the features was on the development branch and then in the > pretests, it probably means most people are okay with it. That is a valid conclusion, as regards experienced users. But surely that should not impede us from adding a user option to get the old behavior -- if due to an omission we did not make one. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Maybe also there is a need to add a separate option that > turns short y-or-n-p queries to long yes-or-no-p questions? It is not something I personally want, but I am not arguing against it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
> From: Richard Stallman <rms@gnu.org>
> Cc: juri@linkov.net, rudalics@gmx.at, monnier@iro.umontreal.ca,
> larsi@gnus.org, emacs-devel@gnu.org, drew.adams@oracle.com
> Date: Fri, 15 Jan 2021 00:28:06 -0500
>
> > The assumption is that if we didn't have a complaint during all the
> > time the features was on the development branch and then in the
> > pretests, it probably means most people are okay with it.
>
> That is a valid conclusion, as regards experienced users.
>
> But surely that should not impede us from adding a user option
> to get the old behavior -- if due to an omission we did not
> make one.
It doesn't impede us. Where adding an option is practical, it is
certainly a good solution for such problems. The assumption I
described above is a factor in the decision whether to revert a
change, not whether to make it optional. The latter is a no-brainer
where it's feasible.
[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It doesn't impede us. Where adding an option is practical, it is > certainly a good solution for such problems. The assumption I > described above is a factor in the decision whether to revert a > change, not whether to make it optional. The latter is a no-brainer > where it's feasible. That is reassuring. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)