More general keyboard-selection mode for scrollback #419

Open
opened 7 months ago by Narrat · 2 comments
Narrat commented 7 months ago

Hello.
I've one small question. Would it be feasible to add a more general keyboard-selection mode? In a way termite and wayst did? Having a vi(m)-like way of moving through the scrollback, marking and yanking a selection for example.
I know it kinda can be accomplished with the shortcuts for scrolling back and then using the scrollback search mode for a desired line/selection. And the scrollback search works great, but only on max one line. And if I know what i want to select.

Thanks in advance

Hello. I've one small question. Would it be feasible to add a more general keyboard-selection mode? In a way termite and wayst did? Having a vi(m)-like way of moving through the scrollback, marking and yanking a selection for example. I know it kinda can be accomplished with the shortcuts for scrolling back and then using the scrollback search mode for a desired line/selection. And the scrollback search works great, but only on max one line. And if I know what i want to select. Thanks in advance
Owner

This is one of those features where I'm having difficulties making up my mind.

On one hand, this is something already implemented by e.g. tmux. So why should we re-implement it in foot? Of course, using the same argument, foot shoulnd't have scrollback support at all. But the line has to be drawn somewhere.

Furthermore, supporting this would add a considerable amount of code, making it harder to keep claiming that foot is "lightweight".

On the other hand, I do want foot to be usable with a keyboard only. And selecting text is currently not optimized for keyboard users.

For the time being, I do not intend to implement this. But I'll keep this issue open.

FWIW, what I usually do is start a scrollback search, and then use ctrl+w to extend the selection. However, I just noticed that you cannot extend the selection across the current line using this method. I consider this a bug and intend to fix that.

This is one of those features where I'm having difficulties making up my mind. On one hand, this is something already implemented by e.g. tmux. So why should we re-implement it in foot? Of course, using the same argument, foot shoulnd't have scrollback support at all. But the line has to be drawn somewhere. Furthermore, supporting this would add a considerable amount of code, making it harder to keep claiming that foot is "lightweight". On the _other_ hand, I _do_ want foot to be usable with a keyboard only. And selecting text is currently not optimized for keyboard users. For the time being, I do **not** intend to implement this. But I'll keep this issue open. FWIW, what I usually do is start a scrollback search, and then use <kbd>ctrl</kbd>+<kbd>w</kbd> to extend the selection. However, I just noticed that you cannot extend the selection across the current line using this method. I consider this a bug and intend to fix that.
dnkl added the
enhancement
label 7 months ago

Tjena!

How would you yank some arbitrary selection of command+output using that method without involving tmux or a mouse?

I would argue this is a feature most users expects from any terminal. E.g, I find it weird that its possible to do so with a mouse, but not a keyboard. For me the terminal should be keyboard centric at the very core.

I do understand the lightweight argument, but including basic expected features and still be lightweight is a different thing entirely.

As an example from Alacritty:
By integrating with other applications, rather than reimplementing their functionality, it manages to provide a flexible set of features with high performance.

Alacritty has the ability to freely move the cursor and select text, natively in a keyboard centric manner. As do termite+++. (my dumbass way of trying to argue that its a basic / expected feature for many).

edits: typomania

Tjena! How would you yank some arbitrary selection of command+output using that method without involving tmux or a mouse? I would argue this is *a feature most users expects from any terminal*. E.g, I find it weird that its possible to do so with a mouse, but not a keyboard. *For me* the terminal should be keyboard centric at the very core. I do understand the lightweight argument, but including basic *expected* features and still be lightweight is a different thing entirely. As an example from Alacritty: *By integrating with other applications, rather than reimplementing their functionality, it manages to provide a flexible set of features with high performance.* Alacritty has the ability to freely move the cursor and select text, natively in a keyboard centric manner. As do termite+++. (my dumbass way of trying to argue that its a basic / expected feature for many). edits: typomania
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.