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

Evilify Macro #9

Closed
jojojames opened this issue Nov 5, 2017 · 8 comments
Closed

Evilify Macro #9

jojojames opened this issue Nov 5, 2017 · 8 comments

Comments

@jojojames
Copy link
Collaborator

jojojames/evil-integrations#1 (comment)

(15) Evilify macros: Why not using the expansion of those macros? ;)
I think it's important to keep our bindings as readable as possible to anyone. Consider there might be newcommers from Vim who do not know Elisp.
Last but not least, the macro does the easy part, that is, the most trivial bindings. Those are usually a matter of copy-pasting and can be done within minutes. The hard part cannot be derived automatically.
So the "better than nothing" can also be done with explicit binding very quickly I think.

The evilify macro does quite a bit, it actually rebinds the pre-existing mode bindings up a waterfall style way.

Hand editing the mode bindings for even simple bindings might not be as simple as one would expect because of that.

@Ambrevar
Copy link
Collaborator

Ambrevar commented Nov 8, 2017

While evilify might be convenient for now, I think it's a poor long term solution for the reasons already mentioned (less readable, more dependable, etc.).

Let's keep this in mind for the near future.

@jojojames
Copy link
Collaborator Author

What I mean by the above is if someone wants to go and add bindings for a new mode using the evilify macro, I wouldn't have too big a problem with it.

But if someone else goes in and rewrites the bindings with just evil-define-key, that'd make the previous bindings obsolete and we should then replace it.

I think it fulfill the best of both worlds. Having some vim bindings regardless of how it's written is better than none. But having vim bindings written the correct way is better than otherwise.

For huge modes like gnus for example, it might be appropriate until someone wants to put in the time to do the whole mode by hand.

As for myself, my plan is to rewrite some of the bindings or add new ones with the regular evil-define-key (like doc-view, arc-mode recently).

@Ambrevar
Copy link
Collaborator

Ambrevar commented Nov 8, 2017

Sure, I get your point.

Let's keep in mind that if we want contribution from the community, the current bindings should serve as an example. Else let's add at least a big WARNING at the beginning of each unfinished file, advising the contributor to look at <good-bindings.el> to get inspiration from.

@jojojames
Copy link
Collaborator Author

Let's keep in mind that if we want contribution from the community, the current bindings should serve as an example.

If there's a contribution using evilify, I am fine with it since it's better than nothing. A quick comment explaining the preferred binding choice can just go into the README.

@Ambrevar
Copy link
Collaborator

Ambrevar commented Dec 7, 2017

I saw you've move from using evil-collection-util to defining bindings explicitly in most modes. Thank you very much!

A quick search yields 3 last modes using the macros: edebug, ibuffer, slime. Any plan for them?

@jojojames
Copy link
Collaborator Author

I want to get to transitioning all of them and then removing the macros but they are a lot of work.

If anyone wanted to volunteer to convert them, that'd be great!

Otherwise, I'll try to get to them as I find the interest in converting those keymaps.

@jojojames
Copy link
Collaborator Author

@Ambrevar You'll be happy with this. ;)

df5d161

We probably still need to continue polishing those keybindings but the evilify macro is gone.

@Ambrevar
Copy link
Collaborator

Ambrevar commented Dec 9, 2017

Excellent, thank you very much for the hard work!

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