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 _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
