emacs-oob-reboot
emacs-oob-reboot copied to clipboard
Do not (fset 'yes-or-no-p 'y-or-n-p)
This is currently being done in https://github.com/josteink/emacs-oob-reboot/blob/master/lisp/basic-configuration-changes.el
yes-or-no-p
exists so that destructive actions can be protected by something more than a single y
key press. I'm aware that some people do make this change in their configs, but I strongly disagree with it as a default for new users (and I'm mostly sure such a change would never be accepted upstream).
@phil-s I can kind of agree with that. (I'm the one who introduced this change). If the goal is to make Emacs better out of the box, that, to me, means increasing UX parity with other editors....in other visual editors, the prompt might be a GUI popup with a yes/no button. One click to accept/deny. By switching to y/n, it's one button press away. It streamlines the flow.
What's the difference between a single mouse click and a single key press?
Someone's safety-feature is another users get-out-of-my-way-will-you feature.
I'm not against having this setting, but if we're consistently disabling safety-features, maybe we should suggest amending the tutorial with a section about features for improved safety.
@phillord: any opinion?
We are also trying to be more on par with other editors, I personally do not remember any editor that I have ever used to have backup's that suck to an extent and the y/n thing , I mean if you want it COOL! But in general people do not care and it only gets in the way, in my opinion.
There are different possibilities. Most users of emacs that hack elisp change yes-or-no-p to y-or-n-p.
However, if the goal of this project is to make emacs more easily usable for new users, popup a dialog box is the way to go. Curious users will find easily how to change that if they would like to - usually one of the first information that one finds about emacs configuration is how to disable the GUI elements.
Most users of emacs that hack elisp change yes-or-no-p to y-or-n-p.
How have you ascertained this?
However, if the goal of this project is to make emacs more easily usable for new users, popup a dialog box is the way to go.
Emacs already uses dialog boxes if it was a mouse action that triggered the query. If it's not a mouse action, but we enforce a GUI dialog box, then the user needs to switch from keyboard to mouse and back again.
I recognise that entering "yes" or "no" is annoying in some scenarios, but I can't agree with removing the feature on that basis, and enforcing mouse usage seems (to me) to be contrary to the benefits of using Emacs.
It's all very subjective, though.
Emacs already uses dialog boxes if it was a mouse action that triggered the query. If it's not a mouse action, but we enforce a GUI dialog box, then the user needs to switch from keyboard to mouse and back again.
As a long time keyboard-only Emacs user, I did not know this, and I suspect the same applies to lots of other people in this thread.
Personally I feel this strengthens the argument for keeping the changes proposed so far, but I have no big steak in this.
So trying not to take sides here, I think the following comment from the original reddit-thread is relevant:
If you use any of the defaults - any of them, not just key bindings - and those change in the base program, you'll have to add the (now former) defaults to your config to have the same setup as before.
This could break a lot of old configs.
The flip side is of course that it can improve a lot of old configs
Some people seem worried that what we're doing here is going to "break" their configs or workflows. Let's not give them more worries than they need :)
On the other hand, I don't think we should be so afraid to change things that we don't change (improve!) anything significant.
Consider this example: In Emacs 24.5 or Emacs 25.1, they changed prog-mode
so that it by default enabled electric-brace-mode
. Did you know that? Did you even notice? No you probably didn't. because you probably already had it (or electric-pair-mode) configured already, so this was effectively no change at all for you.
This change may have "broken" a few setups and configs out there (for whatever definition of broken the complainer chooses to apply), but I'm willing to bet the majority of users benefited from this change.
That's the kind of settings I'd love to see in this repo.
If an issue is contentious enough here that we can't objectively (or with a clear majority vote) agree that it makes Emacs easier to to use out of the box, maybe we should just refrain from altering these settings.
To not make this an argument we have over and over in every thread... I think we could benefit from creating some common "rules" to play by, some common guidelines. That might also help improve the consistency of the proposed changes (and we all know Emacs-users love consistency).
So before deciding on all the open issues, maybe we should just decide on some core guidelines. I'll make a new issue for that :)
I don't believe that we should blanket change yes-or-no-p
to y-or-n-p
. Rather, I think we need to go a bit further and look in general at usage of the two, see if we can come up with better guidelines (the manual currently says "more momentous consequences"), and then seeing whether we can ensure that they are applied consistently.
There are only about 200 usages of yes-or-no-p so, this is quite plausible.
There is also now yes-no.el
, as described here, which would allow this to be configured on a case-by-case basis.
Actually, it is not even clear to me how to "undo" the line (fset 'yes-or-no-p 'y-or-n-p)
and restore the desired (emacs default) behavior. The only way I know of is to save aside yes-or-no-p
early in the load process before it is overwritten, and then set it again after it is clobbered.
EDIT: Sorry for the spacemacs aside in an earlier revision of this post; I had too many open tabs and got confused about what this issue is about ;-).
I think recent changes to Emacs (eglot, tree-sitter, etc) has helped make Emacs much more usable OOB. Considering repo-purpose obsolete.
Closing all issues and archiving repo. Thanks to all contributors!