December 2009 - 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] 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 for Haskell, Ruby, Prolog, and maybe AucTEX (was: Re: viper-in-more-modes)
by Jason Spiro 28 Dec '09

28 Dec '09

> From: Alexey Romanov <alexey.v.romanov(a)gmail.com> > Date: Thu, Jun 12, 2008 at 10:24 AM > > I've been using both Vimpulse and viper-in-more-modes and extended > vimm to Haskell, Ruby, Prolog and LaTeX (from AucTEX) modes. > I'm sending you the modified file. Ruby, Haskell, and Prolog work, but > LaTeX doesn't. > > For some reason > (viper-modify-major-mode 'LaTeX-mode 'vi-state my-LaTeX-modified-vi-map) > doesn't seem to work, since my-LaTeX-modified-vi-map has the correct value. [snip] cc: implementations-list By the way, if viper-in-more-modes one will be ready to include in upstream Emacs, will you then be willing to sign and submit a copyright assignment form to the FSF? Also, are you willing to privately mail me either your home or work mailing address and/or phone number, for use at that time? This is completely optional, but it'd be good if you're willing to do it. If you do it, I recommend you send it as a separate email, not CCed to implementations-list. Kind regards, -Jason

1 0

[implementations-list] Welcome, Vegard, our newest committer (was: Helping to maintain Vimpulse)
by Jason Spiro 28 Dec '09

28 Dec '09

On Wed, Dec 23, 2009 at 11:02 AM, Alessandro Piras <laynor(a)gmail.com> wrote: > it's ok for me. > Alessandro Piras Good. Vegard, thank you very much for offering to help. Vegard, the rest of this email is for you, but anyone else is free to read it also if they want. I added you as a Vimpulse "team member" on Assembla. Vimpulse's Assembla space (project page) is www.assembla.com/spaces/vimpulse. You should now be able to do anything you want in Trac and SVN. If I am wrong about this, please let me know. You can help us as much or as little as you want. After you do any patch reviewing or other work which gets included in Vimpulse, please add yourself to the Acknowledgements file. Since you're new, I think it'd be better if you not commit your own patch until at least one person other than you has tested it and told you it works for them on their version of *macs. This can be a friend or classmate of yours, or someone on IRC (Vimpulse has no IRC channel yet, but Emacs has one), or someone on the mailing list. Dear list: Would one of you please volunteer to test Vegard's patch and check that it works? You can do whatever else you like. Something useful, I think, would be to deal or help deal with open issues in Trac. But note that the lower issue numbers -- I don't remember which but maybe up to about #5 -- are old patches that I never got around to dealing with, and ended up forwarding the entire emails to Trac. They're probably bitrotted by now. They're probably more work to deal with. It might help to ask the original patch senders to fix them up so you can review and maybe commit. Ask them to resend as a patch to current SVN. When it's time to release a new version, type "make" to run the cat command listed in the Makefile, then copy and paste the entire contents of vimpulse-big.el into EmacsWiki. We release often. Release whenever you want. The steps to do include editing the version and Changelog top version, and testing to make sure that Vimpulse will load and work on your version of Emacs and XEmacs. Create an svn tag too. I think it would be best if every EmacsWiki version corresponded to some SVN numbered revision. After you release, bump the version in svn by adding "+svn" to its number. When you merge in any patch, you should edit Changelog and probably Acknowledgements. Always make a comment in SVN when you commit. Make svn commits often. If you want, just copy and paste your Changelog comment into the svn commit comments field. I use M-q in Emacs to re-wrap comments in the area at the top of the file. For changes adding or significantly removing a copyright-significant amount of code, you should also add a copyright line with the author's name to Copyright, and ask the author to agree that they will sign a FSF copyright assignment form if and when Vimpulse gets into Emacs. I don't remember anymore what "copyright-significant" means. Maybe the huge copyright-related mailing list thread from earlier this year contains an answer? I don't remember. Vimpulse has horrible documentation. Our documentation policy so far has unfortunately often been lax. I'm about to write a mail to the list about this problem. You may have lots of questions. Ask us whatever you want, and ask questions as often as you want. There's no such thing as a stupid question. :)

2 5

[implementations-list] Fwd: viper-in-more-modes
by Jason Spiro 26 Dec '09

26 Dec '09

