dominikh / go-mode.el

Emacs mode for the Go programming language
BSD 3-Clause "New" or "Revised" License
1.38k stars 211 forks source link

go-beginning-of-defun breaks some evil mode features #186

Open bomgar opened 7 years ago

bomgar commented 7 years ago

Evil mode uses go-beginning-of-defun for some replacements.

I opened a Bug there and it seems the method moves the point to a strange location if called outside of a function definition.

https://github.com/emacs-evil/evil/issues/807#issuecomment-293056007

The cursor is moved to the end of the line which does not seem right.

psanford commented 4 years ago

Looks like the issue was fixed in evil mode so I'm going to close this.

niontrix commented 1 year ago

Sorry to open this again, but I still have the same issue. The usage of save-excursion in evil did not fix it for me. Also it was mentioned in emacs-evil/evil#807(comment) that the usage of end-of-line in go-beginning-of-defun is most likely causing this behaviour. rust-mode has a similar function which uses beginning-of-line instead of end-of-line and does not have this issue. What prevents us from using beginning-of-line instead of end-of-line? I switched it on my system and haven't noticed any detrimental effects so far. I also ran the tests and couldn't see different results than before. Could someone please explain as to why end-of-line needs to be used (which is a bit counter-intuitive inside a beginning-of-defun function)?

dominikh commented 1 year ago

Could someone please explain as to why end-of-line needs to be used

Not at the moment, no. I wrote that code 8 years ago. I'll look into what's happening here.

dominikh commented 1 year ago

The logic behind that code is as follows:

We search backwards for the beginning of a function, using go-func-meth-regexp, which expects to see a full first line of a function or method declaration. If point is already somewhere on the first line, then the regexp wouldn't match unless we move the pointer to the end of the line.

We only do this if we're not at the beginning of line ((unless (bolp))), because if we're already at the beginning of a function, then another call to go-beginning-of-defun should go to the beginning of the previous function.¹

However, I do acknowledge that things aren't working correctly. I can reproduce the ci" issue, and go-end-of-defun, which relies on go-beginning-of-defun, has some bugs of its own, too. I'll see about improving/rewriting these functions.

¹: it's possible that this logic should be handled by beginning-of-defun-raw instead. I'll have to look into that.

niontrix commented 1 year ago

Thanks, that would be great! My Elisp skills are unfortunately not very high, but if I can help you somehow let me know.

dominikh commented 1 year ago

f03998154bbed359f1912284a49b598fef074406 addresses the ci" issue for me. Hopefully everything else works, too.

karta0807913 commented 4 months ago

hello @dominikh, sorry for following the old issue. I think current implementation is still confusing the evil mode.

For example, if you ci" on the import declaration or constants on the top of the file (out of function). The function go-beginning-of-defun will still jump back to the end of the line. It still makes evil-mode confused.

I suggest we can test if the current point is after the original point. That would help a lot :) (I can open a PR if you need my help)

gif-record bZhrjkpOTG

dominikh commented 4 months ago

I cannot reproduce that error. In a file similar to yours, using ci" while on the import path works as expected. I also cannot reproduce beginning-of-defun at that point moving point forward.

karta0807913 commented 4 months ago

sorry, I used the old stable version (v1.6.0). The problem was solved after I updated it to the latest one.

Thank you for your reply!