July 2009 - implementations-list - lists.ourproject.org

[implementations-list] Faithful vi/vim emulation vs. modality; etc. (was: Early implementation of new VIM-like mode)
by Jason Spiro 02 Jul '09

02 Jul '09

Marius, your email contained excellent new insights. Thank you for writing it. On Wed, Jul 1, 2009 at 9:18 PM, Marius Andersen <rezonatix3(a)yahoo.no> wrote: > Let's get philosophical for a moment. What is it we "really" want to accomplish by writing a new package? > > 1. FAITHFUL VIM EMULATION inside Emacs. Key for key, the editing > should be as identical to Vim's as possible. "Vim is fundamentally > correct, but Emacs has some nice extensions like AUCTeX and > Org-mode." > > 2. MODAL INTERFACE to Emacs' powers. Provide a way to define modal > key bindings, and map them to the word/sentence/paragraph > functions included with Emacs. "Emacs is Emacs, but modal editing > is a good idea." I personally would prefer #1, faithful Vim emulation, so that I can learn one set of keys in my muscle memory and use them in both Vim (the editor I have set the Vimperator addon for Firefox to use as my external editor) and Emacs (which I use for IRC and other uses). #2 would be an ok second-best choice, but I would be annoyed at having to learn a new set of keys, and I would be annoyed that the modal editing keys in Vim and Emacs would be slightly different. > There is a myriad of small differences between Vim and Emacs. For > example, Vim's regular expressions are slighty different from Emacs'. > Should we write a translator from one to the other, or do we simply bind > `/' to `isearch-forward' and encourage the user to adjust? Or, when > jumping back to previous locations in the buffer, Vim's `C-o' works > slighty different than Emacs' `C-u C-SPC'. Do we re-implement this > functionality, or should we stick with Emacs' function? I would prefer to have a translator, even though it'd be a lot more work to write. > The further we go down this road, the more obvious it becomes that a > package that views another editor as the standard can never be very > pretty. Viper is an emulator, and it takes tons and tons of replacement > code to overrule all the Emacs specifics. It's a self-reinforcing > strategy, too: once you've rewritten one function, you typically also > have to rewrite the larger system it was part of, and so on. But surely it can be prettier than how Viper is now. It sounds to me like viper contains a lot of kludges. > In short, if #1 is the goal, stay with Viper. Why? Because Viper contains so much built-in knowledge about how Vi works, just like autoconf contains so much built-in information about how various Unix variants work? There always is the option of rewriting from scratch. Though the opinion I've read (Joel Spolsky's) says don't do it, it takes too long and you will lose the built-in knowledge and bug fixes. > However, and this is where we get philosophical again, there's something > odd about the current state of things. Isn't the very point of using > Emacs the power to extend and program it to one's liking? And yet, as we > have seen, extending Viper turned out to be a "hackish" and unwieldy > process. Worse still, there are few general solutions: e.g., adding text > objects by redefining a function means the same function must be > redefined again when adding something else. (For the record, this hack > was my suggestion.) It sounds like Viper wasn't written perfectly. > As someone said, the only way to improve your work or life is by > understanding and examining why you do what you do. > > What we "really" want, I assert, is not all the specifics of Vim, but > the general concept of modal editing -- and the ability to combine that > concept with the rest of Emacs' powers in unlimited ways. (Of course, > since one of those powers is the ability to faithfully emulate vi, the > "purists" could get their golden standard simply by using this modal > interface as a front-end to Viper's emulation functions.) > > But there are far more interesting ways to employ a modal interface than > just reimplementing vi. For instance, think of text objects again. They > aren't just a nifty "Vim trick", but a very reuseable idea. Wouldn't it > be wicked cool to be able to do > > `cxw' -- transpose words (`M-t' in Emacs) > `cxb' -- transpose blocks (`C-M-t' in Emacs) > `cxs' -- transpose sentences (`transpose-sentences' in Emacs) > `cxp' -- transpose paragraphs (`transpose-paragraphs' in Emacs) Some people have already come up with Vim mappings you can map so you can swap words and paragraphs: http://vim.wikia.com/wiki/Swapping_characters,_words_and_lines#Normal-mode_… If it would be useful to have such functionality in Vimpulse, then why don't we get it added to Vim first, then make a clone of that feature for Vimpulse? > [snip] > > Anyway, the key is orthogonality. The key parser should be orthogonal to > commands, motions, text objects or whatever creative innovation may come > along. That way we can add our own, custom modal keys, without > redefinitions of fixed code, which are difficult to share. What if someone (not me) were to refactor Viper or one of the other vi emulators for emacs listed at http://texteditors.org/cgi-bin/wiki.pl?ViFamily bit-by-bit to make it easier to customize? They could start by rewriting the key parser part. Then they could do other things such as refactor out globals. I think a good goal would be to always keep Viper fully working after every stage of modification -- and every stage should be fifteen hours of work or less. > I've probably said more than enough for now. But please, give some > thought to what we really "want" from a total rewrite. With #1, Vim is > the limit. With #2, Emacs is. You mean that we would get more total functionality available per hour of modal mode developers' time? Yes, I agree.

1 0

[implementations-list] Visual region (was: vimpulse)
by Jason Spiro 01 Jul '09

01 Jul '09

On Wed, Jul 1, 2009 at 11:31 AM, Alessandro Piras <laynor(a)gmail.com> wrote: > Hi Fabian, > I was looking at the viper source code to see how to add the '<,'> > functionality to ex commands. It turns out it's quite boring to add it. > Viper does not recognize the '< and '> marks, and the characters recognized > as mark identifiers are hard coded in the ex command parser. I could easily > change the parser to let it recognize '< '>, but that would be yet another > viper function redefinition. I also think I'd have to change it in other > places, like in the ' command, and god knows where else (as there are also > other functions that check if the character is a valid mark, and it seems > viper uses some sort of registers (the same code used for "a "b etc) to > store markers. > To avoid another redefinition, I can do 2 things: > - put the line numbers that identify the current visual selection > automatically after ":" - this would work almost the same, but then you > would have to remember the line numbers if you want to issue a second > command on the visual selection after it is turned off > - use two marks, for example y and z, instead of < and >, and automatically > put 'y,'z after the : when : is issued in visual mode. Why not ask Michael Kifer for write access to the Viper source code repository, if there is one? [ Please CC me or the list when you write to him; then, if it turns out there isn't one, I or you could offer to make one for him on Assembla. :-) ] > By the way, I'm forwarding this mail to the mailing list, so to hear other > opinions too. I also invite you to subscribe to the mailing list, and direct > your feature/fix requests there :) Thanks Alessandro. Just remember that if you leave out your email address from the top of the file, and put the list email address in its place, then *all* emails will go to list :-)

2 2

[implementations-list] Early implementation of new VIM-like mode
by Frank Fischer 01 Jul '09

01 Jul '09

Hallo, the recent development of vimpulse encouraged me to think again about a new VIM-mode for Emacs. I'm one of those who think that implementing a new vim-mode from scratch might be easier and more powerful than extending viper. In this post I'd like to present you an early result of my attempts. Currently I call is just 'vim-mode', but that name is not important. The code is very modular (I hope) and built around an own keymap structure. This means vim-mode does not use the default Emacs-keymaps but handles all events within its own data structures. The handling of keymaps is an independent subsystem. Commands and motions can be defined independently and operators (commands with motions, I call them 'complex' commands) can be combined with arbitrary motions. In fact, a motion is just a function returning one or two positions in the buffer. Furthermore, vim-mode supports mapping of commands. This is a quiet powerful feature: many more complicated commands can be defined by simple mappings without the need of an own implementation. For example the command "x" is defined (vim:def-map "x" "dl") and "O" is defined (vim:def-map "O" (kbd "0 i RET <up> TAB")) look at the file 'vim-maps.el' for more examples. (OK, I'm not sure if those definitions are correct in all cases, but they seem to work OK for me). You can find the code at http://www.tu-chemnitz.de/~fifr/downloads/vim-mode.tgz and a mercurial repository at http://www.tu-chemnitz.de/~fifr/repos/vim-mode Just open the file 'vim.el' and evaluate it. Don't forget to read the comments in 'vim.el' I hope that this code can convince some of you of this approach in favor for extending viper (although vimpulse is really great - I use it every day, especially when developing vim-mode ;) - I think vim-mode is worth further development and as the potential to be even better than viper + vimpulse). Any comments, suggestions or patches are very welcome. Greetings, Frank

3 7

[implementations-list] Re: vimpulse
by Alessandro Piras 01 Jul '09

01 Jul '09

