Christoph LANGE | 1 Mar 11:54 2012
Picon

Re: Why I stopped using viper, and am going to stop using Evil

Hi Matt,

my 2 cents, well, maybe 10 cents, on your mail.

In short: Thanks for sharing your experience!  Mine is quite different 
though.

2012-02-29 20:36 Matt Armstrong:
> In short: it is easier to use one editor at a time.

In contrast to your experience, I appreciate to be able to use two 
editors at a time, and only Evil gives me the opportunity to do so.

I frequently use any Emacs keybindings that have not been overloaded 
with vim keybindings by Evil.  Not just the C-x and C-c prefixes, but 
also a lot of M-something.

Sometimes Emacs is just more convenient than vi.  Take for example M-c 
(capitalize-word).  This key has no meaning in vim (AFAIK), and it works 
both in Evil's normal mode and in insert mode.

I don't care about the theoretical possiblity to introduce reasonable 
keybindings in vim as well – I wouldn't want to make the effort.

> By default, Evil presents you vim key bindings, but makes you use Emacs key
> bindings too:
>
>   (a) see the huge list of modes in evil-emacs-state-modes

This is a separate problem I'd say, but agree with your concerns about 
(Continue reading)

Tom Short | 1 Mar 13:43 2012
Picon

Re: Why I stopped using viper, and am going to stop using Evil

On Thu, Mar 1, 2012 at 5:54 AM, Christoph LANGE <langec <at> web.de> wrote:
> Hi Matt,
>
> my 2 cents, well, maybe 10 cents, on your mail.
>
> In short: Thanks for sharing your experience!  Mine is quite different
> though.
>
> 2012-02-29 20:36 Matt Armstrong:
>> In short: it is easier to use one editor at a time.
>
> In contrast to your experience, I appreciate to be able to use two
> editors at a time, and only Evil gives me the opportunity to do so.

My perspective is different, too. I've never really used Vim, so
differences between Vim and Emacs don't really cause any headaches for
me. Evil works smoothly for what I do. I might be tempted to try Vim,
but I like Org-mode and ESS (with R) too much. I came to modal
operation by way of using vimperator then pentadactyl in Firefox.

- Tom
Matt Armstrong | 2 Mar 05:18 2012
Picon

Re: Why I stopped using viper, and am going to stop using Evil

Don't get me wrong, I respect that other folks can be quite happy with Evil.  I coded all day today with vanilla Emacs key bindings and found it delightfully...simple and free of paradigm conflicts.  :-)



On Thu, Mar 1, 2012 at 4:43 AM, Tom Short <tshort.rlists <at> gmail.com> wrote:
On Thu, Mar 1, 2012 at 5:54 AM, Christoph LANGE <langec <at> web.de> wrote:
> Hi Matt,
>
> my 2 cents, well, maybe 10 cents, on your mail.
>
> In short: Thanks for sharing your experience!  Mine is quite different
> though.
>
> 2012-02-29 20:36 Matt Armstrong:
>> In short: it is easier to use one editor at a time.
>
> In contrast to your experience, I appreciate to be able to use two
> editors at a time, and only Evil gives me the opportunity to do so.

My perspective is different, too. I've never really used Vim, so
differences between Vim and Emacs don't really cause any headaches for
me. Evil works smoothly for what I do. I might be tempted to try Vim,
but I like Org-mode and ESS (with R) too much. I came to modal
operation by way of using vimperator then pentadactyl in Firefox.

- Tom

_______________________________________________
implementations-list mailing list
implementations-list <at> lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

_______________________________________________
implementations-list mailing list
implementations-list <at> lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Michael Markert | 2 Mar 06:08 2012

Re: Why I stopped using viper, and am going to stop using Evil

Christoph LANGE <langec <at> web.de> writes:

> 2012-02-29 20:36 Matt Armstrong:
>> In short: it is easier to use one editor at a time.
>
> In contrast to your experience, I appreciate to be able to use two 
> editors at a time, and only Evil gives me the opportunity to do so.

Well it's quite a mental burden and they don't mix that easily.

a) Using Emacs makes it really easy to stay in insert-state a lot of time.
b) Vim's undo model works with "iterations" of insert- and normal-state
   changes

Take them together and you know what bites me more often than I like.

Well Evil offers to change the undo granularity, but I really like
the Vim model because it breaks changes down in a semantically related way.

I also appreciate the power of Emacs and Vim at my fingertips but it's
not exactly _easy_.

>> By default, Evil presents you vim key bindings, but makes you use Emacs key
>> bindings too:
>>
>>   (a) see the huge list of modes in evil-emacs-state-modes
>
> This is a separate problem I'd say, but agree with your concerns about 
> this and would also appreciate an Evil solution for it.  There used to 
> be viper-in-more-modes, which gave vi-style keybindings to a number of 
> typical Emacs modes.  Indeed I would prefer vi-style keybindings to be 
> introduced for all modes currently in evil-emacs-state-modes, but it 
> will take time to get them implemented.

