February 2010 - implementations-list

[implementations-list] h/j/k/l keys in Info mode (was: How important is a Vimpulse user manual? ...)
by Jason Spiro 10 Apr '10

10 Apr '10

On Wed, Feb 10, 2010 at 3:18 PM, Vegard Øye <vegard_oye(a)hotmail.com> wrote: >> From: jasonspiro3(a)gmail.com >> Date: Wed, 10 Feb 2010 03:52:13 -0500 [snip] >> I think people can just use the arrow keys and Enter in Info mode. :) > > Yes. But to the seasoned Vim user with his hands at the home row, the > annoyance will be there. (If you're going to use Vim keys in Emacs, > you're probably somewhat seasoned. :) Fair. > Anyway, I added some utility code to vimpulse-misc-keybindings.el in > changeset [58] to address this in time. The idea is that there are two > forms of vi navigation: the "core" commands, like h/j/k/l, and the > rest. The core commands should, in general, be available in every > mode, even if this means overwriting the mode's own bindings for these > keys. On the other hand, the rest of the vi navigation commands -- w, > e, b, f, etc. -- are optional: they are only added if their keys don't > already do something else. Thus w may move forward by words or it may > not, while h always moves one character to the left, no matter what. [snip] Interesting. I see, looking at the changeset[*], that this doesn't yet affect Info mode unless you uncomment the several lines of commented-out code starting with eval-after-load 'info in vimpulse-misc-keybindings.el. If you uncomment those lines, then in Info mode, what can you press to go back to the last Info node you read before? Surely "l", the "Last node" key, won't work. Cheers, -Jason ^ [*]. http://my-trac.assembla.com/vimpulse/changeset/58

3 11

[implementations-list] About the paren matching
by Alessandro Piras 20 Feb '10

20 Feb '10

I installed emacs again today, and downloaded the new vimpulse. This is actually an old problem that i never addressed, and that's still present. Paren matching should revert to normal emacs behavior when editing a buffer that's not using viper nor vimpulse. For example when using slime's repl.

2 1

[implementations-list] [ANN] vim-mode 0.3
by Frank Fischer 19 Feb '10

19 Feb '10

This is an announcement of vim-mode 0.3. vim-mode is another implementation of vi/vim-like key-bindings for Emacs. The mercurial-repository is available at http://bitbucket.org/lyro/vim-mode Version 0.3 includes the following improvements: - XEmacs support - marks - registers for macro-recording and yank/paste - ex-mode - buffer-local key-bindings for all modes via `vim:local-nmap', `vim:local-omap', ... - mouse-selection now enables visual-mode * single-click -> character visual-mode * double-click -> word selection visual-mode * triple-click -> linewise visual-mode * quadruple-click -> block visual-mode - visual-mode selection is passed to Emacs-commands which take a region-argument Since most required features are now present, the plans for the next versions include mainly: - bug-fixes - implementation of missing commands/motion (text-objects) - improved documentation - more interactive search/substitude Feel free to sent any comments, ideas, bug-reports... Greetings, Frank Fischer

1 0

[implementations-list] Ease of use of Emacs and Vimpulse (was: What should the Vimpulse quick-start guide talk about?)
by Jason Spiro 17 Feb '10

17 Feb '10

Vegard wrote, and Jason quoted: > [...] ideally, I'd > like Vimpulse to be useable without too much Emacs knowledge. This is a good ideal. Would anyone here volunteer to do some informal usability testing? Anyone can do it. And it would help us achieve the ideal that Vegard mentioned above. == Usability testing idea == * Find some Vim users at your local workplace, school, hacklab, or LUG, or other place. * Tell them about Emacs, Vimpulse, and why they might like them. * Point them to the Emacs and Vimpulse homepages. * Tell them you'd like them to install and get started with Emacs and Vimpulse with no help from you, so that you can watch and see what we can do to make Vimpulse easier to install and get started with. * Sit back and *not talk at all* while they figure out Emacs and Vimpulse. But it seems to me that the Emacs learning curve is very steep, so it would take a lot of time for Emacs newbies to succeed even in just installing Vimpulse into their Emacs add-ons directory. Correct? == More questions which are not strictly related to usability testing == How was your experience of learning Emacs? How hard was it for you? What helped? People? Certain books? Certain videos? Certain websites? Also, please tell us on behalf of the other people you know who've used Emacs: How was their experience of learning Emacs?

1 0

[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