Skip to content
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

]] misbehaves from the last three markdown headers #844

Closed
Ambrevar opened this issue Jun 3, 2017 · 3 comments
Closed

]] misbehaves from the last three markdown headers #844

Ambrevar opened this issue Jun 3, 2017 · 3 comments

Comments

@Ambrevar
Copy link

Ambrevar commented Jun 3, 2017

Issue type

  • Bug report

Environment

Emacs version: GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.10) of 2017-04-22
Operating System: Arch Linux
Evil version: 1.2.12
Evil installation type: MELPA
Graphical/Terminal: Graphical
Terminal multiplexer: No.

Reproduction steps

  • Start Emacs on the following buffer in Markdown mode (2.2).
foo

# header 0

foo

# header 1

foo

# header 2

foo

# header 3

foo

Expected behavior

Pressing ]] should place the point on the first '#' of the next markdown header.

Actual behavior

Pressing ]] when the point is after the third-to-last section (header 1 in the example), the point is moved beyond its expected location.

@wasamasa
Copy link
Member

wasamasa commented Jun 4, 2017

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?

@Ambrevar
Copy link
Author

Ambrevar commented Jun 4, 2017

Markdown mode is the only mode where I've noticed this behaviour.
I can think of C mode which has its own beginning-of-defun and end-of-defun, but it does not suffer from this issue.

Should I open an issue for Markdown mode?

@wasamasa
Copy link
Member

Thanks for opening the issue with markdown-mode, I've checked out the latest version and no longer get that bug! Feel free to reopen if you still do.

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

No branches or pull requests

2 participants