As I've pushed quite some into that list, that's my feeling as
well. Many of those modes are some kind of `menu modes': You move your
cursor more easily as in vanilla Emacs (like n & p instead of C-n & C-p)
and do something with the entry at point, archive-mode is a perfect
example of this. (I'm pretty sure there are more mode patterns to find)

Dired _was_ a perfect example of this: It's evilized now.

If we can come up with a way to programmatically evilize a mode-map a
lot of the modes in there will vanish.

The greatest obstacle is where to put conflicting keys maybe in an own
keymap ... but where to bind that keymap?

Any ideas here?

If you want a hard nut to play with: Try magit. They have lots of
(useful) single letter keys, many conflicting with basic vim movement
keys. Most dreadful one being `k' I don't count anymore how often I was
asked (luckily!) if I wanted to kill that chunk/item ...

 <at>  Matt
Well I don't think it's evil's goal to reimplement Vim faithfully
because it'd much more work than just to merge the two (or copy the best
things) with little gain.

I'm also not sure what do you hope to gain with an Emacs that behaves exactly
like Vim but is not Vim.

Am I reading you wrong here? Could you elaborate?

Anyway thanks for your input but sadly I don't think that this can be
solved (or at least only in the long run).

Michael
_______________________________________________
implementations-list mailing list
implementations-list <at> lists.ourproject.org
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Titus von der Malsburg | 2 Mar 16:02 2012
Picon

Re: Why I stopped using viper, and am going to stop using Evil

On Fri, Mar 2, 2012 at 6:08 AM, Michael Markert
<markert.michael <at> googlemail.com> wrote:
>  <at>  Matt
> Well I don't think it's evil's goal to reimplement Vim faithfully
> because it'd much more work than just to merge the two (or copy the best
> things) with little gain.
>
> I'm also not sure what do you hope to gain with an Emacs that behaves exactly
> like Vim but is not Vim.

One of the great benefits of Evil is that it allows me to switch
between Vim and Emacs with little mental effort.  (For me, this marks
nothing less than the end of the great editor wars.)  At work, I often
have to do stuff on machines that don't have Emacs installed.  I love
the fact that, in these situations, I can effortlessly switch to Vim.
For this reason, I think it's highly desirable that things work the
same in Vim and Evil to the extend possible.  Of course Evil should
also take advantage of the all the goodies that are present in Emacs
but where possible it should stick to how things work in Vim.

If Evil would start to deviate from Vim, this would also make it
difficult for new users to switch and it would require a lot of new
documentation for Evil.  Right now, I often just refer to Vim
documentation when I want to know how something works in Evil, which
is great.

  Titus
Zolrath | 5 Mar 00:46 2012
Picon

Keyboard Macros remain in input mode

If I define a macro qw and perform some actions, when I use the macro via  <at> w it
plays back my actions appropriately but remains in input mode after playback.
This differs from vim's macros which will return you to normal mode afterwards.
Frank Fischer | 5 Mar 08:50 2012
Picon

Re: Keyboard Macros remain in input mode

On Sun, Mar 04, 2012 at 11:46:00PM +0000, Zolrath wrote:
> If I define a macro qw and perform some actions, when I use the macro via  <at> w it
> plays back my actions appropriately but remains in input mode after playback.
> This differs from vim's macros which will return you to normal mode afterwards.

Do you use Emacs/Evil in terminal mode? If so, then I assume it's
another problem with the ESC key in terminals (then at least I would
know what the problem is ;))

Frank
Zolrath | 6 Mar 13:32 2012
Picon

Re: Keyboard Macros remain in input mode

Frank Fischer <frank.fischer <at> mathematik.tu-chemnitz.de> writes:

> Do you use Emacs/Evil in terminal mode?

Yes, I'm using it in terminal mode! I'm using it in iTerm2 in xterm-256color
mode if that helps further.
Frank Fischer | 6 Mar 15:58 2012
Picon

Re: Keyboard Macros remain in input mode

On Tue, Mar 06, 2012 at 12:32:43PM +0000, Zolrath wrote:
> Frank Fischer <frank.fischer <at> mathematik.tu-chemnitz.de> writes:
> 
> > Do you use Emacs/Evil in terminal mode?
> 
> Yes, I'm using it in terminal mode! I'm using it in iTerm2 in xterm-256color
> mode if that helps further.

Should be fixed in 8258493

Frank
Titus von der Malsburg | 7 Mar 15:45 2012
Picon

Which map is active when I overwrite text with R

In insert mode, I bind TAB to a custom expand function that is based
on hippie-expand.  However, when I overwrite text with the R command,
I would also like to be able to use the expand function.  During
overwriting, TAB is bound to indent-for-tab-command and unfortunately
it's not clear to me which map is active during overwrite.  Could
somebody please give me a hint?

Thanks!
  Titus

Gmane