After split, size isn't properly reported to vim

[Sparhawk]

Steps to reproduce
1) In a new tab, open vim with some text in it.
2) Create a horizontal split.

Expected
* vim should resize to the size of the pane.

Observed
* vim is much narrower than the pane's width. See attached screenshot.

Additional information
Switching to the vim pane does nothing, but sending a command to vim (e.g. moving the cursor down) refreshes it correctly.

FWIW, mutt deals with splits perfectly now. In the gtk2 version of terminator, it never worked, so that is a fantastic improvement.

terminator-gtk3-bzr r1657-1
Up-to-date Arch Linux
KDE Plasma 5.8.4

[Egmont Koblinger (egmont-gmail)]

I cannot reproduce this one.

I suspect that for whatever reason two (or more) consecutive resize events are sent to your vim in a very short time, and it fails to handle them correctly.

Could you please try this: instead of vim, execute these:

$ zsh
% trap 'stty size' WINCH

and then split. What is printed? Also, is there anything additional printed when you switch pane, or start typing into this zsh?

[Stephen Boddy (stephen-j-boddy)]

Ooooh. That's a useful command :-)

I get two different results depending on if I split horizontally or vertically. Vertically (like Sparhawk's screenshot) the terminal seems to get a clear, and I only see the one set of correct y,x values, but I suspect there are two, but one is disappearing due to the clearing. If I split horizontally, I see two sets, with the x value being consistent. The 1st y value is always 1, followed by the correct value.

[Sparhawk (sparhawkthesecond)]

@egmont-gmail Oh, perhaps I should have mentioned that I was already using zsh. I'm not sure if this is important; I tried `bash`, then vim, but got the same results.

Anyway, following your instructions, after the split, I get `49 104`, and that is all. This second number is correct, and is indeed the width of the pane. Nothing additional is printed on switching or typing in that pane.

@stephen-j-boddy Firstly, I think I'm using "vertically" and "horizontally" the other way around to you. I probably switch myself, depending on whether I'm thinking about the direction of the split between the windows, or the relationship between the panes. I'll follow your wording here. So splitting horizontally, I also see two sets of numbers. In my case they are the following.

3 210
24 210

In addition, I've noticed that the split doesn't just make the vim pane too narrow, it also repeats the last character on each line (see the screenshot). The pane is hence 12 characters wide, plus 1 repeated character.

I also see some slightly erratic behaviour on multiple vertical splits, which may be diagnostic.

1) Launch vim, then split it once -> observe a 12+1 pane.
2) Move to the vim window, type a command to fix it, then split this once again -> the pane is correct!
3) Move to the vim window, then split this for the third time -> observe a 12+1 pane.

This is 100% reproducible. Oddly enough, if I type a command in vim in (3), then the pane is again correct.

Also, mostly similar to the initial report, I can start from a fresh terminal, launch vim, *but then type a command in*, and split it once. I then get a brief flash of a 12+1 pane, but then it fixes itself. The duration of the flash is 0.1–0.5 seconds, but it's not consistent.

The final point is possibly related. I create a new window, and totally fill it with text somehow (just from stdout). I then split it vertically. I can then see that the text has shifted up a little. Instead of filling the pane, it's a few lines up from the bottom. See screenshot. Similarly, if I print 6 lines with `echo '1\n2\n3\n4\n5\n6'`, then vertically split, the prompt moves up, but very oddly truncates lines 1, 4, 5, 6; leaving 2 and 3. See next screenshot.

[Sparhawk (sparhawkthesecond)]

Before split, the pane contained:

 echo '1\n2\n3\n4\n5\n6'
1
2
3
4
5
6


After the split, the pane contains:

2
3


[Egmont Koblinger (egmont-gmail)]

The wording of horizontal vs. vertical is discussed in bug 1525594 :)

---

The trap command is indeed a useful one. It also used to work in bash <= 4.2, but bash-4.3 made a stupid change and executing the trap is not immediate, it is now deferred until the next keyboard activity or some similar action.

If the window is resized to something extremely weird (like only 3 characters narrow) then it might be a good idea to redirect its output, like «trap 'stty size >> /tmp/size' WINCH» to make sure it's not overwritten on the screen. It might also be useful to record the timestamp as well, e.g.:

  trap '{ date +%T.%N; stty size; echo } >> /tmp/size' WINCH

Watch out that «stty size» reports the two dimensions in the unexpected order (y x).

---

There are some cases where unfortunately it's inevitable that there are two consecutive resize events. See e.g. https://bugzilla.gnome.org/show_bug.cgi?id=731137. As such, it's definitely a bug in vim if it doesn't repaint its screen according to the last screen size it receives. This should be reported to vim as a bug.

