October 2012 - implementations-list

Empty line at EOB
by Frank Fischer 30 Oct '12

30 Oct '12

Hi friends of evil, recently there have been a lot of issues related to the final-newline/empty-line-at-eob behavior of Emacs. Before I try to fix those issue and provoke further issues, I would like to discuss the problem in public. When Vegard and I discussed this topic some time ago, we pointed out several advantages and disadvantages of certain approaches to this problem (see below) and decided for one of them. However, the latest bug reports make clear this may not be so easy (I had somehow the feeling at that time that sooner or later someone *will* come up with bug reports but I hoped that they would be easy to solve -- now I'm not so sure about the latter anymore). The purpose of this post is to initiate a discussion about how the problem should be handled in evil. Let me start with a description of the problem. In the unix world a line is usually defined as a sequence of characters followed by a newline character \n. In other words, the newline character is the termination character of a line. Sequences of characters that do not end in a newline are therefore *incomplete* or non-proper lines (some programs even used to refuse working correctly on incomplete lines). This is also visible in text editors like vim. In vim (in standard configuration) each line is automatically terminated by newline (when saved to disk). Furthermore the number of lines in a file is exactly the number of newlines. If vim opens a file with an incomplete last line then it appends that newline when saving the file back to disk (and showing [noeol] in the status bar). But more importantly, it is *impossible* to move the cursor beyond that last newline. This means if a file contains "abc\n" vim shows one line and the cursor cannot be moved to the second line. Emacs is different. Emacs can also append a missing newline to a buffer depending on the value of `require-final-newline'. The difference is that in Emacs it is possible to move point *visually* to a position after the final newline (point-max) and Emacs shows point on the next line. Thus, in Emacs one has the *visual* impression that the file contains one additional line. In some sense, in Emacs the newline character is rather a line-separator than a line terminator (at least for the visual impression). The trouble for evil are commands like "G". Vim moves point to the last real line, i.e. to a position not behind the final newline. But Emacs would move point to a position after that final newline, giving a slightly different impression. For evil this means that we have two general approaches: 1. Do it the Vim way. This is what we try currently. In this approach we do not allow point to be moved to (point-max). This is done by adjusting point to the previous line if it is moved to point-max (the function `evil-adjust-point' is responsible for this). As a result the behavior is closer to Vim's. The downside is that a) the behavior is different to Emacs-state and b) it causes trouble some modes like eshell, that somehow exploit that the final line does not need to end in a newline. Furthermore it is not trivial to do the right thing in all cases. In particular some Emacs non-evil commands may have problems with evil's point-adjustment. 2. Do it the Emacs way. In this approach we ignore completely the special handling of the final newline. We allow that point is placed on that "additional" line. This is of course a lot easier to implement. But it also breaks compatibility with vim in a not-so-uncommon situation (e.g., the G command behaves differently and the file always looks as if it contains one line more in evil than in vim). Both approaches have their advantages and disadvantages. But the real question is, what users want. Is vim compatibility significant in this situation or can you live with Emacs' behavior? Please feel free to comment and discuss. Best regards, Frank

4 4

Re:implementations-list Digest, Vol 48, Issue 8
by damien.thiriet77 28 Oct '12

28 Oct '12

I agree with previous posts. I think compatibility with other modes is more useful than a full vim behavior implementation. Btw, I didn’t face situations where having G at (max-point) would be a problem. Damien > ------------------------------ > > Message: 4 > Date: Sat, 27 Oct 2012 15:10:24 -0400 > From: Barry OReilly > Subject: Re: Empty line at EOB > To: "vi/Vim emulation in Emacs" > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > My preference is to avoid conflict with other Emacs modes like eshell and > auto-revert-tail-mode . That it simplifies the Evil implementation is > bonus. >

2 1

Key binding issues in compilation-mode
by Mark Tran 22 Oct '12

22 Oct '12

Hello, I've noticed that evil-mode works fine in compilation-mode except "h" is bound to describe-mode and "0" is bound to digit-argument. How should I bind these to the evil functions that are expected?

2 1

Point at EOB
by Barry OReilly 09 Oct '12

09 Oct '12

> > Regarding the last line of the buffer, this is indeed a "feature" of evil. > Vegard and I had a long discussion about this and finally agreed on the > current implementation which is as follows. Evil considers > newline-characters as line terminators, not as line separators, which is > the default UNIX (POSIX?) interpretation. This means it is not allowed to > move point on a newline or to the position after the last newline character > in the buffer. Evil does some fancy stuff to ensure that point is always > adjusted to the "allowed" region. > The reason for this was that the last, possibly "incomplete" line (when > the last character in the file is not a newline) causes some trouble with > vim-line line operations (e.g. the last line of some line-wise operation > would not include a final newline, but only in this case). Hi Frank, Could you link me to the discussion you and Vegard had about disallowing point at EOB? I searched "point EOB" in the archives, but without many results.

2 1

emacsrocks - multiple-cursors
by York Zhao 09 Oct '12

09 Oct '12

Hi, I just discovered this guy's multiple cursor, it's really really cool. He has a screen episode here: http://emacsrocks.com/e13.html. I have given it a shot in Evil, but very disappointed as Evil command like "cw" and "dw" are not compatible with this package. Also, since the visual selection in Evil is "inclusive", as opposed to "exclusive" in Emacs, it is not compatible with `mc/mark-next-like-this' in this package as well. Currently I have to switch to emacs state when I need to use `mc/mark-next-like-this'. I'm wondering if anyone here is interested in this package? I have to say, this is one of the coolest thing I have ever seen in Emacs so far, highly recommended that you guys give it a go and think about whether it is worth to make it work better in Evil. York

2 2

evil default search case
by Guido Van Hoecke 08 Oct '12

08 Oct '12

I know that M-c toggles search case when tapping / to search with evil. But I would like evil to start searching case-insensitive by default. I googled, searched the docs and glanced at evil-search.el but did not find a variable that I can setq to set insensitive as the initial search case. I must have overlooked something... Any suggestions, any one? Thanks in advance, Guido -- QOTD: All I want is a little more than I'll ever get. http://vanhoecke.org ... and go2 places!

2 2