After a few evil days...

[Frank Fischer]

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