January 2010 - implementations-list

[implementations-list] How important is a Vimpulse user manual? How to make one? Copy from Vim docs?
by Jason Spiro 10 Feb '10

10 Feb '10

Vimpulse needs better documentation -- a better user manual, saying how to use all of its features. Look at the Viper info manual and see how great it is. Look at our documentation -- it's very incomplete. What can we do? Maybe we can copy text straight out of the Vim documentation for every single keystroke and feature that Viper or Vimpulse supports, then ship a series of .txt files containing our newly-cobbled-together documentation? We'd have to give proper copyright and license acknowledgment of course. And maybe we could use or write some software to do that copying, so that when Bram adds to the Vim documentation, we just type "make" and our documentation instantly will improve? Or must we ship Texinfo format instead? Should we get people who write patches to also include documentation in the patch, and say that if they don't, we won't accept their patches? What's doable? What's practical? What's the right thing to do? Then again, is it really so important for Vimpulse to have a user manual that tells users how to use its features? This is only important for people who went straight from using Emacs to using Vimpulse, and who have never used Vim. How common is that? How can we find out how common it is? Can we include a survey in the comments at the top of the next release of Vimpulse and ask people to fill it in, join the mailing list, and email it to the list? (This would also gain us lots of new list subscribers.)

3 7

[implementations-list] Dear readers: We need ten minutes of your time to test Vegard's vimpulse-modal so we can decide if to include it in Vimpulse or not
by Jason Spiro 29 Jan '10

29 Jan '10

Dear implementations-list readers, We need a volunteer to test vimpulse-modal.el, a file which Vegard wants included in Vimpulse. Vegard can't volunteer, since he himself wrote vimpulse-modal. But anyone else who uses Vimpulse can volunteer, even if they don't know how to code in elisp, and even if they're not an expert at using Vimpulse. Just tell us: * if vimpulse-modal worked for you, * whether you think that it makes Vimpulse better or not, * and any comments, if you have any. Alessandro is too busy to volunteer, and I'm not really interested. I haven't been using Emacs much lately. You can download vimpulse-modal from http://my-trac.assembla.com/vimpulse/ticket/14 -- look in the "Attachments" section. Once you test it, just reply to this email to send your test results to the mailing list. One person's opinion is enough for us to decide if vimpulse-modal merits being included in Vimpulse or not. But even if someone else has posted their opinion, you can post your opinion too if you want. The rest of this email is Vegard's description of vimpulse-modal, copied from the Trac ticket for it. Thanks in advance, -Jason The `:map`, `:imap` and `:vmap` commands of Vim let one make two key mappings starting with the same sequence of characters without one overwriting the other. For example: :imap aa foo :imap aaa bar When Vim has read "`aa`" in Insert mode, it will wait for another character to decide whether to insert "`foo`" or "`bar`". If the user types "`a`", "`bar`" is inserted; if another letter, "`foo`" plus that letter. Compare with the analogous use of Emacs' `global-set-key` function: (global-set-key "aa" 'foo) (global-set-key "aaa" 'bar) Here, the first binding is simply overwritten by the more specific second. The end result is that "`aaa`" is bound to `bar`, while any other sequence starting with "`aa`" is not bound to anything. `vimpulse-modal.el`, attached, provides a set of Vim-like or "modal" functions for making new keybindings "on top of" previous bindings. They are `vimpulse-map`, `vimpulse-imap` and `vimpulse-vmap`, which mimic Vim's commands, and `vimpulse-define-key`, a generic function for specifying the keymap. To load it, issue (require 'vimpulse-modal) Then, for example, the key sequences "`cae`" and "`dae`" may be bound in vi (command) mode using `vimpulse-map`: (vimpulse-map "cae" 'vimpulse-change-a-sexp) (vimpulse-map "dae" 'vimpulse-delete-a-sexp) This will execute `vimpulse-change-a-sexp` when typing "`cae`" in vi mode, while retaining keys like "`cw`" for "change word" or "`cas`" for "change a sentence". Just for demonstration purposes, `vimpulse-change-a-sexp` and `vimpulse-delete-a-sexp` are indeed real text object commands, defined and bound at the end of the file as shown. They act on Lisp S-expressions. I am not suggesting they be made part of Vimpulse, just making a point about extensibility.

3 4

[implementations-list] Ann: vim-mode 0.2
by Frank Fischer 23 Jan '10

