Confused by y-or-n-p

Confused by y-or-n-p

[Eli Zaretskii]

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.

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Jean Louis]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Karl Fogel]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[David Masterson]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[João Távora]

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

Re: Confused by y-or-n-p

[Karl Fogel]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[martin rudalics]

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

Re: Confused by y-or-n-p

[martin rudalics]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[martin rudalics]

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

Re: Confused by y-or-n-p

[martin rudalics]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Sv: Confused by y-or-n-p

[arthur miller]

[-- 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 --]

Re: Confused by y-or-n-p

[Eli Zaretskii]

> 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Jean Louis]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

RE: Confused by y-or-n-p

[Drew Adams]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

RE: Confused by y-or-n-p

[Drew Adams]

> 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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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.

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Juri Linkov]

[-- 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);

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

RE: Confused by y-or-n-p

[Drew Adams]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Stefan Kangas]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[martin rudalics]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Alan Mackenzie]

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

Re: Confused by y-or-n-p

[Andrea Corallo via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Alan Mackenzie]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Dmitry Gutov]

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.

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Lars Ingebrigtsen]

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

Re: Confused by y-or-n-p

[Alan Mackenzie]

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

Re: Confused by y-or-n-p

[tomas]

[-- 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 --]

Re: Confused by y-or-n-p

[Alan Mackenzie]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[martin rudalics]

 > 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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Stefan Kangas]

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.

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

RE: Confused by y-or-n-p

[Drew Adams]

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

Re: Confused by y-or-n-p

[Tassilo Horn]

> 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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Tassilo Horn]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Alfred M. Szmidt]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Stefan Kangas]

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/

Re: Confused by y-or-n-p

[Stefan Kangas]

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.

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Stefan Kangas]

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.

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Stefan Monnier]

> 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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Stealing minibuffers [Was: Confused by y-or-n-p]

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Confused by y-or-n-p

[Gregory Heytings via Emacs development discussions.]

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

Re: Stealing minibuffers [Was: Confused by y-or-n-p]

[Gregory Heytings via Emacs development discussions.]

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

Re: Stealing minibuffers [Was: Confused by y-or-n-p]

[Eli Zaretskii]

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

Following etc/NEWS on the development branch (was: Confused by y-or-n-p)

[Kévin Le Gouguec]

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

Re: Following etc/NEWS on the development branch (was: Confused by y-or-n-p)

[Eli Zaretskii]

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

Re: Following etc/NEWS on the development branch

[Kévin Le Gouguec]

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.

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Juri Linkov]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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

Re: Confused by y-or-n-p

[Eli Zaretskii]

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

Re: Confused by y-or-n-p

[Richard Stallman]

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