When editor width changes, keep the cursor in view

[HeyMyian]

When I open another document in the viewer, on my tiny screen the editors become two narrow columns, resulting in new line breaks and an overall "taller" document. This reflow causes the cursor (i.e. my editing position) to scroll out of view. Because the editor has lost focus to other parts of the program, I also cannot easily jump back to the position by moving the cursor with arrow keys.

I suggest that if the editor width changes, the view remains where the cursor last was.

(P.S. It just occured to me the keyboard shortcut Alt + 2 or clicking on the scroll bar refocuses the editor too, which then lets me jump to the last position with the arrow keys. But maybe it could do that automatically anyway?)

[vkbo]

This should be possible to solve. I'll look into it.

[HeyMyian]

Related to cursor issues: When opening the search window, the editor view jumps so that the cursor position (which doesn't change) is one line below the bottom of the editor, out of view. Let me know if you need more description than that. I think(?) this is new behavior since version 2.

[vkbo]

No, this is not new. The search box has always expanded the top margin in order to not cover any text.

I guess this is mostly an issue for when you're writing at the end of the page with the cursor at the end of the text, and you have turned off all the features that keep the cursor further up the page. The issue is avoided by letting the editor pad the bottom of the page with empty lines and allow the "typewriter scrolling" feature that keeps the cursor at a fixed vertical position and scrolls the page instead.

[vkbo]

In any case, there is an ensureCursorVisible() feature that can be used in both these cases. It should be easy enough to add, although it makes sense to only trigger it when the cursor was visible before the action, otherwise it may cause jarring jumps away from a place the user may have deliberately scrolled to.

This is primarily why there aren't any such automatic scrolling actions in the first place. It's difficult to guess whether the user intended scrolling to a different place than where the cursor is parked or not. Just because the intention is obvious for the user or a human observer, it may not be so obvious to implement in code.

[vkbo]

Ok, this one is a bit tricky, so I'm gonna add it to a different release. It is not really suitable for a patch release since it requires adding a new approach to cursor visibility.

[tmarplatt]

re: cursor position on search, I'm glad to find an open related issue for something that is part cosmetics and part UX.

Right now, when you search text and the editor finds a match further below, the editor will always place the highlighted match at the bottom of the editor's viewport. The user is presented with an obstructed view of the matched text context, and is forced to manually scroll down to reveal more text.

I believe it would be a sensible change to, if text flow and related preferences allow for it, scroll the viewport a few lines beyond the current match. At a minimum, scroll until the end of the current paragraph is in view (or, if the paragraph is larger than the viewport, until the match is at the top).

The idea being that the user can immediately read the entire context of a match, which is often important to grok at a glance when doing specific searches. This allows to immediately keep searching if the current match is not satisfactory, without distractions.

[vkbo]

I agree. The current scroll-into-view behaviour is the way the Qt framework implements it. I don't know why they made it only scroll to the bottom. I find that annoying as well.

[vkbo]

Due to the changes in 2.2 where the text editor becomes a true plain text editor as defined by the Qt framework, the scroll behaviour is changing. The "Scroll past end of document" setting in Preferences will now also trigger a centre on scroll feature. These are unfortunately coupled in the Qt framework, which means the ensureCursorVisible function will also centre the cursor in the editor (vertically).

In some cases that is fine. The search now does this, but the jump is a bit jarring when used to ensure cursor visibility when the editor width changes – like when toggling Focus Mode (#1478), and when the document viewer is opened or closed. I've implemented an alternate ensureCursorVisible function that doesn't centre the cursor, which is used for this.

So, the search scrolling solves itself, and the other two scenarios are handled by the new ensureCursorVisibleNoCentre function added in #1608.

They'll be part of the 2.2 RC 1 release that I'll make soon. So it would be nice if you could both test that it works as expected.