Hi list, I've been using Vim for years. However I'm at a point I think Vim will no longer serve (all) my needs - that's because the core is lacking functionality - which can be implemented - but would take a lot of time. I want to thank you - I was very pleased seeing that these features just work: - ctrl-vI..<esc> (instert into multiple lines) - text objects - all visual modes - % in combination with visual mode. So Emacs comes pretty close to what I'm used to (which I use most) There is one last thing which I'm missing: Opening files by glob patterns: noremap :e :e<space>**/* In #emacs I was told use ido-find-file .. However patterns like this **/*Main.scala doen't work for me. creating a buffer with output of find then using gf (which works!) is not a perfect solution. Having gF implemented properly would be fine, because I use it often when reading Exception logs - I can still fallback to Vim. Do you have some more hacks in you ~/.emacs making using Emacs easier for Vim addicts? Eg is there a :qa! like command (without the nasty: You have unsaved open files..) Marc Weber
Marc Weber <[email protected]> writes:
Hi list,
I've been using Vim for years. However I'm at a point I think Vim will no longer serve (all) my needs - that's because the core is lacking functionality - which can be implemented - but would take a lot of time.
Welcome to the club. ;-)
I want to thank you - I was very pleased seeing that these features just work: - ctrl-vI..<esc> (instert into multiple lines) - text objects - all visual modes - % in combination with visual mode.
So Emacs comes pretty close to what I'm used to (which I use most)
There is one last thing which I'm missing: Opening files by glob patterns:
noremap :e :e<space>**/*
Be sure to also have a look at Frank Fischer's Vim mode: http://www.emacswiki.org/emacs/VimMode Before some time it seemed lacking to me, but there were more commits since then and IIRC it implements more :commands (personally I think implementing Vim :commands is not really a good idea: - you're using Emacs anyway, so you'll *have* to use M-x anyway and this only introduces more inconsistency - using and defining usual Emacs commands makes it easier to interact with other Emacs libraries).
In #emacs I was told use ido-find-file .. However patterns like this **/*Main.scala doen't work for me.
Yeah, I think that the double asterisk doesn't work (don't know if some Emacs package implements it); but normal shell patterns do work, even with plain `find-file'. Ido provides an `ido-wide-find-file-or-pop-dir' command, bound to M-f, which uses `find' to search for a file under current directory. I'm guessing that could help?
creating a buffer with output of find then using gf (which works!) is not a perfect solution.
Having gF implemented properly would be fine, because I use it often when reading Exception logs - I can still fallback to Vim.
Yeah, that'd be easy to implement, obviously nobody just felt the need so far...
Do you have some more hacks in you ~/.emacs making using Emacs easier for Vim addicts?
Yes. Not sure what you'd be most interested in... Some simple examples (assuming you use Viper/Vimpulse): ;; redefine `viper-yank-line' (equiv. of the famous `map Y y$') (defun viper-yank-line (arg) "Delete to the end of line." (interactive "P") (viper-goto-eol (cons arg ?y))) (define-key viper-vi-basic-map "ga" 'what-cursor-position) (define-key viper-vi-basic-map "go" 'goto-char)
Eg is there a :qa! like command (without the nasty: You have unsaved open files..)
Hm... Although I do often use :qa! (I have it bound to a key) in Vim, I _never_ felt the need in Emacs :-D. Most people seem to use Emacs rather differently, e.g. you never start Emacs to edit a file and then quit it -- you use emacsclient for that, and then there is no such thing as "quickly quit without saving". That being said, what I do find *very* annoying is the default `yes-or-no-p', i.e. having to type "yes" instead of just pressing "y" on this kind of prompts; (fset 'yes-or-no-p 'y-or-n-p) fixes that. HTH, Štěpán
Excerpts from Štěpán Němec's message of Mon Jul 19 08:47:01 +0200 2010:
Marc Weber <[email protected]> writes:
Hi list,
I've been using Vim for years. However I'm at a point I think Vim will no longer serve (all) my needs - that's because the core is lacking functionality - which can be implemented - but would take a lot of time.
Welcome to the club. ;-)
I want to thank you - I was very pleased seeing that these features just work: - ctrl-vI..<esc> (instert into multiple lines) - text objects - all visual modes - % in combination with visual mode.
So Emacs comes pretty close to what I'm used to (which I use most)
There is one last thing which I'm missing: Opening files by glob patterns:
noremap :e :e<space>**/*
Be sure to also have a look at Frank Fischer's Vim mode:
http://www.emacswiki.org/emacs/VimMode I will. However I'm not interested in duplicating Vim functionality. I want the navigation and movement combinations I use most. And they seem to work.
Yeah, I think that the double asterisk doesn't work (don't know if some Emacs package implements it); but normal shell patterns do work, even with plain `find-file'. Ido provides an `ido-wide-find-file-or-pop-dir' command, bound to M-f, which uses `find' to search for a file under current directory. I'm guessing that could help?
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..
Hm... Although I do often use :qa! (I have it bound to a key) in Vim, I _never_ felt the need in Emacs :-D. When testing Emacs plugin I rather restart than try to update scripts using reload-file or such
How are you supposed to scroll in vimpulse 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. 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. Marc Weber
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
Excerpts from Štěpán Němec's message of Mon Jul 19 19:41:44 +0200 2010:
Marc Weber <[email protected]> writes: 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:
Let me rephrase then: I think Emacs users who don't know vimpulse should find vimpulse easily. So in fact you don't have to include the sources. Adding a big fat help entry telling about its existence would be enough. Eg make the viper screen say "vimpulse is based on viper and provides more advanced Vim editing featuers. See ...." Maybe you're right that it doesn't make sense to move all code into Emacs. About the licensing: I don't understand it. GNU emacs is GPL, isn't it? So everyone who is using it may ask for source. If you get a copy you may redistribute the code yourself etc. http://www.xemacs.org/About/XEmacsVsGNUemacs.html quote: " What we are possibly losing is the ability to force others to make their modifications free ". Can someone give me an example how this works: Making a GPLd application like emacs unfree - or parts of it? Why do you have to know all copyright holders to enforce the GPL freedoms? Is it because you can't enforce the GPL laws for someone else - because the one (maybe unkown) person must do it? Marc Weber
Marc Weber <[email protected]> writes:
Excerpts from Štěpán Němec's message of Mon Jul 19 19:41:44 +0200 2010:
Marc Weber <[email protected]> writes: 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:
Let me rephrase then: I think Emacs users who don't know vimpulse should find vimpulse easily. So in fact you don't have to include the sources. Adding a big fat help entry telling about its existence would be enough.
Eg make the viper screen say "vimpulse is based on viper and provides more advanced Vim editing featuers. See ...."
Well... I get your point, and it might even be actually possible, i.e. there is not *that* many libraries emulating Vim. On the other hand, "standard" practice nowadays is to search the N3tz, and you're bound to find the Emacs Wiki and all that jazz pretty soon if you're curious about kool stoves. In other words, I don't remember a single third party package being recommended or even mentioned _anywhere_ in GNU Emacs documentation :-)
About the licensing: I don't understand it. GNU emacs is GPL, isn't it? So everyone who is using it may ask for source. If you get a copy you may redistribute the code yourself etc.
Sure. You can redistribute it under the same terms (GNU GPL).
http://www.xemacs.org/About/XEmacsVsGNUemacs.html quote: " What we are possibly losing is the ability to force others to make their modifications free ".
Can someone give me an example how this works: Making a GPLd application like emacs unfree - or parts of it?
You can't do that AFAIK. What would be the point of such a license?
Why do you have to know all copyright holders to enforce the GPL freedoms?
The point here is not *knowing* about all the copyright holders. The point is that the FSF insists on being *the* copyright holder on some of the GNU software, including GNU Emacs. The only rationale I've seen in various phrasings goes like "it will put us in better position while enforcing the GNU GPL". (Well OK, I see nothing _necessarily_ wrong with that. What is braindamaged in my opinion is the current procedure which requires sending papers all around the world. When I asked if you could at least get a "cover all" for all GNU projects or if the assignment could be printed only *once*, signed, scanned and sent by e-mail, the answer to both questions was "unfortunately, our counsel has advised against [doing that]". :-))) They seem to be willing to give you an assignment for at most 4 GNU projects at one time. It's horrible. I hate them for that and I still hope it will change. I don't know about anybody else who does this. Let's avoid GNU software. LET'S SWITCH TO XEMACS! UAAA! :-))
Is it because you can't enforce the GPL laws for someone else - because the one (maybe unkown) person must do it?
I doubt that. I don't know about any issues with GPL or BSD or other standard libre software licenses where the single/multiple copyright holders issue or enforceability was a problem. Which does not mean there are really no issues of course -- I'm not only not a lawyer, I'm also absolutely not interested in this kind of stuff. But I did ask the FSF copyright clerk, and haven't got any answer either (for almost a month now; I'm going to PING them when it's a full month, they must be busy gluing envelopes). I also failed to find anything on gnu.org or the Internet. It's all just that general "better position" and "counsel advised" wish-wash. Štěpán
The point here is not *knowing* about all the copyright holders. The point is that the FSF insists on being *the* copyright holder on some of the GNU software, including GNU Emacs. The only rationale I've seen in various phrasings goes like "it will put us in better position while enforcing the GNU GPL".
To enforce the GPL there must be a vialotor, correct? Let's call that person V. What happens if V distributes Emacs adding one anonymous patch. I'd call this patched Emacs P-Emacs. Then FSF has no longer the strong position on PEmacs it has on GNU Emacs, right? So what's the point in protecting GNU Emacs if you can fork and call it XYZ-Emacs thereby weakening FSF's position on XYZ Emacs which still looks and behaves like GNU Emacs? If you read up what is written about LGPL: Please don't use unless you have to ? You have to use LGPL if other libraries exist proprietary firms could use. People could use XYZ-Emacs because its behaviour is almost the same as of GNU Emacs. Marc Weber
On 2010-07-19 19:41, Štěpán Němec wrote:
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.
You have a point, of course. Actually, the very package that got me started with Emacs in the first place -- AUCTeX -- is not included as part of Emacs. Then there's the mentioned issue of "copyright significance" -- apparently, the threshold is somewhere at 15 lines.[1] I don't get how this is supposed to go together with distributed development, at all. Paradoxically, the more /successful/ a project becomes -- the more people get involved and contribute their time and (sometimes) huge chunks of code -- the harder it becomes to get the thing approved. (Of course, since we migrated from SVN to Git, it has become even easier for anyone to experiment locally and submit their work, fully credited, if useful to others. And that's really the point.) I don't see how open software can breathe and grow under these regulations. I don't understand the Free Software Foundation's stance on software freedom. If I have to choose, I'll pick an inclusionist stance on contributed code over an inclusionist stance on Emacs' libraries, any old day of the week. [1] http://article.gmane.org/gmane.emacs.vim-emulation/45/ -- Vegard
participants (3)
-
Marc Weber -
Vegard Øye -
Štěpán Němec