Thanks!

Mon Jul 19 19:41:44 CEST 2010

Marc Weber <marco-oweber at gmx.de> writes:
> Yes. But I get
>   exit-minibuffer: No catch for tag: exit, nil
>
> when asking it to find the file Main.scala
>
> Maybe its time to learn how to debug Emacs then..

Maybe. Evaluating this form

(info "(elisp)Debugging")

should take you to the relevant parts of the manual.
I have no idea what could cause that error. If it happens with emacs -Q,
it might be a candidate for M-x report-emacs-bug.

> How are you supposed to scroll in vimpulse

I've always used Space and Backspace for that, even in Vim.

> ctrl-u is still mapped to emacs. m-v does no longer work.
> Is this due to my (setq viper-expert-level '4) ?
> Yes it is. So I have to rebind something.
>
> in command line I'm missing ctrl-u eg when opening files
> c-a c-k is bearable though.

Well, C-u is one of the ubiquitous bindings (it's called "universal"
for a reason), so I'd just suggest to get used to it. You can rebind it
as anything of course, but I'm not sure it's a good idea. 

You can also customise `vimpulse-want-C-u-like-Vim'.

> Thanks for your help - and to all who worked on this .el files!
>
> You should try to integrate vimpulse into mainline Emacs if at all possible.

Why? Care to provide some arguments? (To save you part of the potential
work, I can reply to some of the obvious ones in advance:

1. It would make Vimpulse reach wider user base.
R: This is not a very compelling argument to me -- you'll most probably
want to use some (or even a lot of) third party packages anyway, and
library management in Emacs is IMO much more painless than in Vim for
instance.

2. It would be maintained by smart guys (in addition to the current
smart guy).
R: Well, not really. While the inclusion process _might_ involve a
useful review by the Emacs devs, resulting in catching some problems
with current Vimpulse code, considering the near-to-zero maintenance of
Viper, it would more probably just rot in there (unless Vegard continues
to maintain it of course, but that makes this whole point a non-issue).

Moreover, the counterarguments are much stronger for me:
1. Including anything into GNU Emacs makes contribution impossible
for anyone that has issues with the FSF copyright assignment
requirement/procedure.

2. Actually it makes contribution a lot harder in general, as all the
patches go through review by Emacs devs (who don't necessarily care/have
any idea about the problem they solve), and any "copyright-significant"
changes need an assignment, which even in best cases appears to usually
take time counted in weeks.

All in all, I don't see any reason whatsoever to want to have one's
package included into Emacs, and the "inclusionism" a lot of people seem
to indulge in seems just ridiculous to me -- there's no point in having
everything in Emacs core. In fact, a lot of current core libraries,
including Viper, would make much more sense as external packages.

Fixing Emacs bugs/refactoring/contributing relevant improvements to
Emacs core code upstream is an entirely different matter, of course.)

Štěpán