evil conflicts in c-mode
Hello, I am an emacs newbie with vim background, return key in N mode works alright for plain text files such as a text file called temp. but in a c++ file for example temp.cpp, it is described as (newline-and-indent) I did c-h k return to find it out. Is this a desired behavior in c-mode? is there anyway to disable this behavior? in vim normal mode, return shouldn't do anything. Thanks for any help! Jim.
On Sun, Dec 04, 2011 at 04:38:57PM -0500, Jim Green wrote:
Hello, I am an emacs newbie with vim background,
return key in N mode works alright for plain text files such as a text file called temp.
but in a c++ file for example temp.cpp, it is described as (newline-and-indent)
I did c-h k return to find it out.
Is this a desired behavior in c-mode? is there anyway to disable this behavior? in vim normal mode, return shouldn't do anything.
The default binding of "RET" in normal state is `evil-ret', which usually moves the cursor COUNT lines downwards. The binding is in `evil-motion-state-map' which acts as a base keymap for other states like normal or visual state. So if this binding is *not* active in normal state in your case, something went wrong or some configuration changes this binding. In insert (and emacs) state evil does not override the binding of "RET", therefore the default binding of the currently active (major-)mode is active, which is probably `newline-and-indent' for c/c++ mode. If you do not like `evil-ret' in normal state you can, e.g., disable this binding using (define-key 'evil-motion-state-map (kbd "RET") nil) but then the default binding of the currently active modes will be active again, or (define-key 'evil-motion-state-map (kbd "RET") 'undefined) or (define-key 'evil-normal-state-map (kbd "RET") 'undefined) which will disable the RET key in either all states based on motion-state or on normal-state. Frank
On 5 December 2011 07:36, Frank Fischer <[email protected]> wrote:
The default binding of "RET" in normal state is `evil-ret', which usually moves the cursor COUNT lines downwards. The binding is in `evil-motion-state-map' which acts as a base keymap for other states like normal or visual state.
So if this binding is *not* active in normal state in your case, something went wrong or some configuration changes this binding.
In insert (and emacs) state evil does not override the binding of "RET", therefore the default binding of the currently active (major-)mode is active, which is probably `newline-and-indent' for c/c++ mode.
If you do not like `evil-ret' in normal state you can, e.g., disable this binding using
(define-key 'evil-motion-state-map (kbd "RET") nil)
but then the default binding of the currently active modes will be active again, or
(define-key 'evil-motion-state-map (kbd "RET") 'undefined)
or
(define-key 'evil-normal-state-map (kbd "RET") 'undefined)
which will disable the RET key in either all states based on motion-state or on normal-state.
Hi, I think I didn't state the issue clear in the post. basicall for non c++/c files, RET behaves as expected, it does 'evil-ret'. but in c++/c files, even in evil normal mode, RET would do "new-line-indent", I guess the reason is cc-mode doesn't differentiate the evil normal mode or insert mode. Is there a way to make sure whatever major mode emacs is in, in evils normal mode, 'RET' would not cause emacs go into insert mode? Thank you! Jim
On Tue, Dec 06, 2011 at 12:40:23AM +0000, Jim Green wrote:
Hi, I think I didn't state the issue clear in the post.
basicall for non c++/c files, RET behaves as expected, it does 'evil-ret'.
but in c++/c files, even in evil normal mode, RET would do "new-line-indent", I guess the reason is cc-mode doesn't differentiate the evil normal mode or insert mode.
No, when evil is activated RET in normal-state should *not* do `new-line-indent', even in c++/c files. At least it does not in my box and I use c++/c every day. (I suppose you mean `newline-and-indent' because I do not know any function `new-line-indent') Please test what happens if you execute 'make emacs' (or even 'make clean emacs') in evil's source directory. This should start a clean Emacs instance with only evil loaded. Then open some c/c++ file and look if the problem remains. If yes, there must be a problem with evil and it would be good if you can provide a minimal example (starting with 'make emacs') to reproduce the error. Otherwise it's probably a configuration issue of your emacs.
Is there a way to make sure whatever major mode emacs is in, in evils normal mode, 'RET' would not cause emacs go into insert mode?
RET should never make emacs go to insert mode. At least in no situation I'm aware of. Again, please provide a minimal example how to reproduce this error, if possible, otherwise we can't help you. Frank
On 6 December 2011 08:44, Frank Fischer <[email protected]> wrote:
On Tue, Dec 06, 2011 at 12:40:23AM +0000, Jim Green wrote:
Hi, I think I didn't state the issue clear in the post.
basicall for non c++/c files, RET behaves as expected, it does 'evil-ret'.
but in c++/c files, even in evil normal mode, RET would do "new-line-indent", I guess the reason is cc-mode doesn't differentiate the evil normal mode or insert mode.
No, when evil is activated RET in normal-state should *not* do `new-line-indent', even in c++/c files. At least it does not in my box and I use c++/c every day. (I suppose you mean `newline-and-indent' because I do not know any function `new-line-indent')
Please test what happens if you execute 'make emacs' (or even 'make clean emacs') in evil's source directory. This should start a clean Emacs instance with only evil loaded. Then open some c/c++ file and look if the problem remains. If yes, there must be a problem with evil and it would be good if you can provide a minimal example (starting with 'make emacs') to reproduce the error. Otherwise it's probably a configuration issue of your emacs.
I got the following error(I think expected) when make clean emacs, but enter works perfectly as tested above for a test c++ file. I found that in my cc-mode.rc.el I copied from somewhere else ret is redefined... sorry about wasting your time and Thanks for such a great debugging trick! Jim. my emacs version is GNU Emacs 24.0.92.1 Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129 Started at: 2011-12-06 21:35:41-0500 Finished. Finished at: 2011-12-06 21:35:43-0500 ........................................F.....................................................................F.................. F evil-test-extract-count Test `evil-extract-count' Info: Exact with count (error "No command bound to \346") F evil-test-rot13-repeat Test repeating of `evil-rot13' (ert-test-failed ((should (string= (buffer-substring (max ... ...) (point)) before)) :form (string= " buffer" ";; Guvf") :value nil))
Is there a way to make sure whatever major mode emacs is in, in evils normal mode, 'RET' would not cause emacs go into insert mode?
RET should never make emacs go to insert mode. At least in no situation I'm aware of. Again, please provide a minimal example how to reproduce this error, if possible, otherwise we can't help you.
On Wed, Dec 07, 2011 at 02:42:07AM +0000, Jim Green wrote:
I got the following error(I think expected) when make clean emacs
Well, no. No such error should occur.
, but enter works perfectly as tested above for a test c++ file. I found that in my cc-mode.rc.el I copied from somewhere else ret is redefined...
sorry about wasting your time and Thanks for such a great debugging trick!
Jim.
my emacs version is GNU Emacs 24.0.92.1
Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129
Started at: 2011-12-06 21:35:41-0500 Finished. Finished at: 2011-12-06 21:35:43-0500
........................................F.....................................................................F..................
F evil-test-extract-count Test `evil-extract-count' Info: Exact with count (error "No command bound to \346")
I have an idea for this bug. Could you please test the patch appended to this mail and check if this error still occurs?
F evil-test-rot13-repeat Test repeating of `evil-rot13' (ert-test-failed ((should (string= (buffer-substring (max ... ...) (point)) before)) :form (string= " buffer" ";; Guvf") :value nil))
I have no real idea what's happening here (it works on my box). If I look at the test code I suppose that the cursor after executing g ? M-Right is placed at the wrong position (the test assumes that point does not move when executing this command), but I have to check if your Emacs version behaves differently. Frank
On 7 December 2011 09:34, Frank Fischer <[email protected]> wrote:
On Wed, Dec 07, 2011 at 02:42:07AM +0000, Jim Green wrote:
I got the following error(I think expected) when make clean emacs
Well, no. No such error should occur.
, but enter works perfectly as tested above for a test c++ file. I found that in my cc-mode.rc.el I copied from somewhere else ret is redefined...
sorry about wasting your time and Thanks for such a great debugging trick!
Jim.
my emacs version is GNU Emacs 24.0.92.1
Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129
Started at: 2011-12-06 21:35:41-0500 Finished. Finished at: 2011-12-06 21:35:43-0500
........................................F.....................................................................F..................
F evil-test-extract-count Test `evil-extract-count' Info: Exact with count (error "No command bound to \346")
I have an idea for this bug. Could you please test the patch appended to this mail and check if this error still occurs?
I applied patch ~/.emacs.d/evil % git diff diff --git a/evil-tests.el b/evil-tests.el index e89918a..32b8ee6 100644 --- a/evil-tests.el +++ b/evil-tests.el @@ -4234,8 +4234,8 @@ if no previous selection") (ert-info ("Exact with count") (should (equal (evil-extract-count "420x") (list 420 'evil-delete-char "x" nil))) - (should (equal (evil-extract-count "420\M-f") - (list 420 'forward-word "\M-f" nil))) + (should (equal (evil-extract-count (vconcat "420" (kbd "M-f"))) + (list 420 'forward-word (vconcat (kbd "M-f")) nil))) (should (equal (evil-extract-count "2301g0") (list 2301 'evil-beginning-of-visual-line "g0" nil)))) but still got the errors: Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129 Started at: 2011-12-07 18:41:11-0500 Finished. Finished at: 2011-12-07 18:41:14-0500 ........................................F.....................................................................F.................. F evil-test-extract-count Test `evil-extract-count' Info: Exact with count (error "No command bound to [134217830]") F evil-test-rot13-repeat Test repeating of `evil-rot13' (ert-test-failed ((should (string= (buffer-substring (max ... ...) (point)) before)) :form (string= " buffer" ";; Guvf") :value nil))
F evil-test-rot13-repeat Test repeating of `evil-rot13' (ert-test-failed ((should (string= (buffer-substring (max ... ...) (point)) before)) :form (string= " buffer" ";; Guvf") :value nil))
I have no real idea what's happening here (it works on my box). If I look at the test code I suppose that the cursor after executing
g ? M-Right
is placed at the wrong position (the test assumes that point does not move when executing this command), but I have to check if your Emacs version behaves differently.
my emacs is: GNU Emacs 24.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2011-12-06 on cw-bkp0, modified by Debia Thankfor checking the code, it doesn't affect daily use. Jim
On Wed, Dec 07, 2011 at 11:43:20PM +0000, Jim Green wrote:
I applied patch
...
but still got the errors:
Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129
Interesting. It seems as if M-f is not bound to 'forward-word and therefore no command bound to M-f is found - I wonder why. Could you please check if M-f (in a clean Emacs, make emacs) is bound? Thx, Frank
On 8 December 2011 07:18, Frank Fischer <[email protected]> wrote:
On Wed, Dec 07, 2011 at 11:43:20PM +0000, Jim Green wrote:
I applied patch
...
but still got the errors:
Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129
Interesting. It seems as if M-f is not bound to 'forward-word and therefore no command bound to M-f is found - I wonder why.
Could you please check if M-f (in a clean Emacs, make emacs) is bound?
Thx, Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 9 December 2011 00:03, Jim Green <[email protected]> wrote:
On 8 December 2011 07:18, Frank Fischer <[email protected]> wrote:
On Wed, Dec 07, 2011 at 11:43:20PM +0000, Jim Green wrote:
I applied patch
...
but still got the errors:
Selector: t Passed: 127 Failed: 2 (2 unexpected) Total: 129/129
Interesting. It seems as if M-f is not bound to 'forward-word and therefore no command bound to M-f is found - I wonder why.
Could you please check if M-f (in a clean Emacs, make emacs) is bound?
Hi, Frank, c-h k m-f shows it is undefined. Thanks! Jim
On 9 December 2011 08:09, Frank Fischer <[email protected]> wrote:
On Fri, Dec 09, 2011 at 12:04:12AM +0000, Jim Green wrote:
Hi, Frank, c-h k m-f shows it is undefined.
Interesting, I wonder why. Is M-<right> bound to 'forward-word?
Here is what I have: <M-right> runs the command right-word, which is an interactive compiled Lisp function in `bindings.el'. It is bound to <C-right>, <M-right>. (right-word &optional N) Move point N words to the right (to the left if N is negative). Depending on the bidirectional context, this may move either forward or backward in the buffer. This is in contrast with M-f and M-b, which see. Value is normally t. If an edge of the buffer or a field boundary is reached, point is left there there and the function returns nil. Field boundaries are not noticed if `inhibit-field-text-motion' is non-nil. Thanks. Jim
participants (2)
-
Frank Fischer -
Jim Green