Yes. Would be simple to do even since the refactoring moved from 'add padding' everywhere in the drawing code to just translating everyting in a few central places (translate cairo context and invalidate regions).

I'd be fine with a version that only makes the hotkeys functional (jump to prev/next prompt), without having a graphical representation. Adding those "[" symbols raises a few questions such as whether we'd increase the left padding, or obscure the glyph within the cell, also what color should that mark have, etc. I'm not saying the visual mark is bad, it could just be a second step :)

The "right click -> add/remove mark" menu entries obviously don't make too much sense without visual marks.

The whole concept of remembering input events rather than output ones is really weird to me and I'd probably be in favor of remembering some output event (escape sequence) instead which is closer to iTerm'2 shell integration. Terminal.app's approach of remembering the Enter keypress however definitely has the advantage that no further configuraion is necessary, works even across ssh by default. So I'm fine with that, too.

Where would we store the mark locations? In-memory linked list is feasible only if they're tied to explicit user action (i.e. pressing Enter), otherwise malicious data could oom vte so we'd need to store in file. Text and attr streams don't seem feasible. Row stream is probably okay. However then the mark locations are tied to physical rows, how much would the behavior make sense after a resize/rewrap? (Should marks belong to paragraphs, rows or characters?)

> In-memory linked list is feasible...

Sorry, I meant anything in-memory (linked list is probably not a really good choice).

If we store the marks in one of the streams (maybe even a new 4th stream) and enable the "add/remove mark" menu entries then we need to implement random-access-writes for streams. As far as I recall, it's not implemented currently, but I think (I hope) it could be implemented reasonably easily.

See also bug 769420 (collapsible scrollback).

*** Bug 794128 has been marked as a duplicate of this bug. ***

Just as an FYI, I have implemented the experimental ability to cycle between prompts in the latest version of Tilix (1.7.9). It uses the same technique that Egmont outlined above for Terminal.app, it simply remembers where the enter key is pressed. This does require my patch for implementing a notification on alternate screen mode since you don't want to remember Enter keystrokes in vi, emacs, nano, etc.

Just an FYI if you are interested in following how it goes and implementing the same capability in VTE but obviously with a more integrated approach.

mdcat ("markdown cat") [1] is an example utility that outputs OSC "1337;SetMark" on iTerm2 to add checkpoints where a keyboard shortcut can quickly scroll to.

That is, one vote (one nice use case) for an escape sequence based approach rather than an input event based one.

[1] https://github.com/lunaryorn/mdcat

Continued in https://gitlab.gnome.org/GNOME/vte/-/issues/295 .

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2314.