emacs-devel
[Top][All Lists]
Advanced

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

Sv: Confused by y-or-n-p


From: arthur miller
Subject: Sv: Confused by y-or-n-p
Date: Sat, 26 Dec 2020 10:41:05 +0000

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)




reply via email to

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