GNOME Bugzilla – Bug 346554
Fancy prompt triggers update problem
Last modified: 2007-01-21 12:36:09 UTC
If I set the bash prompt as follows: export PS1="\[\033]0;X\007\033[33m\]Y\[\033[m\]\$ " Then two problems can be seen (they may be the same) - As you type, the cursor continually flashes back to the beginning of the line - If you paste (with the middle button, say) into the terminal, characters are inserted very slowly ... the terminal seems to be updated after each character. To explain the prompt above: \[ : Begin non-printing section 033]0;X\007: Set the terminal title to 'X' \033[33m: Set the color to orange (or some color, depends on config) \]: End non-printing section Y: Some text for the prompt \[: Begin another non-printing section \033[m: Reset back to the default color $ : More text for the prompt Most of these elements seem necessary to trigger the problem; I couldn't simplify it more than the above.
They seem to be the same problem. And quite reproducible here. Looking into it.
*** Bug 341881 has been marked as a duplicate of this bug. ***
*** Bug 379993 has been marked as a duplicate of this bug. ***
Ah. I can reproduce this with PS1="\[\033]0;X\007\]Y\$ " This is the typescript of: (1) type «PS1="\[\033]0;X\007\]Y\$ "», followed by Enter; (1) type «12345». $ PS1="\[\033]0;X\007\]Y\$ "^M ^[]0;X^GY$ ^M^[]0;X^GY$ ^M^[]0;X^GY$ 1^M^[]0;X^GY$ ^M^[]0;X^GY$ 1^M^[]0;X^GY$ ^M^[]0;X^GY$ 12^M^[]0;X^GY$ ^M^[]0;X^GY$ 12^M^[]0;X^GY$ ^M^[]0;X^GY$ 12345^M bash: 12345: command not found^M Note how bash repaints the complete line twice when one enters 1 and 2, but after that it does not anymore. Changing the X for longer strings in the above PS1, one sees that bash repaints the whole line for each character in the input until the line it is reading gets to the column n, where n is the length (taking into account escapes, of course) of what's between \[ and \] in PS1. I have no idea why and looking at the source did not help much... Now, every time bash emits that PS1 string, vte sees the «CSI ] 0 ; Ps BEL» xterm control sequence and sets the title. This, in particular, ends up setting up one X property on the xwindow of the terminal widget (cf. <http://cvs.gnome.org/viewcvs/vte/src/vteseq.c?r1=1.9&r2=1.10>) My guess is that the delay we are seeing is due to waiting for those X properties to be set or something. I hope bash has a good reason to do what it does... I doubt it.
Right, the thing about 'n' is what I found out the other day experimenting with it too. The X property stuff is rather new. Can you check if the problem disappears if you revert that patch? If it does, we can then look into making those calls conservatively, checking if title changed, etc...
FWIW, I asked the bash maintainers about all this repainting and they said: «From the 3.1/5.1 redisplay engine's perspective, it's necessary. Things are considerably better in bash-3.2/readline-5.2.» We should be faster though...
Created attachment 80514 [details] [review] Queue the gdk_window_set_* to an idle handler. This removes the flashing of the title bar, but not that of the cursor as it repaints the prompt.
Created attachment 80515 [details] [review] Queue the gdk_window_set_* to an idle handler. Pesky gcc was telling the truth with its warnings. This should also help with bug #388692
Looks good.
I had never noticed the window title flashing ;-) Chris, you could test if the title has changed since last time and not do the change when it's the same? Maybe changing vte_terminal_queue_window_title_changed into a vte_terminal_queue_change_window_title which gets also the title and doing the check there (ditto for the icon title) In any case, with this patch, running the vte app and saying PS1="\[\033]0;X\007\]Y\$ " does not get the window title updated. Haven't looked at the cause, though.
Created attachment 80588 [details] [review] Queue the gdk_window_set_* to an idle handler Updated as suggested. Mariano: can you check ./vte again as it is behaving itself here.
The cursor no longer flashes! This is a result of draining all vte_terminal_process_incoming before redrawing. r1475 | cpwilson | 2007-01-19 16:31:59 +0000 (Fri, 19 Jan 2007) | 13 lines 2007-01-19 Chris Wilson <chris@chris-wilson.co.uk> * src/vte.c: (process_timeout), (update_repeat_timeout), (update_timeout): Repeat _vte_terminal_process_incoming until we have drained the incoming buffers or we can handle no more. Fixes a problem where the display wouldn't update if we hadn't processed enough data (e.g. on startup, displaying the first prompt). This bug corresponds with the sequence '*-+=..()?!(?!?!?!)-+=' below, which now reads '*-+=..()(?!?!?!)-+=' Any outstanding objections on the patch to queue the gdk properties setters?
Without the patch in comment #11, vte HEAD shows no flashing. I'll close this as FIXED... We'll hold on to queueing the property setters until we really need it.
Confirmed.