Hello, First of all, thank you very much for your great work on evil! I'm really pleasantly surprised at how active your development is :) I'm a vim user who is trying to learn emacs without losing the handy modal editing of vim (as I imagine many others on this list are), and evil seems to be exactly what I need. I have a couple of questions. First, I am wondering if evil-want-C-u-scroll is broken. I have set it to t using M-x customize-group evil-mode, which causes (custom-set-variables '(evil-want-C-u-scroll t)) to appear in my ~/.emacs , but I don't see any difference in the behavior of evil. Is there something else I need to do in order to make C-u call evil-scroll-up (as C-h k C-d tells me that C-d is bound to evil-scroll-down)? Second, I am wondering about the behavior of :q . It seems to me that it behaves more like :qa does in vim. According to vim documentation, :q[uit] should "Quit the current window. Quit Vim if this is the last window.". So I guess it should be similar to kill-buffer in emacs, no? Thanks again! -Keshav
In my case, evil-want-C-u-scroll is set before (require 'evil) as this is plain variable and evil will not be able to pick it up after is loaded. IMHO, the same should be applied for other global variables.
Second, I am wondering about the behaviour of :q
In vim, when there are multiple buffers but one window, :q will quit vim; the same way evil does. When there are multiple windows (or splits), :q will quit selected one. Again, evil does the same. Hoping I got you correctly :) On Thu, Feb 16, 2012 at 8:03 AM, Keshav Kini <[email protected]> wrote:
Hello,
First of all, thank you very much for your great work on evil! I'm really pleasantly surprised at how active your development is :) I'm a vim user who is trying to learn emacs without losing the handy modal editing of vim (as I imagine many others on this list are), and evil seems to be exactly what I need.
I have a couple of questions. First, I am wondering if evil-want-C-u-scroll is broken. I have set it to t using M-x customize-group evil-mode, which causes (custom-set-variables '(evil-want-C-u-scroll t)) to appear in my ~/.emacs , but I don't see any difference in the behavior of evil. Is there something else I need to do in order to make C-u call evil-scroll-up (as C-h k C-d tells me that C-d is bound to evil-scroll-down)?
Second, I am wondering about the behavior of :q . It seems to me that it behaves more like :qa does in vim. According to vim documentation, :q[uit] should "Quit the current window. Quit Vim if this is the last window.". So I guess it should be similar to kill-buffer in emacs, no?
Thanks again!
-Keshav
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Sanel Zukan <[email protected]> writes:
In my case, evil-want-C-u-scroll is set before (require 'evil) as this is plain variable and evil will not be able to pick it up after is loaded. IMHO, the same should be applied for other global variables.
Aha! That must be it. customize automatically puts its variables at the end of ~/.emacs , though. So maybe evil has the responsibility of loading the customize variables properly, as Frank says.
In vim, when there are multiple buffers but one window, :q will quit vim; the same way evil does. When there are multiple windows (or splits), :q will quit selected one. Again, evil does the same. Hoping I got you correctly :)
Hmm. By "multiple buffers but one window", do you mean when you supply multiple filenames to vim on the command line, and then use :next and :previous to move between them? I wouldn't have thought that corresponds to the way emacs can have multiple buffers open concurrently, especially since vim actually closes the current file when you use :next or :prev, unlike what happens in emacs when you select a different buffer. It seems to me that emacs with its buffers is a lot more similar to how vim works when you use ":tabedit" to open a new file and use [count]gt and [count]gT to switch between them. And :q does indeed close a single tab and not close vim entirely, when multiple tabs are open. But I'm a total newbie at emacs and not exactly a hardened vim wizard either, so I'm probably way off base. Thanks! -Keshav
On Thu 16 Feb 2012 02:05:48 PM FET, Keshav Kini wrote:
In vim, when there are multiple buffers but one window, :q will quit vim; the same way evil does. When there are multiple windows (or splits), :q will quit selected one. Again, evil does the same. Hoping I got you correctly :)
Hmm. By "multiple buffers but one window", do you mean when you supply multiple filenames to vim on the command line, and then use :next and :previous to move between them? I wouldn't have thought that corresponds to the way emacs can have multiple buffers open concurrently, especially since vim actually closes the current file when you use :next or :prev, unlike what happens in emacs when you select a different buffer.
It seems to me that emacs with its buffers is a lot more similar to how vim works when you use ":tabedit" to open a new file and use [count]gt and [count]gT to switch between them. And :q does indeed close a single tab and not close vim entirely, when multiple tabs are open.
Check out ":help buffers" in vim :) Vim has buffers similar to emacs (hovewer much less usable ui for navigation). You can create new buffer with :edit /tmp/file.txt and list buffers with :buffers. And :q quits vim even if you have several open buffers. So evil is perfect here :)
antono <[email protected]> writes:
Check out ":help buffers" in vim :) Vim has buffers similar to emacs (hovewer much less usable ui for navigation). You can create new buffer with :edit /tmp/file.txt and list buffers with :buffers. And :q quits vim even if you have several open buffers. So evil is perfect here :)
I learned something today! Thanks! :) -Keshav
On Thu, Feb 16, 2012 at 03:03:07PM +0800, Keshav Kini wrote:
I have a couple of questions. First, I am wondering if evil-want-C-u-scroll is broken. I have set it to t using M-x customize-group evil-mode, which causes (custom-set-variables '(evil-want-C-u-scroll t)) to appear in my ~/.emacs , but I don't see any difference in the behavior of evil. Is there something else I need to do in order to make C-u call evil-scroll-up (as C-h k C-d tells me that C-d is bound to evil-scroll-down)?
I think you need to set `evil-want-C-u-scroll' to t *before* evil is loaded in your .emacs file, i.e., something like (setq evil-want-C-u-scroll t). The reason is that this variable is examined when evil creates its key-bindings (and only then). Probably we need a better way to respect the customization options (I would consider the current behavior as bug).
Second, I am wondering about the behavior of :q . It seems to me that it behaves more like :qa does in vim. According to vim documentation, :q[uit] should "Quit the current window. Quit Vim if this is the last window.". So I guess it should be similar to kill-buffer in emacs, no?
kill-buffer would not only close the window but also close the file and this is not what :q should do. :q in evil closes the current window or the current frame (if only one window) or Emacs completely (if only one frame), without closing any file (except in last case, of course). :qa on the other hand closes Emacs completely (possibly asking for saving modified buffers). I think this is equivalent to Vim's behavior. Frank
On Thu, Feb 16, 2012 at 10:03 AM, Frank Fischer <[email protected]> wrote: (...)
I think you need to set `evil-want-C-u-scroll' to t *before* evil is loaded in your .emacs file, i.e., something like (setq evil-want-C-u-scroll t). The reason is that this variable is examined when evil creates its key-bindings (and only then). Probably we need a better way to respect the customization options (I would consider the current behavior as bug).
Maybe not necessarily a bug, but it's for sure an annoyance: when using M-x customize-variable to set `evil-want-C-u-scroll' it won't work as long as you don't move your `custom-set-variables' block to somewhere before evil is required in your .emacs file.
Second, I am wondering about the behavior of :q . It seems to me that it behaves more like :qa does in vim. According to vim documentation, :q[uit] should "Quit the current window. Quit Vim if this is the last window.". So I guess it should be similar to kill-buffer in emacs, no?
kill-buffer would not only close the window but also close the file and this is not what :q should do. :q in evil closes the current window or the current frame (if only one window) or Emacs completely (if only one frame), without closing any file (except in last case, of course). :qa on the other hand closes Emacs completely (possibly asking for saving modified buffers). I think this is equivalent to Vim's behavior. (...)
I don't know why, but I could never get used to the way Vi's :q works on Emacs. I just doesn't feel right (that is, to me -- it's a completely personal thing, I suppose). Fortunately C-x k [RET] is exactly the same number of keystrokes ;-) Cheers, -- José A. Romero L. [email protected] "We who cut mere stones must always be envisioning cathedrals." (Quarry worker's creed)
José A. Romero L. <[email protected]> writes:
On Thu, Feb 16, 2012 at 10:03 AM, Frank Fischer <[email protected]> wrote:
kill-buffer would not only close the window but also close the file and this is not what :q should do. :q in evil closes the current window or the current frame (if only one window) or Emacs completely (if only one frame), without closing any file (except in last case, of course). :qa on the other hand closes Emacs completely (possibly asking for saving modified buffers). I think this is equivalent to Vim's behavior. (...)
I don't know why, but I could never get used to the way Vi's :q works on Emacs. I just doesn't feel right (that is, to me -- it's a completely personal thing, I suppose). Fortunately C-x k [RET] is exactly the same number of keystrokes ;-)
Maybe it is because of what I said above, namely that emacs buffers feel more like vim tabs than the kind of multi-file editing that uses :next and :prev, whatever that is called. Frank: I will set the customization variable manually before the (require 'evil) line for now and await the fixing of this bug you identified :) Thanks! -Keshav
Keshav Kini <[email protected]> writes:
Frank: I will set the customization variable manually before the (require 'evil) line for now and await the fixing of this bug you identified :) Thanks!
I recently switched to Emacs 24's package manager instead of installing packages manually and individually. This caused me to hit the bug again. Sorry to bump, but could you look into maybe fixing this? Ideally, if a user just uses M-x customize and doesn't touch ~/.emacs , the customization variable should "just work". By default M-x customize seems to put the customization clause at the bottom of ~/.emacs . Thanks, Keshav
On 2012-02-16 10:03 +0100, Frank Fischer wrote:
I think you need to set `evil-want-C-u-scroll' to t *before* evil is loaded in your .emacs file, i.e., something like (setq evil-want-C-u-scroll t). The reason is that this variable is examined when evil creates its key-bindings (and only then). Probably we need a better way to respect the customization options (I would consider the current behavior as bug).
I think I can fix this with the :set keyword argument of `defcustom', which specifies a setter function for the variable. For example, the `evil-toggle-key' customization variable has such a function, calling `evil-set-toggle-key' to refresh the relevant keymaps. Thus, by adding the necessary functions, Evil's customization variables can be set in two ways: either with `setq' before Evil is loaded, or at the end of .emacs with Custom, in which case the setter functions should re-configure things as necessary. -- Vegard
On Wed, Feb 22, 2012 at 2:15 PM, Vegard Øye <[email protected]> wrote: (...)
Thus, by adding the necessary functions, Evil's customization variables can be set in two ways: either with `setq' before Evil is loaded, or at the end of .emacs with Custom, in which case the setter functions should re-configure things as necessary. (...)
That would be really nice. It would also allow to toggle on and off the feature without restarting Emacs, which is valuable for those of us running in server mode. Cheers, -- José A. Romero L. [email protected] "We who cut mere stones must always be envisioning cathedrals." (Quarry worker's creed)
participants (6)
-
antono -
Frank Fischer -
José A. Romero L. -
Keshav Kini -
Sanel Zukan -
Vegard Øye