23 Jan '10

Hi, in this mail I'd like to announce the release of vim-mode 0.2, another implementation of vim-like keybindings for emacs. Note that vim-mode is still in early development, so it's full of bugs and some features missing. Look at the EmacsWiki page: http://www.emacswiki.org/emacs/VimMode The mercurial repository and downloads can be found at http://bitbucket.org/lyro/vim-mode This version includes the following features: - normal-mode, operator-pending mode - visual-mode (including linewise/block) - easy definition of new commands, motions and mappings - progra - window-commands - ex-mode The following stuff has to be improved: - marks - registers - documentation - implementation of most text-objects (the framework is ready, only the functions describing an object are missing) - interactive :substitute - XEmacs integration Feel free to send comments, bug-reports, patches ... Greetings, Frank

1 0

[implementations-list] viper-in-more-modes still needs a maintainer: does anyone volunteer?
by Jason Spiro 04 Jan '10

04 Jan '10

Hi all, viper-in-more-modes provides vi-like keymaps for emacs-lisp-mode, lisp-interaction-mode, slime-repl-mode, and lisp-mode. But viper-in-more-modes has some problems. Here's some stuff that should be done, copied from the TODO list in the file: * We shouldn't use the "vimper" function-name prefix anywhere in this file. The word "vimper" is a leftover from back when viper-in-more-modes was part of Vimpulse, and Vimpulse was unreleased and didn't have a good name yet. But viper-in-more-modes is no longer part of Vimpulse. It doesn't require Vimpulse to load. It does provide access to some Vimpulse features like visual mode, but viper-in-more-modes does something different than Vimpulse and so isn't shipped with Vimpulse. So we should pick a new prefix. * Rename viper-in-more-modes to something much shorter. This will not only give viper-in-more-modes a shorter name, but will also instantly provide us with a better prefix. * Clean up the code in general: for example, the error messages shouldn't include exclamation marks. And the grammar and capitalization in the comments should be improved. Also, the boxed comments probably don't have to be in boxes. * Submit it to M-x report-emacs-bug and ask them to please include viper-in-more-modes as part of Viper. viper-in-more-modes has no maintainer. Would someone please take over maintainership? Vegard, you could volunteer. Dear everyone else, you could volunteer too. :) -- 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

4 11

[implementations-list] viper-in-more-modes Assembla space (was: viper-in-more-modes still ...)
by Jason Spiro 03 Jan '10

03 Jan '10

On Sat, Jan 2, 2010 at 1:38 PM, Vegard Øye <vegard_oye(a)hotmail.com> wrote: > >> From: jasonspiro3(a)gmail.com >> Date: Fri, 1 Jan 2010 15:35:12 -0500 >> >> By the way, if you do make an Assembla project for >> viper-in-more-modes, it would be appreciated if you would give me >> and Alessandro commit rights :) > > viper-in-more-modes.el now has its own Assembla space at the address > below. Did you receive an invitation? Got it and accepted it. Thanks for giving me commit rights.

1 0

[implementations-list] What ships with core GNU Emacs (was: viper-in-more-modes still ...)
by Jason Spiro 03 Jan '10

03 Jan '10

2010/1/2 José A. Romero L. <escherdragon(a)gmail.com> wrote: > IMHO Stephen has made an excellent point here. And I can understand > the position of the Emacs team too: they have a "core" system, and > they're trying to keep it as thin and simple as they can. Are they? If so, why? And anyway, don't they ship more and more Emacs add-ons with each new version of Emacs? > Of course > there's a lot of history, politics and... (folklore, maybe?) in the > list of packages distributed with Emacs -- were not for that, I bet > they'd already dumped off half of it. Don't you think there'd be more > sense in promoting some kind of comprehensive, widely available > repository of software for Emacs, like the Emacs Wiki? It would be nice if they promoted repositories of add-on software more heavily, for example, on the Help menu. But I still think it would be nice if viper-in-more-modes got upstream, and if vimpulse eventually got upstream too. I agree that this will take time. That way all viper users will have viper-in-more-modes and Vimpulse automatically installed, and I hope, automatically enabled.

1 0

[implementations-list] viper-in-more-modes and Vimpulse (was: viper-in-more-modes still ...)
by Jason Spiro 03 Jan '10

03 Jan '10

