Marc Weber <[email protected]> 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 _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
