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

[implementations-list] C-v y p pastes "^BVimpulseVisualBlockMode^C" when experimental is nil (was: vimpulse - visual ...)
by Jason Spiro 30 Jul '09

30 Jul '09

On Thu, Jul 30, 2009 at 5:24 PM, Alessandro Piras <laynor(a)gmail.com> wrote: > yeah, that's an ugly hack I made to make p work with block selection. > before you had to press Ctrl-P to paste. Enabling the experimental > code should fix it. If Vimpulse pastes "^BVimpulseVisualBlockMode^C", isn't that a bug? :) P.S. Alessandro, it is best to get in the habit of always clicking "Reply to All" instead of replying to sender then forwarding to list. :) And John, it is best to join the list for long conversations like this: it makes it easier for us to reply, and then plus you can help out if you like by giving tech support to others in the future.

2 1

[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: John MacFarlane <jgm(a)berkeley.edu> yeah, that's an ugly hack I made to make p work with block selection. before you had to press Ctrl-P to paste. Enabling the experimental code should fix it. 2009/7/30 John MacFarlane <jgm(a)berkeley.edu>: > +++ Alessandro Piras [Jul 30 09 04:49 ]: >> better: >> (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 tried putting this in my .emacs, and it did allow the arrow > keys to be used with visual mode in console emacs. > > I noticed another glitch that doesn't seem connected with the > above code (since it happens even without it). If I do a > visual block select (Ctrl-v then movement keys), then y, > then P to paste the buffer, I get the string > > ^BVimpulseVisualBlockMode^C > > rather than the text I selected. > > John >

1 0

[implementations-list] vimpulse - visual select with emacs -nw
by John MacFarlane 30 Jul '09

30 Jul '09

I just discovered vimpulse and was very happy to find it! Thank you. One oddity: Visual selecting (with v or Ctrl-v) doesn't seem to work when I run emacs in a terminal with 'emacs -nw'. For example, in normal mode I can hit vllld and nothing will be deleted. Visual selecting works fine when I run emacs in its own window. Why would this be? Is there any way to get vimpulse working fully in terminal mode emacs? I don't subscribe to this list, so please cc me in replies. John

3 16

[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