More general keyboard-selection mode for scrollback

Narrat commented

2021-03-26 14:18:37 +00:00

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

👍 9

dnkl commented

2021-03-27 13:55:22 +00:00

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 2021-03-27 13:55:28 +00:00

dnkl referenced this issue

2021-03-27 13:57:51 +00:00

ctrl+w does not extend selection beyond current line in scrollback search mode #421

dnkl referenced this issue

2021-03-27 20:33:16 +00:00

ctrl+w does not extend selection beyond current line in scrollback search mode #421

RdVLSf commented

2021-09-20 09:48:36 +00:00

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

markstos commented

2022-01-11 02:14:18 +00:00

Contributor

On one hand, this is something already implemented by e.g. tmux. So why should we re-implement it in foot?

Once I moved to Sway from Gnome, I dropped Tmux from my stack for nearly all uses. Instead, I use Sway multiple terminal windows. With Alacritty I can use the keyboard to search through the scrollback buffer and select words and URLs. Keyboard-based search and selection is one feature that keeps me from switching from Alacritty to Foot.

With Sway+Alacritty, the only time I use Tmux any more is when I want to send the same input to multiple terminals in parallel.

Adding this feature to foot would still be "lighter" than foot+tmux together.

> On one hand, this is something already implemented by e.g. tmux. So why should we re-implement it in foot? Once I moved to Sway from Gnome, I dropped Tmux from my stack for nearly all uses. Instead, I use Sway multiple terminal windows. With Alacritty I can use the keyboard to search through the scrollback buffer and select words and URLs. Keyboard-based search and selection is one feature that keeps me from switching from Alacritty to Foot. With Sway+Alacritty, the only time I use Tmux any more is when I want to send the same input to multiple terminals in parallel. Adding this feature to foot would still be "lighter" than foot+tmux together.

RdVLSf commented

2022-01-13 17:35:59 +00:00

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".

Any thoughts on what lightweight actually implies? It's clearly a prioritized requirement, but very vague. Could make it a bit easier to set the scope for the project, and for us to bring some arguments for and against.

> 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". Any thoughts on what *lightweight* actually implies? It's clearly a prioritized requirement, but very vague. Could make it a bit easier to set the scope for the project, and for us to bring some arguments for and against.

tkna commented

2022-01-14 08:28:12 +00:00

Assuming that the ideal alternative would be a less resource-intensive, text-selecting, copy-pest-only plexer, what do you think would be the most useful solution at present?

This question is for anyone reading this. If you can think of any, please let me know.

Assuming that the ideal alternative would be a less resource-intensive, text-selecting, copy-pest-only plexer, what do you think would be the most useful solution at present? This question is for anyone reading this. If you can think of any, please let me know.

dnkl commented

2022-01-14 12:18:39 +00:00

Owner

Any thoughts on what lightweight actually implies?

Since this is a subjective measurement, it's hard to specify it in detail. What it does mean is that for every feature added we need to consider:

Does it add new dependencies, and if so, is it really necessary?
Run-time memory usage. What's the most efficient implementation? If it can't be done without a major increase in memory usage, then the feature may not be suitable for foot. One example is colored undercurlies.
Does it increase code size (almost always yes)? Can we refactor the code to make it smaller, while still being readable, maintainable and efficient (i.e. without increasing e.g memory usage)? I often spend quite a lot of time "optimizing" the larger features I implement. Very often the end result is better (more readable) source code, in addition to a smaller binary size.

In other words, dependencies, memory usage and binary size all matters.

But, a project can also be deemed lightweight (or not so lightweight) in terms of features. Here, one has to judge, on a case-by-case basis, wether a feature "makes sense". Being an expected feature doesn't necessarily auto-qualify it for inclusion, but it's definitely a good start.

I agree that getting text out from the terminal emulator is an expected feature. Do note that there are already a couple of ways to do that (using the keyboard only): the search mode, and the pipe-* actions. They are somewhat limited though, not denying that.