---------- Forwarded message ---------- From: Alexey Romanov <alexey.v.romanov(a)gmail.com> Date: Thu, Jun 12, 2008 at 10:24 AM Subject: viper-in-more-modes To: jasonspiro3(a)gmail.com Hello! I've been using both Vimpulse and viper-in-more-modes and extended vimm to Haskell, Ruby, Prolog and LaTeX (from AucTEX) modes. I'm sending you the modified file. Ruby, Haskell, and Prolog work, but LaTeX doesn't. For some reason (viper-modify-major-mode 'LaTeX-mode 'vi-state my-LaTeX-modified-vi-map) doesn't seem to work, since my-LaTeX-modified-vi-map has the correct value. About Vimpulse: if I have selected a region while in Normal mode, can I switch to Visual while keeping the selection? 'v' loses it. -- Yours, Alexey Romanov

2 2

[implementations-list] Helping to maintain Vimpulse (was: Transferring maintainership of Vimpulse)
by Jason Spiro 23 Dec '09

23 Dec '09

On Mon, Jan 26, 2009 at 12:21 AM, Stephen Bach <sjbach(a)sjbach.com> wrote: > > On Sun, Jan 25, 2009 at 01:52:03PM -0500, Jason Spiro wrote: >> >> Are you interested in taking over maintainership of Vimpulse? >> > I appreciate being asked, but I'm probably not the best choice to be the > formal maintainer. I'd certainly like to see further improvements to > vimpulse and a viper-in-more-modes, though. I use them every day. :-) Stephen, are you willing not to be a formal maintainer, but simply to download, test, and commit patches from Trac when Alessandro is busy? This would require that Alessandro bless you to be allowed to do so, but I am sure that Alessandro would.

3 5

[implementations-list] vimpulse-modal.el --- modal key bindings
by Vegard Øye 08 Dec '09

08 Dec '09

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. The attached code 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 as shown at the end of the file. They act on Lisp S-expressions. I am not suggesting they be made part of vimpulse.el, just making a point about extensibility. Try it! And please comment. :) Vegard Øye _________________________________________________________________ Windows Live™ Mail. Flere kontoer på ett sted. http://download.live.com/wlmail

2 4

[implementations-list] [PATCH] Small fixes
by Vegard Øye 01 Dec '09

01 Dec '09

I have made a few fixes, attached to this e-mail as a patch (patch.txt). They are: * AUTOMATIC LOADING OF CL.EL: if cl.el isn't loaded already (Common Lisp extensions for Emacs), one gets error messages bemoaning undefined functions like `destructuring-bind'. Added (require 'cl) to fix this. * FIXED `TRAILING-NEWLINES' PARAMETER: corrected a small typo in the function `vimpulse-get-bounds-with-whitespace'. See http://www.emacswiki.org/emacs/vimpulse for details. I also took the liberty to remove any trailing whitespace (M-x delete-trailing-whitespace), which made the patch a bit larger than it otherwise would have been. The patch was made with the GnuWin32 version of diff, running on Windows XP, with the command diff vimpulse-old.el vimpulse.el> patch.txt where vimpulse-old.el is version 0.3.0 of Vimpulse, downloaded from http://www.emacswiki.org/emacs/vimpulse.el. Tested on GNU Emacs 23.1. Vegard Øye _________________________________________________________________ Nye Windows 7: PCen som passer for deg. Finn ut mer. http://windows.microsoft.com/shop

2 4

[implementations-list] Whether Vimpulse may intentionally work differently than Vim (was: [PATCH] Vimpulse: vi* and va* ...)
by Jason Spiro 01 Dec '09

01 Dec '09

2009/11/29 José A. Romero L. <escherdragon(a)gmail.com> wrote: > [...] > [...] I've divided the original patch into > 3 smaller ones: one for removing the extra definitions of the function > vimpulse-visual-replace-region, and two for the vi*/va* stuff, the first > one with standard gvim behavior, and the second one with a function of > my own invention that IMO makes that behavior more useful. > [...] I always tried to make sure Vimpulse worked as much like Vim as possible. If somebody thought Vim behavior could be improved, then I wanted them to email the Vim mailing list and get the change made in Vim. Once the change was made in Vim, then the same change could be made in Vimpulse. This would provide two advantages. * People who use both Vim and Vimpulse could use the same keys in both. * It would be possible to one day copy and paste from the Vim documentation into the Vimpulse documentation, maybe by an automated Vimpulse .txt-format-help-file-generation script. But now that Alessandro is maintainer, it is his choice whether to continue to enforce this policy or not.

2 1