Insert mode - point doesn't move to next line
I'm having an issue with the master branch where the cursor in Insert mode doesn't always move to the next line with Return or Ctrl-J. I can reproduce this in the following way: 1. open a new buffer with `:new` 2. Go into Insert mode with `i`. 3. Type `hello world` 4. Hit Enter, the cursor goes to the beginning of the line just typed and not the next line. This also happens intermittently in eshell where when I enter a command like `ls` the cursor moves to the beginning of this line rather than the prompt that comes up after the output. Thanks ... -deech
On Tue, Oct 30, 2012 at 4:52 PM, aditya siram <[email protected]>wrote:
I'm having an issue with the master branch where the cursor in Insert mode doesn't always move to the next line with Return or Ctrl-J. I can reproduce this in the following way: 1. open a new buffer with `:new` 2. Go into Insert mode with `i`. 3. Type `hello world` 4. Hit Enter, the cursor goes to the beginning of the line just typed and not the next line.
Frank solved this. Pull latest Evil.
Just pulled, the problem is still occurring. -deech On Tue, Oct 30, 2012 at 5:13 PM, Barry OReilly <[email protected]> wrote:
On Tue, Oct 30, 2012 at 4:52 PM, aditya siram <[email protected]> wrote:
I'm having an issue with the master branch where the cursor in Insert mode doesn't always move to the next line with Return or Ctrl-J. I can reproduce this in the following way: 1. open a new buffer with `:new` 2. Go into Insert mode with `i`. 3. Type `hello world` 4. Hit Enter, the cursor goes to the beginning of the line just typed and not the next line.
Frank solved this. Pull latest Evil.
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 2012-10-30, aditya siram <[email protected]> wrote:
Just pulled, the problem is still occurring.
It should not. Please start with `make emacs' from evil's source (and do not forget to recompile after pulling). Frank
The problem is still occurring even in the emacs that pops up to run the tests. But it's pretty odd. I edebugged evil-ret, I can see that it correctly moves point to the next line, but just after the function returns point moves right back to beginning the first line so the problem isn't evil-ret. I was able to reproduce the problem by replacing step 4 with `M-x newline`. However this problem does not occur if I move to emacs-mode temporarily and hit return. Does evil-ret somehow change a global variable that `newline` depends on? -deech On Wed, Oct 31, 2012 at 3:54 AM, Frank Fischer <[email protected]> wrote:
On 2012-10-30, aditya siram <[email protected]> wrote:
Just pulled, the problem is still occurring.
It should not. Please start with `make emacs' from evil's source (and do not forget to recompile after pulling).
Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 2012-10-31, aditya siram <[email protected]> wrote:
The problem is still occurring even in the emacs that pops up to run the tests. But it's pretty odd. I edebugged evil-ret, I can see that it correctly moves point to the next line, but just after the function returns point moves right back to beginning the first line so the problem isn't evil-ret.
I was able to reproduce the problem by replacing step 4 with `M-x newline`. However this problem does not occur if I move to emacs-mode temporarily and hit return. Does evil-ret somehow change a global variable that `newline` depends on?
The problem has been the last-line adjustment of evil (see another recent thread in this mailing list for a description). This adjustment happens in a post-command-hook. But it has been removed in commit f45a6d9 (git) resp. 394e8be (hg). That's why we assume that your tree has not been updated correctly. Please do the following steps: 1. update your tree (maybe create a new fresh clone) 2. remove *all* compiled files (`make clean') 3. check with 'make term' or 'make emacs' 4. if the error still occurs, check with 'grep evil-with-adjust-cursor *.el' whether `evil-with-adjust-cursor' appears somewhere in the code, if so then your tree has not been updated correctly to the latest revision. 5. please tell us your Emacs version and revision you use Currently I'm not able to reproduce the problem, so I can't help you. Frank
Egg on my face. I had some changes I forgot about and when I pulled they didn't apply or signal a conflict. When I stashed them things work fine. Sorry for the noise and thanks for your time! -deech On Wed, Oct 31, 2012 at 8:52 AM, Frank Fischer <[email protected]> wrote:
On 2012-10-31, aditya siram <[email protected]> wrote:
The problem is still occurring even in the emacs that pops up to run the tests. But it's pretty odd. I edebugged evil-ret, I can see that it correctly moves point to the next line, but just after the function returns point moves right back to beginning the first line so the problem isn't evil-ret.
I was able to reproduce the problem by replacing step 4 with `M-x newline`. However this problem does not occur if I move to emacs-mode temporarily and hit return. Does evil-ret somehow change a global variable that `newline` depends on?
The problem has been the last-line adjustment of evil (see another recent thread in this mailing list for a description). This adjustment happens in a post-command-hook. But it has been removed in commit f45a6d9 (git) resp. 394e8be (hg). That's why we assume that your tree has not been updated correctly. Please do the following steps:
1. update your tree (maybe create a new fresh clone) 2. remove *all* compiled files (`make clean') 3. check with 'make term' or 'make emacs' 4. if the error still occurs, check with 'grep evil-with-adjust-cursor *.el' whether `evil-with-adjust-cursor' appears somewhere in the code, if so then your tree has not been updated correctly to the latest revision. 5. please tell us your Emacs version and revision you use
Currently I'm not able to reproduce the problem, so I can't help you.
Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
participants (3)
-
aditya siram -
Barry OReilly -
Frank Fischer