- implementations-list - lists.ourproject.org

[implementations-list] What should the Vimpulse quick-start guide talk about?
by Jason Spiro 17 Feb '10

17 Feb '10

Vegard and I were talking at http://my-trac.assembla.com/vimpulse/ticket/23 but we need more input so I am moving the conversation to this list. == Ticket 23 input by Jason == In http://lists.ourproject.org/pipermail/implementations-list/2009-December/00… Vegard said what documentation it would be useful for Vimpulse to have. One thing he said would be good is a quick-start guide, including things like "(require 'vimpulse) and some Emacs pointers". Let's make such a guide. [But] does the Installation wiki page[1] count as a good-enough quick-start guide? If so, let's close this ticket. == Input by Vegard == I feel it's a bit draft-like still, but it's definitely a good start. Besides installation, the quick guide should deal with immediate sources of confusion: things which may be unfamiliar to the newbie, especially if he's used to Vim. A list of pointers should clear this up ("if you want to do this, go here, if that, go there"). This, of course, begs the question: what is confusing to a newbie? Links to Emacs introductions may also be valuable, but ideally, I'd like Vimpulse to be useable without too much Emacs knowledge. == Dear mailing list == Dear mailing list, what do you think? I would prefer if, in this case, you would reply here, and would not add any more comments to the Trac ticket.

1 0

[implementations-list] GNU Emacs policy that says packages must not use cl.el at runtime (was: viper-in-more-modes still needs ...)
by Jason Spiro 13 Feb '10

13 Feb '10

On Sun, Jan 3, 2010 at 9:58 PM, Stephen Bach <sjbach(a)sjbach.com> wrote: > On Sat, Jan 02, 2010 at 10:40:10PM -0500, Jason Spiro wrote: >> > 3. GNU Emacs enforces the backward policy that packages must not use >> > cl.el Common Lisp extensions at runtime. This kind of restriction >> > is another enemy to development momentum; if it's expedient to >> > Vegard or another developer to leverage a standard library, they >> > should be empowered to do so. >> >> But John J. Foerch said in his email of Wed, Oct 3, 2007 at 11:00 PM >> at http://my-trac.assembla.com/vimpulse/ticket/2 that there are cl.el >> macros that override core Emacs functions. Do you still stand by your >> assertion? > > Yes. cl.el's version of push subsumes GNU Emacs' standard push - it's > not dangerous. Almost anyone who uses Emacs extensively will load cl.el > as part of their configuration. XEmacs loads it by default. What reason does the GNU Emacs team give for this policy? If it turns out to be a flimsy reason, then perhaps you or Vegard could get the policy changed if you wanted to. :)

4 12

[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] Vegard, I made you default assignee for all new Trac tickets
by Jason Spiro 10 Feb '10

10 Feb '10

Hi Vegard, "The reward for a job well done is another job." :) You've done wonderful work by catching up on the backlog of patches sent in since maybe mid-2007. I bet this encourages other people to send more patches. So I've made you default assignee for all new Trac tickets. If you disagree, just let me know, or go into the Trac admin UI yourself and change the default assignee back to Alessandro. Cheers, -Jason -- 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

2 2

[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