It's sure easy for app developers not to prepare for the scenario of another SIGWINCH arriving while the first one is still being handled, but it's possible to implement it without a race condition. Probably the cleanest approach is if the main select() call (where the app stays while waiting for user event) is actually a pselect() that atomically unblocks WINCH for its duration, and atomically blocks again when left for whatever reason. WINCH's handler could flip a boolean, or after the pselect() call it could query the window size and compare with the previous value, and repaint the screen if necessary. Another possible well-known approach is the self-pipe trick where the signal handler writes a byte to a pipe, and the main select() call listens on its reading end.

---

It this current situation though I can see no theoretical reason why terminator needs to send two consecutive resize events, and as so, probably its code could be fixed not to do so.

---

If a window (especially with a shell prompt) is made extremely narrow, weird things happen (e.g. with the "1 2 3 4 5 6" output). This is I'm afraid inevitable, especially since VTE rewraps its contents (including the shell prompt), and unaware of this, zsh also redraws its prompt. You can probably see "1" and "4 5 6" getting lost and only "2 3" remaning on the screen if you resize manually to such an extremely narrow window.

---

I'm getting quite confused around the horizontal vs. vertical terminology, and stty's stupid output order. Could you please confirm that in the originally reported scenario, when the two panes are next to each other, the intermittent size is extremely narrow, and as tall as all the terminal before and after the action?

[Sparhawk (sparhawkthesecond)]

Haha… thanks for the link with the vertical/horizontal wording. I actually found that quite interesting!

Here is the output of the following command:
    trap '{ date +%T.%N; stty size; echo } >> /tmp/size' WINCH

I split the window once ("vertically", i.e. the windows are left and right), then closed the right side. I then repeated this.

    20:22:24.234716256
    49 1

    20:22:24.244638841
    49 104

    20:22:42.180421768
    49 210

    20:22:45.345583616
    49 1

    20:22:53.537098429
    49 210

I only did it once, and as you can see, the first time x went rapidly from 1 to 104, whereas the second time, it was stuck on 1 semi-permanently.

Regarding the "1 2 3 4 5 6" issue, I *think* we're on the same page, but just in case, I'll clarify. Here, I'm not manually (intentionally) making the window narrow; the final width from the screenshot is as narrow as I go. I'm presuming that narrowness is a side-effect of the main bug we're talking about.

Regarding your confusion… Sorry, I'm a little confused too! Are you asking about the very original post, and the attachment "Screenshot showing vim's incorrect resizing"? Tell me if I misinterpret your question, but yes, the intermittent width of vim is 12+1 characters, until I send it a command, where it fills the width again as expected. The height of the window is never affected, as far as I can tell.

[Egmont Koblinger (egmont-gmail)]

We're all confused :)

So... that "stuck on 1 semi-permanently" at 20:22:45 really worries me.

How did it visually look then? Was it half of the screen wide (104-ish characters)? Can you reproduce this? Can you manually execute "stty size" there, and what does it print then?

If this really happens, it can mean either of two things:

- zsh also does not handle perfectly two resize events in short succession,

- or vte fails to send the second resize.

I would be quite surprised if it turned out to be a vte bug, but of course it's possible. Could you please do this for us:

- download vte (ftp://ftp.gnome.org/pub/GNOME/sources/vte/0.46/ or similar version)

- uncompress; ./configure --enable-debug (if necessary: install all the missing dependencies that you encounter on your way and repeat); make

- LD_PRELOAD=/the/path/to/vte/src/.libs/libvte-2.91.so.0 VTE_DEBUG=resize terminator

This should spit out some debugging info, unfortunately mixed for the two vtes of the two panes, but it should be a reliable source of what vte believes its size is.

(I'm not sure we're heading in the right direction... we'll see.)

[Sparhawk (sparhawkthesecond)]

I can't seem to reproduce the "stuck on 1 semi-permanently" part any more! I guess it could have been a combination of commands earlier. I tried several permutations, but none could produce that result now.

When I did get that "1" before, it looked… normal. Possibly only because it was an empty screen with a single prompt, so there wasn't really enough text there to see if there was a change.

I also tried to get the trap information when I *knew* that the window was bugging out, i.e. when vim was running. However, vim being open appears to suppress the trap output.

I did the vte debugging as suggested. I then recreated the original bug (open vim with text, split window and observe a 12+1 width window). Here is the debugging info after the split was made.
============================================================
Setting PTY size to 80x24.
Setting PTY size to 80x24.
Setting PTY size to 80x24.
Setting PTY size to 210x51.
Resizing normal screen_
Old insert_delta=0 scroll_delta=0.000000
     cursor (absolute) row=0 col=0
     cursor_saved (relative to insert_delta) row=0 col=0
Everything fits without scrollbars
New insert_delta=0 scroll_delta=0.000000
     cursor (absolute) row=0 col=0
     cursor_saved (relative to insert_delta) row=0 col=0

Setting PTY size to 1x51.
Resizing normal screen_
Old insert_delta=0 scroll_delta=0.000000
     cursor (absolute) row=1 col=0
     cursor_saved (relative to insert_delta) row=1 col=0
Scroll to bottom
New insert_delta=208 scroll_delta=208.000000
     cursor (absolute) row=209 col=0
     cursor_saved (relative to insert_delta) row=1 col=0

Resizing alternate screen_
Old insert_delta=359 scroll_delta=359.000000
     cursor (absolute) row=406 col=169
     cursor_saved (relative to insert_delta) row=0 col=0
Everything fits without scrollbars
New insert_delta=359 scroll_delta=359.000000
     cursor (absolute) row=406 col=169
     cursor_saved (relative to insert_delta) row=0 col=0

Setting PTY size to 104x51.
Resizing normal screen_
Old insert_delta=0 scroll_delta=0.000000
     cursor (absolute) row=0 col=0
     cursor_saved (relative to insert_delta) row=0 col=0
Everything fits without scrollbars
New insert_delta=0 scroll_delta=0.000000
     cursor (absolute) row=0 col=0
     cursor_saved (relative to insert_delta) row=0 col=0

Setting PTY size to 104x51.
Resizing normal screen_
Old insert_delta=208 scroll_delta=208.000000
     cursor (absolute) row=209 col=0
     cursor_saved (relative to insert_delta) row=1 col=0
Scroll to bottom
New insert_delta=2 scroll_delta=2.000000
     cursor (absolute) row=3 col=0
     cursor_saved (relative to insert_delta) row=1 col=0

Resizing alternate screen_
Old insert_delta=359 scroll_delta=359.000000
     cursor (absolute) row=406 col=169
     cursor_saved (relative to insert_delta) row=0 col=0
Everything fits without scrollbars
New insert_delta=359 scroll_delta=359.000000
     cursor (absolute) row=406 col=169
     cursor_saved (relative to insert_delta) row=0 col=0
============================================================
At the risk of complicating the issue, when I unhide terminator, I get the fol...

[Sparhawk (sparhawkthesecond)]

I'm not sure if this was implied by our discussion, but I just tried splitting a window with vim the other way… um… that is… um… "horizontally". I get a similar problem.

[Sparhawk (sparhawkthesecond)]

Hello, I appreciate that it's a busy time of the year, and you probably have other, more pressing tasks, but I was just wondering if there were any more information I could provide to you on this bug? Alternatively, is there any possible workaround? Generally I split windows when I have some interesting information in one pane, and want to do something with that information in a new pane. With this bug, that information often goes missing, so I'm finding myself not splitting at all much nowadays. (I'm even tempted to revert to terminator-gtk2, which I'd prefer not to do!) It's not just a problem with vim, but standard out is truncated too.

Also, since Egmont couldn't reproduce this earlier, I just tried deleting ~/.config/terminator/config. Even with a fresh profile, I can still reproduce this bug.

[Stephen Boddy (stephen-j-boddy)]

OK, so it is not completely fixed, but it's better than it was. I think:
http://bazaar.launchpad.net/~gnome-terminator/terminator/gtk3/revision/1720
Has changed the timing of the set-pos, making the first set of numbers close to the final number, instead of being way out. Then there's a following minor nudge that causes a single increment of the x count. That minor nudge is incorrect, because if I then double-click the splitter to balance them, they snap back to where they opened initially. SO I just need to track down that second nudge.

[Stephen Boddy (stephen-j-boddy)]

Oh, and I con reproduce the double set of numbers in both directions. You just have to fine tune the size of the window *just right*, so that the second nudge expands the first pane just enough to fit another character.

[Stephen Boddy (stephen-j-boddy)]

Committed revision 1722.

And I just found the source of the nudge! :-)

As far as I can tell this will not stop the double resize values being triggered, but they will both be the correct value now so you won't see weirdness with vim et al. Test it and let me know, and I'll set this to Fixed.

[Sparhawk (sparhawkthesecond)]

Gosh, that is soooooo much better! Thank you! As far as I can tell, vim is perfect now! However, I still see some other minor artifacts. If I just have "normal" zsh output, the whole output shifts up by two lines. e.g. Print four lines.

$ echo '1\n2\n3\n4'
1
2
3
4

Split vertically, and see the following.

2
3
4

Scroll up and see the following.

$ echo '1\n2\n3\n4'

1
2
3
4

I tried the `trap 'stty size' WINCH` trick from before. I see two slightly different pairs of numbers. Also, the right-justified edge of my prompt is slightly odd, although it might be something to do with zsh.

~  49 101  18:17:51
 ~  49 104  18:17:51

I tested the `echo` test with bash, and I don't see the problem at all; it works perfectly.

[Stephen Boddy (stephen-j-boddy)]

Try this one... print your text, then resize the window in and out a few times, making sure to cause the rewrap to trigger. Lines disappear! I'm not sure if this is to do with the fancy prompt, but that action causes havoc (i.e. the number lines disappear, there's runs of garbage in the multicolored prompt.) I have no idea how to resolve that, so I hope it's not Terminator at fault here. Interestingly, when I turn off the rewrapping, zsh still rewraps the prompt line (bash doesn't) and it gradually munches the previous lines, so zsh itself must be detecting and reacting to events from vte.

Egmont: any ideas, cos this has me stumped. I'm tempted to say that this bug is fixed, and this (whatever it is) is a different issue.

[Egmont Koblinger (egmont-gmail)]

bash <= 4.2 and zsh react immediately on resize, redraw the prompt. bash-4.3 only redraws the prompt on a subsequent keypress, not immediately upon a resize. No clue about bash-4.4.

Prompt displaying of bash is broken as hell, sometimes it even sends out invalid escape sequences and such. It shouldn't be used for evaluating vte's or terminator's behavior.

[Sparhawk (sparhawkthesecond)]

@Stephen, I tested resizing a few times, and indeed it messes up the window. However, the lines don't totally disappear, but instead move off the visible window. i.e. if I scroll up I can still see them. I've attached a screenshot. FWIW I tested doing the same thing in Konsole, and there are no artifacts. N.B. the grey time in my prompt is right-aligned. In Konsole, when I resize the window, it moves perfectly left and right to follow the right edge of the window.

I think you are right, and it's probably my fancy prompt not meshing perfectly with terminator. I did a bit more testing with other prompts. I don't see the problem with the default zsh prompt, the "steeef" prompt, or the "eriner" prompt [1].

The prompt that I've had issues with is Powerline9k [2]. I also see the problem with the "minimal" prompt. This also has a right-aligned element. Hence, from the five prompts that I tested, I suspect that any prompt that uses right-aligned elements might be problematic for terminator. Similarly, I tested the "minimal" prompt with Konsole, and it also displays fine with resizing.

Please let me know if you are having trouble duplicating this issue. I have a stack of stuff in ~.zshrc that might be interfering. I didn't investigate rewrapping, but I can if you think it might be diagnostic.

[1] https://github.com/Eriner/zim/wiki/Themes
[2] https://github.com/bhilburn/powerlevel9k

[Stephen Boddy (stephen-j-boddy)]

@Sparhawk. Quick Q. Did you test how the zsh fancy prompt behaves in gnome-terminal when you resize its window? I ask because gnome-terminal and terminator use the exact same vte widget for the actual terminal. If you see the same thing in gnome-terminal, it would point to a problem in the behaviour of the widget, rather than the application. If on the other hand gnome-terminal behaves properly, then it points to a problem in terminator. (The fact that Konsole is OK at least tells us that your environment/zsh/the specific prompt are all working. It does however use a completely different terminal KPart, which is why I ask about gnome-terminal.)

[Sparhawk (sparhawkthesecond)]

Ah, yes, gnome-terminal does indeed suffer from the same problems.

[Stephen Boddy (stephen-j-boddy)]

Yay! um... I mean, OK. So I'm going to close this as the original issue is all fixed, and if g-t is hitting this lingering issue, then it is almost certainly an issue in the common libvte widget.

Perhaps you can raise a bug with that project? I confess that I'm not even sure if I have an account at the gnome bug tracker: https://bugzilla.gnome.org/page.cgi?id=browse.html&product=vte

[Stephen Boddy (stephen-j-boddy)]

This might actually be somewhat related to https://bugzilla.gnome.org/show_bug.cgi?id=763390

Egmont would be more capable of determining that than me though.

[Sparhawk (sparhawkthesecond)]

Hahahahahahaha! Too funny!

Okay, bug filed here: https://bugzilla.gnome.org/show_bug.cgi?id=778547

Thank you both for all your help. I really appreciate it!

[Sparhawk (sparhawkthesecond)]

Okay, thanks Stephen. I'll wait for Egmont's reply before cross-posting in the Gnome's bug tracker.