On Fri, Jan 1, 2010 at 4:56 PM, Stephen Bach <sjbach(a)sjbach.com> wrote: > > Is there a good reason to keep viper-in-more-modes individual from > vimpulse? It seems unlikely to me that anyone who uses the former would > not also use the latter. I see two reasons: 1. Some people might want viper-in-more-modes but not vimpulse. Vimpulse isn't stable yet. I don't use viper-in-more-modes, but it's a simpler piece of software and is more likely to be stable. 2. Also, the two projects have two different maintainers. But if Alessandro continues to be too busy to work on vimpulse, then I think Vegard should ask Alessandro to make Vegard co-maintainer or the new sole maintainer. > Also, the extensions in vimpulse may be things > we would want to use in these other modes. I don't think we need to > integrate the two packages, but I don't think it's worth enforcing a > separation. viper-in-more-modes already adds keys to certain modes to enable Vimpulse visual mode. So, in effect, viper-in-more-modes provides Vimpulse support already. > P.S. Jason: my first attempt to send this message was rejected because > the mailing list service didn't recognize the content type of my PGP > signature. If it's configurable, you may want to relax this constraint. I set Mailman Content Filtering filter_action to "preserve". I'd appreciate it if you let me and the list know if this fixed your problem or not.

1 0

[implementations-list] Messing around with viper and its extensions
by Konrad Scorciapino 02 Jan '10

02 Jan '10

Hey guys, I'd been using vim for 5 or more years, until about a month ago, when I switched to Emacs to have access to better Lisp utilities. From day 1, I've been wanting to improve Viper, and my conversation some days ago with Jason at #emacs inspired me, so I played a bit with it and its extensions, and here I am to report the results. First I played a bit with vimpulse.el and viper-in-more-modes.el, fixing the extensions to the Emacs Mode. The visual mode evaluation wasn't working at all. First, the variable which was used to check if the user was on the visual mode was prefixed with viper-, but since I could only find it in vimpulse.el, I changed the prefix. Secondly, for some reason, the function '(vimpulse-set-mark)' was commented in vimpulse.el, so I had to uncomment it. I also changed a bit some other functions and got the Visual Line mode working more consistently. Besides that, I started to write viper bindings to ibuffer-mode. My idea is to write bindings for all modes a user might possibly find, thus providing a vi-like experience everywhere. I've attached the patches relative to the files I've changes. This is my first experience with elisp programming, so criticism of any kind is welcome. Thanks, and happy new year :-)

2 2

[implementations-list] fork viper?
by John J. Foerch 01 Jan '10

01 Jan '10

Hi, I don't use Viper myself so take this with a grain of salt.. Have you considered forking viper, instead of having all these modes that run on top of it? Having many modes that must work in concert with each other introduces a level of complexity that was a large part of why I decided not to use Viper anymore. -- John Foerch

2 1

[implementations-list] Fwd: Messing around with viper and its extensions
by Konrad Scorciapino 01 Jan '10

01 Jan '10

For some reason my message wasn't delivered, so I forward it here. A happy 2010 for everyone! ---------- Forwarded message ---------- From: Konrad Scorciapino <konrad(a)scorciapino.com> Date: Thu, Dec 31, 2009 at 6:23 PM Subject: Messing around with viper and its extensions To: implementations-list <implementations-list(a)lists.ourproject.com> Hey guys, I'd been using vim for 5 or more years, until about a month ago, when I switched to Emacs to have access to better Lisp utilities. From day 1, I've been wanting to improve Viper, and my conversation some days ago with Jason at #emacs inspired me, so I played a bit with it and its extensions, and here I am to report the results. First I played a bit with vimpulse.el and viper-in-more-modes.el, fixing the extensions to the Emacs Mode. The visual mode evaluation wasn't working at all. First, the variable which was used to check if the user was on the visual mode was prefixed with viper-, but since I could only find it in vimpulse.el, I changed the prefix. Secondly, for some reason, the function '(vimpulse-set-mark)' was commented in vimpulse.el, so I had to uncomment it. I also changed a bit some other functions and got the Visual Line mode working more consistently. Besides that, I started to write viper bindings to ibuffer-mode. My idea is to write bindings for all modes a user might possibly find, thus providing a vi-like experience everywhere. I've attached the patches relative to the files I've changes. This is my first experience with elisp programming, so criticism of any kind is welcome. Thanks, and happy new year :-) -- Et Forum delendum est!

1 0