Hi, I'm very excited to get away from viper and you really did a nice job with evil. Thank you! I've got some points, though. * Motion commands don't play nice with chars not found in ASCII Test for example with "Pröblem" * Input-Method-Handling is missing In my case everythings fine except normal and visual state but they don't like my input method ("german-postfix"). I came up with this, I hope it helps someone until there's real support: * evil-states are no good default Currently I add about 20 modes to `evil-emacs-state-modes', most of them are third-party and not about editing but are specialized and add their own set of keybindings. I think it would make the life of users far easier and their config thinner to switch to emacs-state if the mode isn't in `evil-insert-state-modes' or `evil-motion-state-modes' (and maybe add a `evil-normal-state-modes'). * I'd like to help with developing evil is there a roadmap or feature list to work on? I found the issue tracker at bitbucket, but there are only real issues. Or is there a better point to start development? Michael
On Mon, Aug 08, 2011 at 12:32:06AM +0200, Michael Markert wrote:
Hi,
I'm very excited to get away from viper and you really did a nice job with evil. Thank you!
You're welcome, but don't hesitate to say this again ... ;)
I've got some points, though.
* Motion commands don't play nice with chars not found in ASCII Test for example with "Pröblem"
Fixed in a15c747. Word characters are defined in the variable `evil-word' which had been set to a-zA-Z0-9_. The new default is [:word:]_ which should include non-ASCII characters and `evil-word' is customizable now.
* Input-Method-Handling is missing
Well, that's right. Input methods have to be deactivated in normal and visual-state but should be active in operator-pending state. We have to work on this ...
* evil-states are no good default
Currently I add about 20 modes to `evil-emacs-state-modes', most of them are third-party and not about editing but are specialized and add their own set of keybindings.
I think it would make the life of users far easier and their config thinner to switch to emacs-state if the mode isn't in `evil-insert-state-modes' or `evil-motion-state-modes' (and maybe add a `evil-normal-state-modes').
This can be argued. Almost all modes that I use are editing modes and for me it is easier to have evil come up in normal-state as default. Perhaps we could add a switch to select the default for all modes that are listed in none of those mode-lists (and add `evil-normal-state-modes' as well). Of course, the best possibility would be to detect whether the current major-mode is indeed an editing mode, but I have no good idea how to accomplish (one, could, e.g., detect whether the mode is derived from text-mode, but this is not true for all editing modes). Another useful feature could be to define a new (ex-?)command (e.g., :set-evil-default) to change the default mode for the current major-mode. I had something like this in vim-mode and it worked quite well. This way the users do not have to change their config by manually editing the file but the customization is changed (semi-)automatically.
* I'd like to help with developing evil is there a roadmap or feature list to work on?
I found the issue tracker at bitbucket, but there are only real issues. Or is there a better point to start development?
We integrated the issue tracker very recently, so there's not much in there. In the meantime we used the wiki on gitorious to discuss our plans. In my opinion (I do not know about Vegard?) the only thing missing is ex mode. I hope I can finish it by the end of this week, but we will see. Besides evil contains already all featues a want for the 1.0 release. This means the most urgent things are finding bugs, missing key-bindings and commands/motions that really should go into 1.0 (and, of course, someone has to deal with input-method stuff ... ;)). Furthermore there are the tedious tasks like writing the documentation. The public api should be fixed (and we should define what belongs to the public api and must therefore not change for 1.x), packages for elpa (or so) have to be created. So the best everyone can do is to use evil in the daily work and report bugs and missing features (send patches, if possible), tell us what is really missing and praise the developers. Frank
On 8 Aug 2011, Frank Fischer wrote:
On Mon, Aug 08, 2011 at 12:32:06AM +0200, Michael Markert wrote:
I'm very excited to get away from viper and you really did a nice job with evil. Thank you!
You're welcome, but don't hesitate to say this again ... ;)
Well then: I f*ckin love the prefix :D
* Input-Method-Handling is missing
Well, that's right. Input methods have to be deactivated in normal and visual-state but should be active in operator-pending state. We have to work on this ...
I think my code does that already. But I'm not sure how robust it is. The handling in viper looks quite messy so I rather not copy it.
* evil-states are no good default
This can be argued. Almost all modes that I use are editing modes and for me it is easier to have evil come up in normal-state as default.
Perhaps we could add a switch to select the default for all modes that are listed in none of those mode-lists (and add `evil-normal-state-modes' as well). Of course, the best possibility would be to detect whether the current major-mode is indeed an editing mode, but I have no good idea how to accomplish (one, could, e.g., detect whether the mode is derived from text-mode, but this is not true for all editing modes).
I like the idea to user-define the default, because it's highly dependent on the user, as you mentionend.
Another useful feature could be to define a new (ex-?)command (e.g., :set-evil-default) to change the default mode for the current major-mode. I had something like this in vim-mode and it worked quite well. This way the users do not have to change their config by manually editing the file but the customization is changed (semi-)automatically.
I keep my config under version control and don't like them changed automatically, but I think that's a nice feature to have, though.
In my opinion (I do not know about Vegard?) the only thing missing is ex mode. I hope I can finish it by the end of this week, but we will see. Besides evil contains already all featues a want for the 1.0 release. This means the most urgent things are finding bugs, missing key-bindings and commands/motions that really should go into 1.0 (and, of course, someone has to deal with input-method stuff ... ;)).
Well then I'll take a deeper look at the input-method stuff ;)
Furthermore there are the tedious tasks like writing the documentation. The public api should be fixed (and we should define what belongs to the public api and must therefore not change for 1.x), packages for elpa (or so) have to be created.
I noticed the PDF documentation but there are no sources in the repository: What's the format of choice to generate the docs? From the PDF I'd deduce it's LaTeX, but where is the source? [1]
So the best everyone can do is to use evil in the daily work and report bugs and missing features (send patches, if possible), tell us what is really missing and praise the developers.
Sure will do! I think I already got 2 Bugs, I'll carry those to the issue tracker. Michael Footnotes: [1] As Texinfo would be nice to have (info files), there's pandoc[2]. But I've not yet worked with it and don't know how well it supports LaTeX (it says a subset). [2] http://johnmacfarlane.net/pandoc/
On Mon, Aug 08, 2011 at 12:24:28PM +0200, Michael Markert wrote:
I noticed the PDF documentation but there are no sources in the repository: What's the format of choice to generate the docs? From the PDF I'd deduce it's LaTeX, but where is the source? [1]
It's written in TexInfo and the source is still in the 'doc' branch. So maybe pandoc is worth a look, never used it. Frank
On 8 Aug 2011, Frank Fischer wrote:
It's written in TexInfo and the source is still in the 'doc' branch.
Oh I never thought of this. Is there a reason to keep it separate from the code on its own branch?
So maybe pandoc is worth a look, never used it.
Since it's already written in texinfo it's maybe not worth it. Michael
Am Mon, 08 Aug 2011 19:52:14 +0200 schrieb Michael Markert <[email protected]>:
On 8 Aug 2011, Frank Fischer wrote:
It's written in TexInfo and the source is still in the 'doc' branch.
Oh I never thought of this. Is there a reason to keep it separate from the code on its own branch?
Just historic reasons, it has been created when we started and introduced new rules in the Makefile and so on. We're going to merge that branch back very soon. Frank
On 2011-08-08 00:32 +0200, Michael Markert wrote:
I think it would make the life of users far easier and their config thinner to switch to emacs-state if the mode isn't in `evil-insert-state-modes' or `evil-motion-state-modes' (and maybe add a `evil-normal-state-modes').
Commit dedf81c adds a `evil-default-state' variable for this purpose: (setq evil-default-state 'emacs) This makes all unlisted modes come up in Normal state. (You can set the initial state for a mode with the function `evil-set-initial-state'.) -- Vegard
On 9 Aug 2011, Vegard Øye wrote:
On 2011-08-08 00:32 +0200, Michael Markert wrote:
I think it would make the life of users far easier and their config thinner to switch to emacs-state if the mode isn't in `evil-insert-state-modes' or `evil-motion-state-modes' (and maybe add a `evil-normal-state-modes').
Commit dedf81c adds a `evil-default-state' variable for this purpose:
(setq evil-default-state 'emacs)
This makes all unlisted modes come up in Normal state. (You can set the initial state for a mode with the function `evil-set-initial-state'.)
Thanks for this. Maybe add a `evil-normal-state-modes'? The reason why I brought this up (and forgot to mention) is that it may be more easy to compile a list of editing modes than of misc modes (think of magit and so on). I also opened a merge request to add more modes to emacs-state and insert-state. Michael
participants (3)
-
Frank Fischer -
Michael Markert -
Vegard Øye