Created attachment 7086 Sample document to edit to demonstrate the bug The attached file "plot" is a movie plot summary from Wikipedia, edited to remove non-ASCII characters. Each paragraph is written on one long line. If I start an xfce4-terminal from the command line by doing xfce4-terminal --geometry 80x30 -T normal --hide-menubar And then, in that terminal window, type vim plot vim starts up normally, as seen in the attachment "normal.png". (Since most of the odd-numbered lines of the file are long paragraphs, they get wrapped, so only lines 1-5 of the file are actually visible in this screenshot.) However, if I do THIS: xfce4-terminal --geometry 80x30 -T buggy --hide-menubar -e 'vim plot' then vim displays the file shifted by one line upward: see "buggy1.png". Typing control-L to have vim repaint the screen causes no change. If I attempt to navigate in the file in the usual ways, the cursor moves to where it would be if it had been displayed correctly. For example, typing "/Greek" in vim puts the cursor (green) below the word "Greek", as seen in "buggy2.png". Naturally, this makes it impossible to use vim with any degree of convenience. However, there seems to be a workaround. If I change the width of the window by clicking and dragging its left or right side, then vim now gets the right idea of its size and displays things properly. If I change it to 79x30 by dragging the left side one column right, and then back to 80x30 by dragging it back to the left, then I get "buggy3.png" and now the window looks the way it should. (Why do I care -- why would I ever use a command line like that? The answer is that I use Firefox's "It's All Text" add-on, and I use a shell script with a command line like that in order to have it run vim in a temporary terminal window. In fact I'm editing this bug report in that manner. The bug only seems to happen when there are very long lines in the file, and I'm keeping my lines under 80 characters here.) Of course I can't tell for sure whether the bug is in xfce4-terminal or the xfce window manager or some other, non-xfce component involved in these operations. But the involvement of the -e option suggests that it is xfce4-terminal. I can say that it only started happening relatively recently, say in the last few weeks.
Created attachment 7087 Screenshot showing normal appearance
Created attachment 7088 Screenshot showing wrong appearance (1)
Created attachment 7089 Screenshot showing wrong appearance (2)
Created attachment 7090 Screenshot after workaround
I cannot reproduce this on my Arch Linux system with xfce4-terminal 0.8.4-git, vte3 0.47.91-git and vim 8.0. What is your OS? What versions of these components are you using?
I'm using Fedora 25 Linux, and I just did a "dnf update" to confirm that the bug is still present for me with the newest components. I have these RPMs: vim-enhanced-8.0.562-1.fc25.x86_64 xfce4-terminal-0.8.4-1.fc25.x86_64 I don't have an RPM installed with vte3 in its name, but I have: vte-0.28.2-18.fc25.x86_64 vte-profile-0.46.1-1.fc25.x86_64 vte291-0.46.1-1.fc25.x86_64 If I can help you by checking on versions of things in another way, please let me know.
I can't reproduce either. I'm on Ubuntu Zesty; tried with xfce4-terminal 0.8.4 as shipped by the distro as well as from git master; VTE from git master only; everything else as shipped by Zesty. Desktop environment is Unity7. Just wondering, why do you have three @s below each other even in the normal case? For me, the third paragraph of the plot starts displaying there (two lines, then three @s next to each other in the next line). I'm not a vim user, no clue what these blue @s stand for. Anyway: Instead of 'vim plot', could you please start a shell script like this (via xfce4-terminal --geom ... -e ...) and see what's printed? #!/bin/bash trap 'echo -n winch:; stty size' WINCH echo $LINES $COLUMNS stty size sleep 1 stty size sleep 1000000 What's printed for you? For me, it's an empty line (the shell variables aren't initialized, nevermind), then 24 80, then a second later winch event and the new size of 30 80. On one hand, this is not nice from xfce4-terminal that it does not open with the desired size straight away but rather with an intermittent 80x24. Preferable it should fix it and then your problem will be fixed too. On the other hand, it's not nice from vim that it cannot handle resize events without a race condition, and you're hitting such a race. Either it ignores window size changes for some period during its startup, or it receives multiple consecutive resize events and it fails to handle them properly. The above bash script is not guaranteed to catch all the resize events, we'd need to debug VTE in order to make sure to see all.
Looks like you've diagnosed it correctly. I get precisely the output 24 80 winch:30 80 30 80 As you say, it would be nicer for xfce4-terminal to start with the correct window-size information, but it looks like it's vim that's not handling the change to 30x80. For my purposes I can work around the bug by changing the script that "It's All Text!" invokes. Instead of using -e 'vim FILE' it will now do -e 'slowvim FILE', where slowvim is a shell script reading sleep 0.1 exec vim "$@" Thanks! As to the @ lines, that's just vim's way of saying "Because the next line of the file is wide enough that it wraps onto several screen lines, there isn't room in the window to display it competely, so to avoid confusing you, I won't try." (It would only display a partial line if it filled the entire window.)
Indeed, if no instance of xfce4-terminal is running, it would start 80x24 and then resize to 80x30. I will look into this, thanks.
OK, there's a comment in the code explaining why the window is first created with default size and then resized to desired geometry: /* set the window geometry, this can only be set after one of the tabs * has been added, because vte is the geometry widget, so atleast one * call should have been made to terminal_screen_set_window_geometry_hints */ Egmont, do you think that could be true for gtk2 vte but isn't the case anymore?
Geometry has always been a nightmare, even around gtk-3.20 there were significant changes. I'm not familiar with this topic too much. It's easily possible that a hack required from the gtk2 era is no longer relevant.
Mark, Egmont, thanks for the report and your help. Fixed by https://git.xfce.org/apps/xfce4-terminal/commit/?id=159676d89c24d4b61c972da28db73645525cf051