Wayland terminal foot

[spica]

[Moderator note: The following posts were moved from https://forums.gentoo.org/viewtopic.php?t=1169829 to this thread. -- pietinger]

I often see foot recommended as a good Wayland terminal: lightweight, fast, minimal. I tried it myself after reading such posts, and while it is indeed small and efficient, there is one important caveat that I wish I had known earlier.
Foot’s implementation of primary selection (the buffer used for middle-click paste) is extremely literal. The moment you move the pointer by even a single pixel, foot considers it a new selection and immediately overwrites the primary buffer — sometimes with nothing at all.
This means that the usual workflow of „select text in one terminal → middle-click paste in another“ becomes unreliable, because even the tiniest accidental mouse movement can wipe out what you wanted to paste.
For comparison, in GNOME Terminal, Konsole, and other terminals, selection only starts once you actually cross a character cell boundary. That way, small pointer jitter doesn’t destroy your selection buffer.
Yes, you can work around this in foot by declining your habits, e.g. relying exclusively on the clipboard (Ctrl+Shift+C/V), or by using wl-clipboard to sync primary → clipboard, or by forgetting about middle-click paste entirely. But if you are used to the „classic“ X11-style copy-paste workflow, foot’s behavior will likely frustrate you.
So, foot is great as a minimal and performant Wayland terminal, but it’s not for everyone. If primary selection and reliable middle-click paste are important to you, be aware of this limitation before investing time in it.

[Zucca]

I have not encountered that problem with foot.

Code: Select all

$ qlist -vI foot
gui-apps/foot-1.20.2

[spica]

I have not encountered that problem with foot.

That’s the point: if you don’t use primary selection, you won’t notice it.
But if you want to reproduce, just hold the left mouse button in foot and move the pointer by a single pixel -- selection starts immediately and overwrites the buffer.
This is exactly the behavior I described, and it’s not consistent with most other terminals.

[Zucca]

I have not encountered that problem with foot.

That’s the point: if you don’t use primary selection, you won’t notice it.

I do use it.
And now I was able to reproduce the behaviour, but that doesn't really trigger on my setups in real world usage:

• laptop touchpads
• desktop trackball

So yes, I can imagine it being a problem with "regular" mouse.

[logrusx]

I can imagine it being a problem with "regular" mouse.

Weird, I was about to say the same thing about touchpads.

I can imagine it being a problem with regular crappy mouse that reports fake events having had such mouse. One day I soldered new switches in it, taken from two decades old Logitech mouse. Problem solved. But also Wayland was involved in some way, I don't know what. Somehow it was not suppressing those events as good as Xorg does, according to the claims online from the people who experienced this issue.

@spica I bet your mouse reports fake events. If you get more than one click that certainly is the case.

Best Regards,
Georgi

[spica]

@spica I bet your mouse reports fake events

This is not about exotic hardware or „fake mouse events“. It’s about a very common workflow.
In daily work I usually have multiple terminals open:

• one for investigating a Kubernetes cluster,
• another for notes,
• another with an SSH session, code, email, browser etc.

When debugging issues I constantly transfer text between them — and not only between terminals, but also from chats, ticketing systems, email windows, and so on. Sometimes I switch with Alt+Tab, sometimes I just move the pointer to a partially covered window and click on it to bring it to the front, even just to check whether something has updated there.

Yes, there is pointer movement — but that’s exactly the problem.

Typical case:

• copy something in one foot window,
• move the pointer to another window,
• quickly click to focus it (sometimes only to look at the output) and then middle-click to paste.

Since this is done very quickly, it’s basically impossible to stop the pointer perfectly before clicking. There is always at least a tiny 1-pixel motion.

In foot, that tiny motion immediately starts a new selection and overwrites the primary buffer. That’s why the text is lost. Other terminals wait until the pointer crosses a character cell boundary, so they are tolerant of this normal, unavoidable pointer jitter.

[logrusx]

That's not exotic hardware at all. It's a very common problem. I just emerged foot just to test your issue. It happens. Only when I explicitly click. Foot works fine and although starting the selection from the tiniest movement, it needs a selection to be started. That can't happen just by moving the cursor. I don't know what you're doing but your problem is definitely not with foot.

Best Regards,
Georgi

[spica]

That's not exotic hardware at all. It's a very common problem. I just emerged foot just to test your issue. It happens. Only when I explicitly click. Foot works fine and although starting the selection from the tiniest movement, it needs a selection to be started. That can't happen just by moving the cursor. I don't know what you're doing but your problem is definitely not with foot.

Ah, thanks for testing, that’s exactly the subtlety I’m talking about
Yes, it only happens when you click, but in normal workflows that click is unavoidable: bringing a partially covered window to the front or checking updates always involves at least a tiny pointer movement. In foot, even that 1-pixel motion while clicking starts a new selection and overwrites the primary buffer.
So it’s not exotic hardware, and it’s not „just me“ -- it’s the way foot handles selection, which is unlike virtually every other terminal that snaps selection to character cells.

[logrusx]

Yes, it only happens when you click, but in normal workflows that click is unavoidable

No it's not and that's the point. You have either a hardware or software issue, because click is one thing, drag is another. Now if you please stop defending your issue, you might as well solve it. And I'm not saying another word because even in Gentoo Chat this has already become spam.

p.s. it's obvious it's not just you. Maybe you and a few others, but not all, as I and Zucca have already proved. The fact that other terminals don't select graphics but only text just hides your real issue.

Best Regards,
Georgi

[pietinger]

Discussions about foot can be held in this thread by anyone interested.

[Anon-E-moose]

I use foot exclusively for my terminal.

Never had a problem with losing selection, just because of selecting another window, with this caveat
click on menu/top bar or borders, not inside another window as clicking there might indeed reset the selection,
but with a little thought one can comprehend why this is this way.

There are a few selection managers that keep a history, that also would solve the problem.

[Naib]

My terminal of choice is also foot ( foot --server is <3 ) and I do not experience what is being describe here. I don't think this is a foot issue, nor any terminal BUT maybe your wayland compositor (or hardware).

the way I select something to middle-click paste is double-click and FOOT selects upto the delimiters <3. The left mouse and drag is the fallback and the only times I run into an issue are
1. tmux session - need to hold SHIFT as the qualifier
2. testing wlroots sessions Vulkan renderer... Labwc and sway all have odd selection going on so its not quite ready.

Hyprland for instance had a odd behaviour recently

https://forums.gentoo.org/viewtopic-p-8864601.html