Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change default value of evil-overriding-maps to an empty list #1488

Closed
condy0919 opened this issue Jul 7, 2021 · 6 comments
Closed

Change default value of evil-overriding-maps to an empty list #1488

condy0919 opened this issue Jul 7, 2021 · 6 comments

Comments

@condy0919
Copy link
Contributor

Issue type

  • Question

Further notes

(defcustom evil-overriding-maps
  '((Buffer-menu-mode-map . nil)
    (color-theme-mode-map . nil)
    (comint-mode-map . nil)
    (compilation-mode-map . nil)
    (grep-mode-map . nil)
    (dictionary-mode-map . nil)
    (ert-results-mode-map . motion)
    (Info-mode-map . motion)
    (speedbar-key-map . nil)
    (speedbar-file-key-map . nil)
    (speedbar-buffers-key-map . nil)))

Where

  • Buffer-menu
  • comint
  • compile
  • grep
  • dictionary
  • ert
  • Info
  • speed

are all supported by evil-collection except for color-theme which is a third library and obsolete. So I propose to change the default value of evil-overriding-maps to '().

@tomdl89
Copy link
Member

tomdl89 commented Jul 8, 2021

This is a tricky one. There are three types of users I'm thinking about:

  1. Experienced users who don't want evil overridden anywhere (who would customize this to '()
  2. Experienced users who want finer control or wider support (who would probably use evil-collection)
  3. New users who are not aware of evil-collection

My concern is that by defaulting this to '() we'd be making life a little more difficult for users in the third category when visiting buffers in the above modes.
Thoughts?

@condy0919
Copy link
Contributor Author

condy0919 commented Jul 8, 2021

We can experimentally set it to '() as emacs maintainers unbind M-o https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00537.html

If there is no bug reports for 3 months, it means this change is accepted by most of users.

Or start a poll?

@tomdl89
Copy link
Member

tomdl89 commented Jul 8, 2021

The problem with this idea, is that waiting for complaints or running a poll, almost by their nature, exclude new users. Newbies are not going to know what they're missing, and they're most likely not going to be browsing this repo, or any other forum where you may want to run a poll. Before we try experimental changes or polling, I think it would be most helpful if you could make an argument or two in favour of your idea, so I can weigh up the pros/cons.

@condy0919
Copy link
Contributor Author

condy0919 commented Jul 8, 2021

For the case 3, the most frequent keys, such as h, l and g, are not evilified (e.g. M-x info, h -> Info-help, l -> Info-history-back, g -> Info-goto-node) which will be more confusing to evil beginners. They don't known why h/l not working.

@condy0919
Copy link
Contributor Author

@tomdl89 ping. Thoughts?

@tomdl89
Copy link
Member

tomdl89 commented Jul 14, 2021

I think you're right actually. The topic of where evil is or is not overriding / being overridden is complicated, and evil-overriding-maps doesn't appear to help newbies as much as I had thought. When I changed the value to '() and restarted emacs, I could still see that some evil keys were overridden by e.g. buffer-menu-mode-map, (although some were no longer overridden). If this variable's current value resulted in intuitive behaviour, I would be inclined to keep it as it is. But it does not, so feel free to make a PR and we'll see if we get any bug reports.

condy0919 added a commit to condy0919/evil that referenced this issue Jul 15, 2021
It's more intuitive for evil beginners if no keymap overriding evil maps.

fix emacs-evil#1488
condy0919 pushed a commit to emacs-evil/evil-collection that referenced this issue Sep 4, 2021
condy0919 pushed a commit to emacs-evil/evil-collection that referenced this issue Sep 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants