- implementations-list - lists.ourproject.org

[implementations-list] Fwd: vimpulse - visual select with emacs -nw
by Alessandro Piras 30 Jul '09

30 Jul '09

---------- Forwarded message ---------- From: Alessandro Piras <laynor(a)gmail.com> Date: 2009/7/30 Subject: Re: vimpulse - visual select with emacs -nw To: Jason Spiro <jasonspiro3(a)gmail.com> it was already shipped as part of vimpulse, it just lacked the input-pending-p check :) 2009/7/30 Jason Spiro <jasonspiro3(a)gmail.com>: > On Wed, Jul 29, 2009 at 9:49 PM, Alessandro Piras <laynor(a)gmail.com> wrote: > ... >> (defadvice viper-intercept-ESC-key (around >> vimpulse-esc-exit-visual-mode activate) >> (when (and vimpulse-visual-mode >> (not (input-pending-p))) >> (vimpulse-visual-mode '-)) >> ad-do-it) > > I haven't tested the above code. But do you think it should be > shipped as part of Vimpulse? >

2 1

[implementations-list] vim-mode 0.0.1
by Frank Fischer 14 Jul '09

14 Jul '09

Hallo, in this mail I'd like to present the current status of my vim-mode implementation for emacs. mercurial repository: http://www.tu-chemnitz.de/~fifr/repos/vim-mode snapshot: http://www.tu-chemnitz.de/~fifr/downloads/vim-mode-r32.tgz The main-file is 'vim.el'. To test vim-mode, load this file and type 'M-x vim-mode' in some buffer. Don't forget to disable viper! The core of the implementation is quite usable and many aspects do already work. The following parts are ready: - keymap subsystem, - motion subsystem (including text-objects), - command and operator (commands with motion) subsystem, - easy definition of new commands, motions and mappings, - vim-like mapping of commands to other commands, - normal-mode, - insert-mode, - replace-mode, - visual-mode (character-wise, line-wise, block-wise), - undo/redo, - repeat. The following parts are NOT implemented yet: - marks, - registers, - ex-mode, - many motions (especially text-objects, word-motions, searching), - some commands, - scrolling/window commands, - good Emacs integration (global minor-mode?), - XEmacs compatibility (mainly keymap subsystem and visual-mode). The most urgent things to be implemented are Emacs integration and the missing but frequently used motions and commands. Both aspects should not be very difficult but, well, need some coding :) Feel free to send comments, bug-reports, patches ... Greetings, Frank. -- Frank Fischer Chemnitz University of Technology, Department of Mathematics eMail: frank.fischer(a)mathematik.tu-chemnitz.de Tel.: +49 (371) 531-36913

3 2

[implementations-list] How to use cscope with vimplus under emacs?
by zhihang wang 05 Jul '09

05 Jul '09

Thanks in advance! -- Best Regards zhihang wang www.ffavs.net

3 2

[implementations-list] New version is out
by Alessandro Piras 03 Jul '09

03 Jul '09

The behavior when issuing : while visual selecting text is closer to vim's, fixes, improved code in visual selection commands, and the other stuff you can see from the commit logs :) Out on emacswiki too. Alessandro

1 0

[implementations-list] Alessandro, I made a doc change SVN commit; also, thanks for being maintainer
by Jason Spiro 02 Jul '09

02 Jul '09

Hi Alessandro, I upgraded to the newest vimpulse. Thanks for maintaining it. I will try it soon. New SVN commit: "Fixed up docs a bit: spacing, pointed users more strongly to mailing list, added more URLs, copyediting. Alessandro, you wrote that you were looking for a new maintainer because you were lazy. I don't think you're a lazy maintainer at all. I removed and summarized it all and simply wrote that you were looking for a new maintainer. I hope you don't mind. :)" If you want to know about future commits, you should set Assembla to email you when they happen, because I probably won't. :) -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com

1 0

[implementations-list] Why accommodate non-Vi-like modal-editor emulation now? (was: Early implementation of...)
by Jason Spiro 02 Jul '09

02 Jul '09

cc added: John J. Foerch; he doesn't subscribe to implementations-list. Why not, John? :) On Thu, Jul 2, 2009 at 7:38 AM, Frank Fischer <frank.fischer(a)mathematik.tu-chemnitz.de> wrote: > [snip] > > The point is that emacs' own keymaps are not powerful enough or well > suited for modal editing (in my opinion). But it's relatively easy to > plug another keymap system on top of them. In fact, the design is > similar to emacs' own keymaps and minor/major modes. That's the reason > why other vim-emulation-packages just use emacs-keymaps and minor > modes. Would it be practical and useful to send patches to the FSF to improve Emacs's keymap system? Maybe the same improvements that would make the keymap system better for us would also help other Emacs mode developers. > [snip] > > I have to say that currently the core-keymap-system is a little specific > to vim (e.g. it knows of 'motions', 'commands' and 'argument'), but it > should not be too difficult to make it more generic (I have some ideas > in this direction I'll try in the next days). > > And, of course, there're some aspects that are not so easy to do the > right way for all thinkable model-editing-schemes, like undo/redo or > repeating. The current implementation is oriented at vim's. I have to > think about making it more generic. > > Some last words. I don't think we should try to build a system that can > be the base of every thinkable modal-editing-scheme. Focusing on vim > seems more important to me, because I think this is what most people > need and most people are used to. Frank, both you, and also John J. Foerch with his modal-mode[1], are already making accommodations for non-Vi-like modal editor emulation now. Why make any such accommodations now? That takes work, and maybe nobody will ever take advantage of that work. AFAICT, only one new non-Vi-like modal editor has gained even minor popularity nowadays anymore: DivaScheme[2], an add-on to DrScheme for editing Scheme code more easily. I suspect that modal editing has been losing market share over time, and that it will never regain the market share it used to have long ago. For more on why, see Leon Bambrick's comment at [3]. By the way, I no longer code in Lisp anymore nowadays. But if you do -- do you think it would be nice if some of DivaScheme's new editing commands were added to Vim and Vimpulse? ^ [1]. http://jjfoerch.com/modal-mode/ ^ [2]. Homepage: http://www.cs.brown.edu/research/plt/software/divascheme/ ; manual: http://www.cs.brown.edu/research/plt/software/divascheme/doc.txt ^ [3]. http://stackoverflow.com/questions/14410/why-are-there-so-few-modal-editors…

2 1

Re: [implementations-list] Early implementation of new VIM-like mode
by Marius Andersen 02 Jul '09

02 Jul '09

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." 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? 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. In short, if #1 is the goal, stay with Viper. 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.) 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) If we could bind `cx' to a command without overwriting the binding for `c', then this would be easy. Indeed, this is how Vim's `map' command works. But how to implement it in Emacs? Well, Frank Fischer is definitely onto something. Myself, I imagine some list of modal bindings -- wherein `c' maps to `change-command', `cx' to `transpose-object-command', and so on. Then, `change-command' calls the function `modal-read' to read input from the keyboard: (modal-read expectation) Here, `expectation' is what the calling command expects to get. `change-command' may call it like (modal-read motion), where `motion' somehow defines the keys that make up a text motion, like `3w'. Now, if the expectation is not met -- `x' is not a motion -- then `modal-read' will look up `cx' in the modal bindings list, and find `transpose-object-command'. Control will then be passed on to `transpose-object-command', which may read from the keyboard with (modal-read text-object). 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. 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. _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

3 3

[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