Hi Fabian, I was looking at the viper source code to see how to add the '<,'> functionality to ex commands. It turns out it's quite boring to add it. Viper does not recognize the '< and '> marks, and the characters recognized as mark identifiers are hard coded in the ex command parser. I could easily change the parser to let it recognize '< '>, but that would be yet another viper function redefinition. I also think I'd have to change it in other places, like in the ' command, and god knows where else (as there are also other functions that check if the character is a valid mark, and it seems viper uses some sort of registers (the same code used for "a "b etc) to store markers. To avoid another redefinition, I can do 2 things: - put the line numbers that identify the current visual selection automatically after ":" - this would work almost the same, but then you would have to remember the line numbers if you want to issue a second command on the visual selection after it is turned off - use two marks, for example y and z, instead of < and >, and automatically put 'y,'z after the : when : is issued in visual mode. By the way, I'm forwarding this mail to the mailing list, so to hear other opinions too. I also invite you to subscribe to the mailing list, and direct your feature/fix requests there :) Cheers, Alessandro 2009/6/30 Fabian Braennstroem <f.braennstroem(a)gmx.de> > Hi Alessandro, > > Alessandro Piras wrote: > >> thanks for the suggestions! :) >> ex support is still bad in vimpulse, the code is at least 2 years old, and >> we didn't work much on it, but that will be on the schedule :) >> > > Sounds nice! I am quite happy, that I saw the new start ... somehow, I was > afraid, that it will stay at the current status (which was quite good) . > > Best Regards! > Fabian > > Ciao, >> Alessandro >> >> 2009/6/29 Fabian Braennstroem <f.braennstroem(a)gmx.de <mailto: >> f.braennstroem(a)gmx.de>> >> >> >> Hi Alessandro, >> >> thanks a lot! That is really great! >> One or two more suggestions I got, is the adjustment of the search >> using: >> set ignorecase >> set smartcase >> >> in vim and running commands on the visual region like: >> >> :'<,'>s/test/TEST/ >> >> in vim :-) >> >> Best Regards! >> Fabian >> >> Alessandro Piras wrote: >> >> Hi Fabian, >> unluckily, the emacs commands <do-something>-region don't work >> at all with the new visual selection, at least for the moment. >> I'll try to explain why. The region is the area between the mark >> and the point. there are quite a lot of functions that can be >> used to identify those two ends, I really don't know why. I >> tried at first to override region-beginning and region-end, and >> some command worked, and some didn't. I tried to override point >> and mark, and some other function worked, and some didn't. >> suffice is to say, there's no clean method to make those >> commands work automatically. There basically are 3 options: >> a) Move the mark and the point at the exit of visual mode, so to >> highlight the region. I really don't like this method at all >> b) Provide an explicit command to exit visual selection mode and >> activate the region, so you can use the region-related commands >> c) instead of using region-related commands, like comment-region >> and uncomment-region, you provide your own commands that operate >> on the visual selection (implemented using the region commands, >> possibly). >> >> I'll give you a quick solution using the method 3, as it's the >> one that I would use in that case :) >> >> (define-key viper-vi-global-user-map (kbd "\\\]") >> 'my-vimpulse-comment-region) >> (define-key viper-vi-global-user-map (kbd "\\,") >> 'my-vimpulse-uncomment-region) >> >> (defun my-vimpulse-comment-region () >> (interactive) >> (comment-region (vimpulse-get-vs-start) (vimpulse-get-vs-end)) >> (vimpulse-visual-mode nil)) >> >> (defun my-vimpulse-uncomment-region () >> (interactive) >> (uncomment-region (vimpulse-get-vs-start) (vimpulse-get-vs-end)) >> (vimpulse-visual-mode nil)) >> >> You can go further than this. As most (maybe all?) emacs region >> related commands have the syntax (command region-begin >> region-end), it's possible to convert commands in a more >> abstract way: >> (defmacro vimpulse-region-command (function) >> `(lambda () >> (interactive) >> (,function (vimpulse-get-vs-start) (vimpulse-get-vs-end)) >> (vimpulse-visual-mode nil))) >> (define-key vimpulse-vi-global-user-map "\\\]" >> (vimpulse-region-command comment-region)) >> (define-key vimpulse-vi-global-user-map "\\," >> (vimpulse-region-command uncomment-region)) >> >> As this macro seems to be of general interest, I'll add it to >> vimpulse's helper functions :) >> Thanks for your feedback! >> Alessandro >> >> >> >> >> 2009/6/28 Fabian Braennstroem <f.braennstroem(a)gmx.de >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> >> >> >> Hi Alessandro, >> >> I just saw the new vimpulse release and that you took the >> maintaining :-) This is really great! I had to test the new >> release >> right away and like the new visual behavior. >> Right now, I got a short comment about the visual mode. I use >> quite >> a lot the command 'comment-region' to place comment characters >> in >> the first column of the whole visual region. This works with >> the new >> visual mode as well, but unfortunately it seems to behave in >> the old >> release style, which means that the last marked line does not >> get >> commented out!? >> >> (define-key viper-vi-global-user-map (kbd "\\\]") >> 'comment-region) >> (define-key viper-vi-global-user-map (kbd "\\,") >> 'uncomment-region) >> >> Do you have a hint, how to fix this? >> >> Thanks in advance! >> Fabian >> >> >> >> >> >

1 0