After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 346554 - Fancy prompt triggers update problem
Fancy prompt triggers update problem
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.12.x
Other Linux
: Normal normal
: ---
Assigned To: Behdad Esfahbod
VTE Maintainers
: 341881 379993 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-07-04 15:06 UTC by Owen Taylor
Modified: 2007-01-21 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Queue the gdk_window_set_* to an idle handler. (3.42 KB, patch)
2007-01-17 14:59 UTC, Chris Wilson
none Details | Review
Queue the gdk_window_set_* to an idle handler. (3.67 KB, patch)
2007-01-17 15:04 UTC, Chris Wilson
needs-work Details | Review
Queue the gdk_window_set_* to an idle handler (7.13 KB, patch)
2007-01-18 12:37 UTC, Chris Wilson
none Details | Review

Description Owen Taylor 2006-07-04 15:06:36 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.
Comment 1 Behdad Esfahbod 2006-07-05 05:55:05 UTC
They seem to be the same problem.  And quite reproducible here.  Looking into it.
Comment 2 Behdad Esfahbod 2006-07-29 16:20:38 UTC
*** Bug 341881 has been marked as a duplicate of this bug. ***
Comment 3 Behdad Esfahbod 2006-11-28 18:47:46 UTC
*** Bug 379993 has been marked as a duplicate of this bug. ***
Comment 4 Mariano Suárez-Alvarez 2006-11-28 21:27:13 UTC
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.
Comment 5 Behdad Esfahbod 2006-11-28 21:54:39 UTC
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...
Comment 6 Mariano Suárez-Alvarez 2006-11-30 21:15:34 UTC
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...
Comment 7 Chris Wilson 2007-01-17 14:59:14 UTC
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.
Comment 8 Chris Wilson 2007-01-17 15:04:45 UTC
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
Comment 9 Behdad Esfahbod 2007-01-17 21:15:08 UTC
Looks good.
Comment 10 Mariano Suárez-Alvarez 2007-01-17 23:50:37 UTC
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.
Comment 11 Chris Wilson 2007-01-18 12:37:43 UTC
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.
Comment 12 Chris Wilson 2007-01-19 19:42:06 UTC
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?
Comment 13 Mariano Suárez-Alvarez 2007-01-20 21:25:44 UTC
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.
Comment 14 Behdad Esfahbod 2007-01-21 12:36:09 UTC
Confirmed.