New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`evil-forward-section-begin` misbehaves #197

Closed
Ambrevar opened this Issue Jun 13, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@Ambrevar
Contributor

Ambrevar commented Jun 13, 2017

This bug is linked with evil-mode, so I first opened an issue there:
emacs-evil/evil#844

foo

# header 0

foo

# header 1

foo

# header 2

foo

# header 3

foo

Pressing ]] on header 1 moves the point at the end of the body of header 2. Same with header 2 and 3.
Only the last 3 headers are concerned. The rest is fine.

[[ (evil-backward-section-begin) does not display the issue.

The Evil maintainer suggests that Markdown-mode might be to blame.

@jrblevin

This comment has been minimized.

Show comment
Hide comment
@jrblevin

jrblevin Jun 13, 2017

Owner

Let me describe the Markdown mode defun movement functions. That might clear things up?

If the point is in the whitespace between the second "foo" and "# header 1", then you are at the end of the "# header 0" defun. The docstring for end-of-defun says "Move forward to next end of defun." So, the next end of defun is the end of the "# header 1" defun.

Markdown mode's defun functions behave like those in c-mode and emacs-lisp-mode, for example. When the point is at whitespace after a function, it is considered end of defun and end-of-defun moves over the following function.

So, with your test document if you move to the beginning of the buffer and press C-M-e repeatedly, Markdown mode moves the point just after "foo" each time. So, it's consistent in markdown-mode by itself (not different behavior for the last three sections). It seems like perhaps an inconsistency in evil mode?

Edit: I meant to write C-M-e.

Owner

jrblevin commented Jun 13, 2017

Let me describe the Markdown mode defun movement functions. That might clear things up?

If the point is in the whitespace between the second "foo" and "# header 1", then you are at the end of the "# header 0" defun. The docstring for end-of-defun says "Move forward to next end of defun." So, the next end of defun is the end of the "# header 1" defun.

Markdown mode's defun functions behave like those in c-mode and emacs-lisp-mode, for example. When the point is at whitespace after a function, it is considered end of defun and end-of-defun moves over the following function.

So, with your test document if you move to the beginning of the buffer and press C-M-e repeatedly, Markdown mode moves the point just after "foo" each time. So, it's consistent in markdown-mode by itself (not different behavior for the last three sections). It seems like perhaps an inconsistency in evil mode?

Edit: I meant to write C-M-e.

@Ambrevar

This comment has been minimized.

Show comment
Hide comment
@Ambrevar

Ambrevar Jun 13, 2017

Contributor

Let me quote @wasamasa:

This is the result of another oddity with thingatpt.el. Movement for ]] is done in terms of evil-defun (which is like a regular defun except that movement signals whether it's been successful or not) and generally done with evil-forward-beginning. In the case you describe it first goes to the end of the evil-defun at point, then moves to the end of the next one with forward-thing, then back to the beginning of the next one with beginning-of-thing. The last step fails for your test data, to reproduce go to the last newline and evaluate M-: (bounds-of-thing-at-point 'evil-defun).

I'm not sure whether evil can do anything about this, other than trying to move back until it's possible to navigate by a defun. This might be the fault of markdown-mode if their functions for beginning-of-defun and end-of-defun are suboptimal. Can you reproduce this problem with other modes defining those?

The thing is, other modes are fine.

Contributor

Ambrevar commented Jun 13, 2017

Let me quote @wasamasa:

This is the result of another oddity with thingatpt.el. Movement for ]] is done in terms of evil-defun (which is like a regular defun except that movement signals whether it's been successful or not) and generally done with evil-forward-beginning. In the case you describe it first goes to the end of the evil-defun at point, then moves to the end of the next one with forward-thing, then back to the beginning of the next one with beginning-of-thing. The last step fails for your test data, to reproduce go to the last newline and evaluate M-: (bounds-of-thing-at-point 'evil-defun).

I'm not sure whether evil can do anything about this, other than trying to move back until it's possible to navigate by a defun. This might be the fault of markdown-mode if their functions for beginning-of-defun and end-of-defun are suboptimal. Can you reproduce this problem with other modes defining those?

The thing is, other modes are fine.

@jrblevin

This comment has been minimized.

Show comment
Hide comment
@jrblevin

jrblevin Jun 13, 2017

Owner

Thanks. I did read the original issue, but after re-reading it more carefully I now understand that the issue is when the point is at the end of the buffer and I can reproduce it (independently of evil-mode).

Owner

jrblevin commented Jun 13, 2017

Thanks. I did read the original issue, but after re-reading it more carefully I now understand that the issue is when the point is at the end of the buffer and I can reproduce it (independently of evil-mode).

@jrblevin jrblevin added the bug label Jun 13, 2017

jrblevin added a commit that referenced this issue Jun 13, 2017

@jrblevin jrblevin closed this in c458a96 Jun 13, 2017

@jrblevin

This comment has been minimized.

Show comment
Hide comment
@jrblevin

jrblevin Jun 13, 2017

Owner

I think that should fix your issue, but please let me know if not.

Owner

jrblevin commented Jun 13, 2017

I think that should fix your issue, but please let me know if not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment