SwayWM: Trimmed output, not wrapped #1055

Closed
opened 7 months ago by cartesius68 · 15 comments

Current Arch, swaywm 1.7, fish shell (fish, version 3.4.1).

$ foot --version
foot version: 1.12.1 +pgo +ime +graphemes -assertions

Please see the images. In this case I run the qemu and the error message is not properly wrapped in the terminal whereas e.g. gnome-terminal outputs that correctly and wraps the lines.

Image 1: Second output is wrong.
Image 2: Full output.
Image 3: gnome-terminal.

Current Arch, swaywm 1.7, fish shell (fish, version 3.4.1). ``` $ foot --version foot version: 1.12.1 +pgo +ime +graphemes -assertions ``` Please see the images. In this case I run the qemu and the error message is not properly wrapped in the terminal whereas e.g. gnome-terminal outputs that correctly and wraps the lines. Image 1: Second output is wrong. Image 2: Full output. Image 3: gnome-terminal.
cartesius68 changed title from SwayWM: Trimmed output not wrapped to SwayWM: Trimmed output, not wrapped 7 months ago
Owner

Can you provide more details on how to reproduce this? As seen below, it works for me when I'm doing what I think you're doing:

https://codeberg.org/attachments/154f977f-e121-444f-9fbd-8a32fb305d81

  • Have you tested any other terminals?
  • Have you tested other shells?
  • Have you tested fish with default options?
  • Which shell is used in start.sh?
  • It obviously worked the first time; any ideas why it would fail the second time? What's the difference?
Can you provide more details on how to reproduce this? As seen below, it works for me when I'm doing what I _think_ you're doing: ![https://codeberg.org/attachments/154f977f-e121-444f-9fbd-8a32fb305d81](https://codeberg.org/attachments/154f977f-e121-444f-9fbd-8a32fb305d81) * Have you tested any other terminals? * Have you tested other shells? * Have you tested fish with default options? * Which shell is used in `start.sh`? * It obviously worked the first time; any ideas why it would fail the second time? What's the difference?
Owner

Have you tested any other terminals?

If you can , please throw urxvt into the mix

> Have you tested any other terminals? If you can , please throw urxvt into the mix

Will try to investigate this more deeply and answer all the questions.
In the meantime another screenshot.

Problematic seems to be (at least sometimes) this order of actions:

  1. Having a terminal in docked mode.
  2. mod+shift+space to switch to the floating mode.
  3. Running the command in the window which is newly in the floating mode.
    => unwrapped output.

But this is rather a comment, will provide (hopefully) better answers.

Will try to investigate this more deeply and answer all the questions. In the meantime another screenshot. Problematic seems to be (at least sometimes) this order of actions: 1. Having a terminal in docked mode. 2. mod+shift+space to switch to the floating mode. 3. Running the command in the window which is **newly in the floating mode**. => unwrapped output. But this is rather a comment, will provide (hopefully) better answers.
Owner

When you resize the foot window, it'll to a text reflow. This is an operation that isn't spec:ed anywhere, and there are minor differences in how terminals do this. Some don't reflow at all, but simply truncate the text.

That said, foot does reflow, and fwiw, I can't reproduce any issues with fish-3.4.1. Doesn't matter if I start with a long line unwrapped line in a big window, and resize to a smaller size, or start with a wrapped line in a small window and resize to a larger window. Text is reflowed as expected.

When you resize the foot window, it'll to a text reflow. This is an operation that isn't spec:ed anywhere, and there are minor differences in how terminals do this. Some don't reflow at all, but simply truncate the text. That said, foot **does** reflow, and fwiw, I can't reproduce any issues with fish-3.4.1. Doesn't matter if I start with a long line unwrapped line in a big window, and resize to a smaller size, or start with a wrapped line in a small window and resize to a larger window. Text is reflowed as expected.

Thanks for shedding some light into this topic. So in other words, should any text be trimmed at any moment regardless of the previous operation (dock -> float, resize etc.), such an outcome should be considered as a bug, at least in foot? (which is already fantastic anyway!)
Is that correct?

Thanks for shedding some light into this topic. So in other words, should any text be trimmed at any moment regardless of the previous operation (dock -> float, resize etc.), such an outcome should be considered as a bug, at least in foot? (which is already fantastic anyway!) Is that correct?
Owner

It's not that easy. In general, no text should be trimmed. But the bug may just as well be in the shell.

When the terminal is resized, and reflows the text, the cursor position moves. Either to a new absolute line, a new column, or both. Or should move. Not sure all terminals that reflow text also reflows the cursor position.

The issue is usually related to the shell redrawing its prompt; the shell may assume, and rely on the terminal reflowing the cursor, or ignore that and try to figure out where to redraw the prompt all by itself.

There are numerous issues with terminal window resizing and shells redrawing their prompt. Some combos (of terminals and shells) work, other don't.

I suggest you try to strip down your configuration. Test different shells, and most importantly, try with their default configurations first. If that works, start adding back your stuff.

Since I cannot reproduce this, and since this is the first time I've seen anyone report this "glitch", means it's likely to be something in your setup.

It's not that easy. In general, no text should be trimmed. But the bug may just as well be in the shell. When the terminal is resized, and reflows the text, the cursor position moves. Either to a new absolute line, a new column, or both. Or _should_ move. Not sure **all** terminals that reflow text **also** reflows the cursor position. The issue is usually related to the shell redrawing its prompt; the shell may assume, and rely on the terminal reflowing the cursor, or ignore that and try to figure out where to redraw the prompt all by itself. There are numerous issues with terminal window resizing and shells redrawing their prompt. Some combos (of terminals and shells) work, other don't. I suggest you try to strip down your configuration. Test different shells, and most importantly, try with their **default** configurations first. If that works, start adding back your stuff. Since I cannot reproduce this, and since this is the first time I've seen _anyone_ report this "glitch", means it's likely to be something in your setup.

I am facing this same issue. Text gets jumbled on window size change. This doesn't happen in Alacritty and my build of st.

This has also been discussed in st-flexipatch

I am facing this same issue. Text gets jumbled on window size change. This doesn't happen in Alacritty and my build of [st](https://github.com/UtkarshVerma/st-flexipatch). This has also been discussed in [st-flexipatch](https://github.com/bakkeby/st-flexipatch/issues/34)
Owner

As far as I can tell, Alacritty behaves just like in the clip you attached. At least on my machine.

Can you attach a clip of alacrity, where you do exactly the same thing?

As far as I can tell, Alacritty behaves just like in the clip you attached. At least on my machine. Can you attach a clip of alacrity, where you do exactly the same thing?

As far as I can tell, Alacritty behaves just like in the clip you attached. At least on my machine.

Can you attach a clip of alacrity, where you do exactly the same thing?

Sure, here's how Alacritty behaves for me.

> As far as I can tell, Alacritty behaves just like in the clip you attached. At least on my machine. > > Can you attach a clip of alacrity, where you do exactly the same thing? Sure, here's how Alacritty behaves for me.
Owner

Ah, ok, now I see it. Wasn't obvious where I should be looking...

The "issue" is that neofetch doesn't pad with spaces (between the logo and the text), but just moves the cursor.

Foot will compress that when reflowing the text. This is done to reduce "prompt spamming" when reflowing e.g zsh with a secondary prompt on the right-hand side.

Compare with e.g ls output, where text reflow does work as expected.

In other words, in this particular case it's done intentionally; if we change the behavior, we'll break another use case instead.

Ah, ok, now I see it. Wasn't obvious where I should be looking... The "issue" is that neofetch doesn't pad with spaces (between the logo and the text), but just moves the cursor. Foot will compress that when reflowing the text. This is done to reduce "prompt spamming" when reflowing e.g zsh with a secondary prompt on the right-hand side. Compare with e.g `ls` output, where text reflow does work as expected. In other words, in this particular case it's done intentionally; if we change the behavior, we'll break another use case instead.

Oh, that makes sense. Thank you for the quick response and your work on foot.

Oh, that makes sense. Thank you for the quick response and your work on foot.
Owner

Let me take a look at foot's reflow code... While it used to work exactly as described above, I can't find the piece that compresses empty cells. There might be something else going on here.

Let me take a look at foot's reflow code... While it used to work exactly as described above, I can't find the piece that compresses empty cells. There _might_ be something else going on here.
Owner

Ok, so the issue isn't that foot compresses empty cells. We stopped doing that a while ago, as prompts are handled well enough anyway, when the cursor position is reflowed along with the text.

Things break when the text column gets completely pushed over to a separate row. Each line in the logo is at this point followed by empty cells only. Trailing empty cells are skipped when reflowing text, leading to the "compressed" state we see in the clip when the window is enlarged.

This does sound like something we can fix. However, the obvious thing - including the trailing empty cells - broke resizing ls output. Still, we should be able to fix this. Somehow.

Ok, so the issue isn't that foot compresses empty cells. We stopped doing that a while ago, as prompts are handled well enough anyway, when the cursor position is reflowed along with the text. Things break when the text column gets completely pushed over to a separate row. Each line in the logo is at this point followed by empty cells only. Trailing empty cells are skipped when reflowing text, leading to the "compressed" state we see in the clip when the window is enlarged. This does sound like something we can fix. However, the obvious thing - including the trailing empty cells - broke resizing `ls` output. Still, we _should_ be able to fix this. Somehow.
Owner

I have a POC patch that seems to fix it, without breaking something else.

I'll post a PR later. It'll need some testing before it's merged, to ensure there aren't any regressions.

I have a POC patch that seems to fix it, without breaking something else. I'll post a PR later. It'll need some testing before it's merged, to ensure there aren't any regressions.

I have a POC patch that seems to fix it, without breaking something else.

I'll post a PR later. It'll need some testing before it's merged, to ensure there aren't any regressions.

Awesome. I can help you with the testing.

> I have a POC patch that seems to fix it, without breaking something else. > > I'll post a PR later. It'll need some testing before it's merged, to ensure there aren't any regressions. Awesome. I can help you with the testing.
dnkl closed this issue 6 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dnkl/foot#1055
Loading…
There is no content yet.