The foot -e command causes some terminal programs to open in a small size when used in client mode #723

Closed
opened 2 months ago by WhereAreWeSeeing · 10 comments

The newly added -e feature works fine for the normal foot terminal, however when used in server/client mode, it always opens up, in my testing, vim in a smaller size. It also did this with ncmpcpp the first two times, but it hasn't again. I am not doing something different, however, as vim is still opening in this shrunken state.

The newly added -e feature works fine for the normal foot terminal, however when used in server/client mode, it always opens up, in my testing, vim in a smaller size. It also did this with ncmpcpp the first two times, but it hasn't again. I am not doing something different, however, as vim is still opening in this shrunken state.
WhereAreWeSeeing changed title from The foot -e command causes terminal programs to open in a small size when used in client mode to The foot -e command causes some terminal programs to open in a small size when used in client mode 2 months ago
Collaborator

What happens if you run: killall -sSIGWINCH vim while it's in the shrunken state..?

What happens if you run: `killall -sSIGWINCH vim` while it's in the shrunken state..?

The program goes to a normal state

The program goes to a normal state

I tested footclient -e vim && killall -sSIGWINCH vim, does not work, but doing it seperately does work for some reason.

I tested footclient -e vim && killall -sSIGWINCH vim, does not work, but doing it seperately does work for some reason.
Collaborator

I tested footclient -e vim && killall -sSIGWINCH vim, does not work, but doing it seperately does work for some reason.

Yeah, I did mean run it seperately (i.e. from a different terminal), but I should have been more specific.

If doing that makes it work, it would imply the problem is something to do with vim recieving (or acting upon) the SIGWINCH signal, which is usually sent to let programs know the window was resized.

I imagine the only difference -e could make is adding a small delay, which might help trigger a race condition. Likewise for the foot vs footclient situation - footclient starts up faster and so may be more prone to race conditions.

See also:

> I tested footclient -e vim && killall -sSIGWINCH vim, does not work, but doing it seperately does work for some reason. Yeah, I did mean run it seperately (i.e. from a different terminal), but I should have been more specific. If doing that makes it work, it would imply the problem is something to do with vim recieving (or acting upon) the `SIGWINCH` signal, which is usually sent to let programs know the window was resized. I imagine the only difference `-e` could make is adding a small delay, which might help trigger a race condition. Likewise for the `foot` vs `footclient` situation - `footclient` starts up faster and so may be more prone to race conditions. See also: * #453 (proposed solution) * #558 * #265 * #195

Ah okay, I just tried that as a workaround. Thanks for your input.

Ah okay, I just tried that as a workaround. Thanks for your input.
Collaborator

I can reproduce the problem by spamming footclient -e ncmpcpp repeatedly from a terminal. Sometimes it pauses at the smaller size for a moment (~0.5s) and then resizes properly and other times it just gets stuck at the smaller size. One of the two seems to happen roughly every 5-6 runs.

Strangely enough, when doing the same thing with just footclient ncmpcpp, the problem doesn't seem to happen at all.

Adding tmux into the mix also seems to make it never happen (with or without -e) which is probably why I've never noticed it before.

I can reproduce the problem by spamming `footclient -e ncmpcpp` repeatedly from a terminal. Sometimes it pauses at the smaller size for a moment (~0.5s) and then resizes properly and other times it just gets stuck at the smaller size. One of the two seems to happen roughly every 5-6 runs. Strangely enough, when doing the same thing with just `footclient ncmpcpp`, the problem doesn't seem to happen at all. Adding tmux into the mix also seems to make it never happen (with or without `-e`) which is probably why I've never noticed it before.
Owner

I don't see how -e have any effect in footclient, since the command line is fully parsed before anything is sent to the foot server (and thus before the application is exec:ed)...

That said, this is a timing dependent issue.

Neovim reproduces close to 10/10 times with footclient for me, with our without -e.

Fwiw, footclient sh -c "sleep 0.1; nvim" seems to work.

I don't see how `-e` have any effect in `footclient`, since the command line is fully parsed **before** anything is sent to the foot server (and thus before the application is exec:ed)... That said, this is a timing dependent issue. Neovim reproduces close to 10/10 times with footclient for me, with our without `-e`. Fwiw, `footclient sh -c "sleep 0.1; nvim"` seems to work.

I use the release version without -e I ran into a similar problem in which I open a foot terminal from a foot terminal, then run nmtui. The nmtui is not draw correctly. Only half of the screen is filled, very similar to the screenshot of OP. Alacritty has the same issue.

// On a side note, would be really appreciate if someone can give me a short direction on how to get foot scrollbar to work. I cannot click/drag it with mouse.

I use the release version without `-e` I ran into a similar problem in which I open a foot terminal from a foot terminal, then run nmtui. The nmtui is not draw correctly. Only half of the screen is filled, very similar to the screenshot of OP. Alacritty has the same issue. // On a side note, would be really appreciate if someone can give me a short direction on how to get foot scrollbar to work. I cannot click/drag it with mouse.
Owner

I use the release version without -e I ran into a similar problem in which I open a foot terminal from a foot terminal, then run nmtui. The nmtui is not draw correctly. Only half of the screen is filled, very similar to the screenshot of OP. Alacritty has the same issue.

If you first start a terminal instance, with a shell, and then launch nmtui from there, then it sounds like a different bug. Still a bug in nmtui, but different from the issue desribed here.

On a side note, would be really appreciate if someone can give me a short direction on how to get foot scrollbar to work. I cannot click/drag it with mouse.

There is no scrollbar in foot. There's a "scrollback position indicator", but it's just a visual cue - it cannot be interacted with. You can disable it, if you don't like it. Or, change the way it looks. For example, you can have it display the position in either percent, or as a line number. And/or have its position fixed near the top of the window.

> I use the release version without -e I ran into a similar problem in which I open a foot terminal from a foot terminal, then run nmtui. The nmtui is not draw correctly. Only half of the screen is filled, very similar to the screenshot of OP. Alacritty has the same issue. If you _first_ start a terminal instance, with a shell, and _then_ launch `nmtui` from there, then it sounds like a different bug. Still a bug in `nmtui`, but different from the issue desribed here. > On a side note, would be really appreciate if someone can give me a short direction on how to get foot scrollbar to work. I cannot click/drag it with mouse. There is no scrollbar in foot. There's a "scrollback position indicator", but it's just a visual cue - it cannot be interacted with. You can disable it, if you don't like it. Or, change the way it looks. For example, you can have it display the position in either percent, or as a line number. And/or have its position fixed near the top of the window.
Owner

I'm going to close this as a duplicate. Any changes to foot, if any, is tracked in #453.

I'm going to close this as a duplicate. Any changes to foot, **if any**, is tracked in https://codeberg.org/dnkl/foot/issues/453.
dnkl closed this issue 2 months ago
dnkl added the
duplicate
label 2 months ago
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.