Add an option for up and down keys to move vertically across "visual rows"

[MikkoMMM]

I've looked for it, but there doesn't seem to be a way to do this easily currently. That is, having the up and down keys behave like a lot of text editors moving the cursor in an imaginary vertical line across the prompt, only straying from that when shorter rows are encountered and at the beginning/end of the document. Right now it seems that they go to the same index on the previous/next internal line, and not the "visual row".

My own hacky implementation is in this file:
https://github.com/MikkoMMM/Clover-Edition/blob/master/inline_editor.py
And even then I encountered problems where rarely but seemingly randomly the cursor would go in the slightly wrong column. That's why for example pressing left and right also manually invoke update_stored_pos in addition to the textf.buffer.on_cursor_position_changed event. And since I wasn't sure about the source of the problem, I also reimplemented the textf.document.cursor_position_col and textf.document.cursor_position_row functions.

So, it's a very messy solution and I'm not sure if it's working perfectly even still. It would be so much better if Python Prompt Toolkit could just offer the option to do it itself, and properly.

[jonathanslenders]

Hi @MikkoMMM,

Do you mean by this: to keep line wrapping into account; double with characters, or both?
I think this would correspond to the Vim "gj" and "gk" key bindings.

Getting the actual implementation right is really not easy. It should also work for full screen applications. I take this as a feature request, and can look into it later on when I have time.

Doing it right requires information from the rendering process (This is in the ptk Window class). It should take the line processors into account (lines can be transformed before rendering, like tabs can be rendered as 2 or 4 spaces for instance). Some information can be taken from WindowRenderInfo. We should also know how to move up when we're at the top of the screen, or down when we're at the bottom. This is not easy when these lines were not rendered.

We should also take performance into account. A lot of effort was spent optimizing the rendering performance in the Window class. We can't make the rendering more complex to track character positions to make this work. The offsets have to be computed when gj or gk are pressed with the information we have.

Dealing with double width characters is also not easy, but should be done.

So, not easy, but something I'd very much like to have as well, and if we do it, I'd like it to be done right.

[MikkoMMM]

Yeah, I was indeed talking about taking line wrapping into account. I don't really use Vim or Emacs myself; my comment had to do more with graphical editors, I suppose. And it sounds like you've already identifed problems that I hadn't thought of, but I did say "properly" so it sounds good to me.