So, how do we improve? I personally prefer search-based solutions over moving a cursor around. That however doesn't mean I won't accept such a feature.

Here's my (own) requirements:

Must be triggerable by a search (i.e. I don't want to enter an alternative mode, and then start a search - I want to be able to start the search with a single key binding)
The new(?) mode must, somehow, be combined with the current search mode. That is, I don't want to add a new mode while keeping the current search mode. Either we extend the current search mode, or we replace it.
While searching, show all currently visible matches, not just the "current" one.

If I were to implement this, I'd probably extend the current search mode. But if someone else wants to have a go at a cursor based mode, raise your hand. I don't want to spend time extending the search mode just to have it replaced a couple of months later.

With Alacritty I can use the keyboard to search through the scrollback buffer and select words and URLs. Keyboard-based search and selection is one feature that keeps me from switching from Alacritty to Foot.

You can already do this in foot. But yeah, the current search mode is limited.

> Any thoughts on what lightweight actually implies? Since this is a subjective measurement, it's hard to specify it in detail. What it _does_ mean is that for every feature added we need to consider: * Does it add new dependencies, and if so, is it really necessary? * Run-time memory usage. What's the most efficient implementation? If it can't be done without a major increase in memory usage, then the feature may not be suitable for foot. One example is colored undercurlies. * Does it increase code size (almost always yes)? Can we refactor the code to make it smaller, while still being readable, maintainable and efficient (i.e. without increasing e.g memory usage)? I often spend quite a lot of time "optimizing" the larger features I implement. Very often the end result is **better** (more readable) source code, in addition to a smaller binary size. In other words, dependencies, memory usage and binary size all matters. But, a project can also be deemed lightweight (or not so lightweight) in terms of features. Here, one has to judge, on a case-by-case basis, wether a feature "makes sense". Being an expected feature doesn't necessarily auto-qualify it for inclusion, but it's definitely a good start. I agree that getting text out from the terminal emulator _is_ an expected feature. Do note that there _are_ already a couple of ways to do that (using the keyboard only): the search mode, and the `pipe-*` actions. They _are_ somewhat limited though, not denying that. So, how do we improve? I personally prefer search-based solutions over moving a cursor around. That however doesn't mean I won't accept such a feature. Here's my (own) requirements: * Must be triggerable by a search (i.e. I don't want to enter an alternative mode, and _then_ start a search - I want to be able to start the search with a single key binding) * The new(?) mode **must**, somehow, be combined with the current search mode. That is, I don't want to add a new mode while keeping the current search mode. Either we extend the current search mode, or we replace it. * While searching, show **all** currently visible matches, not just the "current" one. If I were to implement this, I'd probably extend the current search mode. But if someone else wants to have a go at a cursor based mode, raise your hand. I don't want to spend time extending the search mode just to have it replaced a couple of months later. > With Alacritty I can use the keyboard to search through the scrollback buffer and select words and URLs. Keyboard-based search and selection is one feature that keeps me from switching from Alacritty to Foot. You _can_ already do this in foot. But yeah, the current search mode **is** limited.

tkna commented

2022-01-17 08:06:25 +00:00

I'm sorry if I'm interrupting anything.

On one hand, this is something already implemented by e.g. tmux.

I was able to achieve what I wanted to do with the following. The startup speed is fast and comfortable.

~/.config/tmux/status-off.conf

source-file ~/.config/tmux/tmux.conf
set-option -g status off

~/.config/tmux/tmux.conf

# toggle statusbar
bind-key t set-option status
# scroll
bind -n S-Pageup copy-mode -u
bind -n S-Pagedown send-keys Pagedown

~/.config/sway/config
set $term foot tmux -f ~/.config/tmux/status-off.conf
Set window title to standard format
https://wiki.archlinux.org/title/Tmux#Terminal_emulator_window_titles
Improved startup speed (not recommended. Details are in the next post)
https://wiki.archlinux.org/title/Tmux#Autostart_with_systemd

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

As you said, I think I understand what you mean when you say that it might be better not to add a feature if it will degrade performance.

However, there were some commands that could not be executed on tmux.

$ systemctl --user
Failed to connect to bus: No medium found
$
$ alsamixer
cannot open mixer: Host is down
$
$ speaker-test 

speaker-test 1.2.6

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Playback open error: -112,Host is down
$ pactl list sinks
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
$
$ reboot
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to talk to init daemon.
$

I'm sorry if I'm interrupting anything. > On one hand, this is something already implemented by e.g. tmux. I was able to achieve what I wanted to do with the following. The startup speed is fast and comfortable. * ~/.config/tmux/status-off.conf ``` source-file ~/.config/tmux/tmux.conf set-option -g status off ``` * ~/.config/tmux/tmux.conf ``` # toggle statusbar bind-key t set-option status # scroll bind -n S-Pageup copy-mode -u bind -n S-Pagedown send-keys Pagedown ``` * ~/.config/sway/config `set $term foot tmux -f ~/.config/tmux/status-off.conf` * Set window title to standard format https://wiki.archlinux.org/title/Tmux#Terminal_emulator_window_titles * Improved startup speed (not recommended. Details are in the next post) https://wiki.archlinux.org/title/Tmux#Autostart_with_systemd > Furthermore, supporting this would add a considerable amount of code, making it harder to keep claiming that foot is "lightweight". As you said, I think I understand what you mean when you say that it might be better not to add a feature if it will degrade performance. However, there were some commands that could not be executed on tmux. ``` $ systemctl --user Failed to connect to bus: No medium found $ $ alsamixer cannot open mixer: Host is down $ $ speaker-test speaker-test 1.2.6 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Playback open error: -112,Host is down $ pactl list sinks Connection failure: Connection refused pa_context_connect() failed: Connection refused $ $ reboot Failed to set wall message, ignoring: Interactive authentication required. Failed to reboot system via logind: Interactive authentication required. Failed to talk to init daemon. $ ```

tkna commented

2022-01-17 11:18:10 +00:00

However, there were some commands that could not be executed on tmux.

It seems that the problem was caused by the following settings.

Improved startup speed
https://wiki.archlinux.org/title/Tmux#Autostart_with_systemd

It now works as follows

systemctl disable --now tmux@$USER.service

There seems to be no problem with startup speed. I'm going to use this for a while.

> However, there were some commands that could not be executed on tmux. It seems that the problem was caused by the following settings. > Improved startup speed https://wiki.archlinux.org/title/Tmux#Autostart_with_systemd It now works as follows ``` systemctl disable --now tmux@$USER.service ``` There seems to be no problem with startup speed. I'm going to use this for a while.

markstos commented

2022-01-17 16:18:49 +00:00

Contributor

Regarding Tmux-based solutions, I'm aligned with @ddevault, who commented on the topic elsewhere in the issue tracker:

I use a tiling window manager for multiplexing, not my terminal emulator. I would use at most two or three tmux features, which does not justify the additional bloat. Nor would implementing each feature independently, and wrapping my terminal session in N wrappers, present a compelling alternative.

One possibility is to expand the search mode using concepts and bindings from Emacs movement that people may already know, as the most common of these are used in shells in other places outside of Emacs already. As a long-time Vim user, I'm familiar with many of these already.

Shortcut	Function	Description
C-a or Home	beginning-of-line	Expand to the beginning of line.
C-e or End	end-of-line	Expand to the end of line.
C-f RIGHT*	forward-char	Expand forward a character.
C-b LEFT*	backward-char	Expand back a character.
M-f	forward-word	Expand forward a word.
M-b	backward-word	Expand backward a word.
C-p or UP	backward-line	Expand backward a line.
C-n or DOWN	forward-line	Expand forward a line.
M-v or PgUp	backward-screen	Expand backward a screen.
C-v or PgDn	forward-screen	Expand forward a screen.
M-a	backward-sentence	Expand backward a sentence.
M-e	forward-sentence	Expand forward a sentence.

*Currently the left and right arrow keys are used to move within the search box. It could be considered if they might be useful to expand the selection.

Note that there no commands here to shrink the selection. The only way to shrink the selection is to restart search mode. Maybe that turns out to be a good compromise.

If you to the expand the search selection forward a character, it's already intuitive to just type the next character.

I'm sure for some it will remain more intuitive to move first and then start a selection like Alacritty's Vim-mode works, but starting a selection by searching for a few characters can become intuitive.

Regarding Tmux-based solutions, I'm aligned with @ddevault, who [commented on the topic elsewhere in the issue tracker](https://codeberg.org/dnkl/foot/issues/14#issuecomment-167049): > I use a tiling window manager for multiplexing, not my terminal emulator. I would use at most two or three tmux features, which does not justify the additional bloat. Nor would implementing each feature independently, and wrapping my terminal session in $N$ wrappers, present a compelling alternative. One possibility is to expand the search mode using concepts and bindings from Emacs movement that people may already know, as the most common of these are used in shells in other places outside of Emacs already. As a long-time Vim user, I'm familiar with many of these already. | Shortcut | Function | Description | |--------------|-------------------|----------------------------------------| | C-a or Home | beginning-of-line | Expand to the beginning of line. | | C-e or End | end-of-line | Expand to the end of line. | | C-f RIGHT* | forward-char | Expand forward a character. | | C-b LEFT* | backward-char | Expand back a character. | | M-f | forward-word | Expand forward a word. | | M-b | backward-word | Expand backward a word. | | C-p or UP | backward-line | Expand backward a line. | | C-n or DOWN | forward-line | Expand forward a line. | | M-v or PgUp | backward-screen | Expand backward a screen. | | C-v or PgDn | forward-screen | Expand forward a screen. | | M-a | backward-sentence | Expand backward a sentence. | | M-e | forward-sentence | Expand forward a sentence. | *\*Currently the left and right arrow keys are used to move within the search box. It could be considered if they might be useful to expand the selection.* Note that there no commands here to *shrink* the selection. The only way to shrink the selection is to restart search mode. Maybe that turns out to be a good compromise. If you to the expand the search selection forward a character, it's already intuitive to just type the next character. I'm sure for some it will remain more intuitive to move first and then start a selection like Alacritty's Vim-mode works, but starting a selection by searching for a few characters can become intuitive.

RdVLSf commented

2022-01-20 12:34:06 +00:00

@dnkl Thanks for elaborating :)

Must be triggerable by a search (i.e. I don't want to enter an alternative mode, and then start a search - I want to be able to start the search with a single key binding)

Could the scrollback search be extended to support regexp easily? Some sort search aliases (by regexp) in the config file that is accessible in the scrollback search mode.

The ability to simply capture n previous lines would also be a decent compromise to be honest (without the long hand pipe-visible pattern). Just something fast that gives me a selection I can work with :P

@dnkl Thanks for elaborating :) > * Must be triggerable by a search (i.e. I don't want to enter an alternative mode, and _then_ start a search - I want to be able to start the search with a single key binding) Could the *scrollback search* be extended to support regexp *easily*? Some sort *search aliases (by regexp)* in the config file that is accessible in the scrollback search mode. The ability to simply capture *n* previous lines would also be a decent compromise to be honest (without the long hand pipe-visible pattern). Just something *fast* that gives me a selection I can work with :P

markstos commented

2022-01-21 14:59:03 +00:00

Contributor

Some sort search aliases (by regexp) in the config file that is accessible in the scrollback search mode.

I think the URL hinting mode is the place where it makes more sense to expand regex support.

For example, when hinting text for copying, it would be useful to me if in addition to URLS, all file paths and Git SHAs were hinted as well.

> Some sort search aliases (by regexp) in the config file that is accessible in the scrollback search mode. I think the URL hinting mode is the place where it makes more sense to expand regex support. For example, when hinting text for copying, it would be useful to me if in addition to URLS, all file paths and Git SHAs were hinted as well.

dnkl commented

2022-02-02 20:53:50 +00:00

Owner

@markstos @RdVLSf thanks for all the input. There are some nice ideas here. Some of them are things I've toyed with in the back of my mind; nice to see someone else coming up with the same ideas! Other ideas are new, which is great to see!

I'll revisit this issue after fcft-3 and foot-1.11 has been released.

@markstos @RdVLSf thanks for all the input. There are some nice ideas here. Some of them are things I've toyed with in the back of my mind; nice to see someone else coming up with the same ideas! Other ideas are new, which is great to see! I'll revisit this issue after fcft-3 and foot-1.11 has been released.

👍 2

Barbaross commented

2022-05-28 00:07:31 +00:00

Hi there @dnkl

It looks like fcft-3 and foot-1.11 have been released for some time now. Do you have any further thoughts on such a feature? FWIW some type of keyboard selection mode is the last major feature I would love to see in foot.

Hi there @dnkl It looks like fcft-3 and foot-1.11 have been released for some time now. Do you have any further thoughts on such a feature? FWIW some type of keyboard selection mode is the last major feature I would love to see in foot.

dnkl commented

2022-05-28 10:04:13 +00:00

Owner

1.12 brought "highlight-all-matches", and also laid the foundation for further work on the scrollback search mode.

I've been busy (still is) with real life, but the next step is adding key bindings for expanding (and hopefully shrinking) the selection in different ways.

1.12 brought "highlight-all-matches", and also laid the foundation for further work on the scrollback search mode. I've been busy (still is) with real life, but the next step is adding key bindings for expanding (and hopefully shrinking) the selection in different ways.

👍 3

dnkl referenced this issue

2022-06-25 07:50:14 +00:00

Add new key-binding: "extend-to-end-line" #1095

dnkl referenced this issue

2022-09-11 08:23:23 +00:00

Vi-style control #1168

mildred referenced this issue

2023-01-18 09:20:31 +00:00

Better scrollback by piping it to alternate programs #1264

dnkl referenced this issue

2023-05-26 08:42:03 +00:00

Select-Text like URxvt or Alacritty #1356

dnkl referenced this issue

2023-07-19 04:51:42 +00:00

missing vi copy mode or alternative #1414

Ghost commented

2023-08-30 21:30:34 +00:00

1.12 brought "highlight-all-matches", and also laid the foundation for further work on the scrollback search mode.

Is highlight-all-matches a command you can bind? I'm not finding it in the manpage.

> 1.12 brought "highlight-all-matches", and also laid the foundation for further work on the scrollback search mode. Is highlight-all-matches a command you can bind? I'm not finding it in the manpage.

craigbarnes commented

2023-08-31 02:57:20 +00:00

Collaborator

Is highlight-all-matches a command you can bind? I'm not finding it in the manpage.

@rcorre No, I think it was just a way of referring to the improvements made in #1026. As mentioned in the 1.12.0 changelog entry, "scrollback search mode now highlights all matches".

> Is highlight-all-matches a command you can bind? I'm not finding it in the manpage. @rcorre No, I think it was just a way of referring to the improvements made in #1026. As mentioned in the [1.12.0 changelog entry](https://codeberg.org/dnkl/foot/src/commit/4f3f61445799827aa88f69b11ebe2b181a58ca36/CHANGELOG.md#user-content-1-12-0), "scrollback search mode now highlights all matches".

dnkl referenced this issue

2023-09-20 13:22:24 +00:00

Feature Request: selection using keyboard #1488