FR: Don't change cursor position on lint, and scroll to current line after linting if moved

[redactedscribe]

trafficstars

Is Your Feature Request Related to a Problem? Please Describe.

After linting a file, the line you were on may be moved to another position within the note, for example a footnote ([^42]: ...) may be moved to the the bottom of the file, and you are then left having to search for the same line if you wish to continue writing on it as the cursor / view doesn't follow it.

Describe the Solution You'd Like

If there was a "scroll to / follow current line after lint" type of feature, this could be a solution.

Please include an example where applicable:

If the new line position was within the note's current visible view, then only the cursor would need to follow it (either being placed at the end of the line, or better, at the same position it was within the line before linting).

If the new line position was outside of the note's current visible view, then scrolling to the new position would also be necessary (and perhaps ideally so that the line is vertically centred in middle of the visible view).

Describe Alternatives You've Considered

-

Additional Context

In theory, it sounds like it could be useful. In my case, I use a plugin to add a new footnote via hotkey which appends it to the bottom of the note, scrolling me there, then on lint Linter sorts it to its correct referenced position within the list of footnotes at the bottom ("Move Footnotes to the bottom" rule), and I lose where I was editing. It's just a bit jarring. I could manually trigger linting less often (lint on save), but it's not always certain whether I'm done yet or not.

I can see however it may not be desirable in a different scenario: If creating a footnote just below the its key(?) ([^42]), and then linting with the proposed feature on (+ "Move Footnotes to the bottom"), it may be considered jarring to jump down to the bottom of the note with the footnote upon linting. To avoid that, you'd need to change line before linting, or not enable this feature.

I don't think Linter changes the position of most things as drastically as it does for footnotes, but the proposed feature could still benefit smaller scenarios like: If a header is just below a line with some content, and the rule that ensures spacing surrounds headers is enabled, and the cursor is on some line above this header, linting will cause the position of the cursor to change position to the right by a single character. If the cursor was at the end of the line in that scenario, it would've ended up at the start of the next line.

In short, it would be nice if the cursor position would not change after linting. And if the currently focused line has to be moved, scroll to it after. Hopefully I explained things clearly.

Thanks.

[pjkaufman]

Hey @redactedscribe . Could you verify that this is happening with the version available via BRAT? I think this should already be addressed, but I could be wrong.

[pjkaufman]

Please disregard my previous statement. I thought you were saying keep the cursor around where it was when you linted the file. This sounds more like follow the text your cursor was near when the file gets linted.

[redactedscribe]

I thought you were saying keep the cursor around where it was when you linted the file.

Yes, I didn't mean that.

This sounds more like follow the text your cursor was near when the file gets linted.

Indeed.

[pjkaufman]

That is a pretty big feature to create as it would likely require rewritting how the Linter handles making changes. This is because you would first need to know what the current line's content's are. Then you need to know when something was moved from one location to another. Well, that only really works if the content is the same. If changes are made to that content, you have to know what the original location and new location is or else you cannot properly move the cursor.

Currently the Linter could only do a simple comparison to check for file content that matches the old file content line if the current line does not match. But that might only work 80% of the time depending upon what rules you have enabled. I think it is doable to create, but other than the simple approach, a change like this would likely be a lot of work.

[pjkaufman]

I just wanted to add that comment as a dev since it is best to have that context present to get feedback on strategies to do this or to help whoever may try to tackle this in the future (me or some other dev).