elpy-format-code dosn't save the point location

Created on 29 Oct 2016  Â·  10Comments  Â·  Source: jorgenschaefer/elpy

I have a before hook on my config so that after before a python file is save it will run elpy-format-code. However when elpy-format-code runs my cursor end up at the end of the buffer rather then stay where it is

Bug

Most helpful comment

I have the same problem. Running Elpy 1.13.0.

All 10 comments

Hmmm, on my side that randomly happens. Sometimes it moves the cursor, sometimes it won't. I'm using yapf. One way to work around this is to add save-excursion inside the condition statements in elpy-format-code.

Could you post the output of M-x elpy-config? This was a bug in older versions of Elpy. Current versions should try to retain the line and column at least.

I have the same problem. Running Elpy 1.13.0.

Here is the output from M-x elpy-config.

Elpy Configuration

Virtualenv........: None
RPC Python........: 3.5.2 (/workspace/software/Python-3.5.2/build/bin/python3)
Interactive Python: python3 (/workspace/software/Python-3.5.2/build/bin/python3)
Emacs.............: 25.1.1
Elpy..............: 1.14.1
Jedi..............: 0.10.0
Rope..............: 0.10.5
Importmagic.......: 0.1.7
Autopep8..........: 1.3.1
Yapf..............: 0.16.0
Syntax checker....: flake8 (/workspace/software/Python-3.5.2/build/bin/flake8)

Hm. elpy--fix-code-with-formatter will remember the line and column point was at before the code fix-up, and return there afterwards. I do not see why this should fail. Testing this localy, it also works for me.

I'm really sorry, but without a way to reproduce this, I'm a bit at a loss here. Can anyone of you debug this any further?

Same problem here when I run 'elpy-yapf-fix-code.
I guess the cursor position is preserved if yapf has something to fix, and the cursor goes to the end of buffer if not.

I'm running Elpy on my Windows 10 (64-bit).
Is there any way to see debug messages for you guys?

The followings are my Elpy Configuration.

Virtualenv........: None
RPC Python........: 3.5.3 (c:/Users/kju/AppData/Local/Programs/Python/Python35/python.exe)
Interactive Python: ipython (c:/Users/kju/AppData/Local/Programs/Python/Python35/Scripts/ipython.exe)
Emacs.............: 25.1.1
Elpy..............: 1.14.1
Jedi..............: 0.10.0
Rope..............: 0.9.4-1
Importmagic.......: 0.1.7
Autopep8..........: 1.3.1
Yapf..............: 0.16.0
Syntax checker....: flake8.exe (c:/Users/kju/AppData/Local/Programs/Python/Python35/Scripts/flake8.exe)

elpy--fix-code-with-formatter will always move to the last line/column …

Hm. Does M-x elpy-yapf-fix-code cause an error or something?

If you know elisp, could you add some debugging code to elpy--fix-code-with-formatter at the end around the forward-line call to see whether it actually tries to go to that line?

@jorgenschaefer so I have the same problem, and edebug-ing through the code it appears that when yapf doesn't modify the content, elpy-buffer--replace-region doesn't do anything at all, therefore leaves point in place. After that, the forward-line call moves us somewhere else, which is basically line 2N, if we were initially at line N.

On the other hand, when there is a replacement, after the call to elpy-buffer--replace-region the point is at (point-min), which makes the forward-line call correct. I'm not entirely sure I understand why we're there though, given the presence of save-excursion in elpy-buffer--replace-region.

Anyway, my current workaround is to modify elpy--fix-code-with-formatter as follows:

...
(when (equal (point) (point-min))
  (forward-line (1- line))
  (forward-char col))
...

Hm. elpy-buffer--replace-region does not modify the buffer position if the replacement text is the same as before, so that sounds like the right spot. Very nice debugging, thank you! Could you check if the change I pushed fixes things? (It's basically the same code as yours)

@jorgenschaefer yep, that fixes things for me. thanks !

Was this page helpful?
0 / 5 - 0 ratings

Related issues

yitang picture yitang  Â·  4Comments

mfcabrera picture mfcabrera  Â·  6Comments

rakanalh picture rakanalh  Â·  5Comments

chechoRP picture chechoRP  Â·  5Comments

CDitzel picture CDitzel  Â·  5Comments