GNOME Bugzilla – Bug 792532
Demote "Rewrap on resize" to hidden pref
Last modified: 2019-06-06 11:20:47 UTC
"Rewrap on resize" has been available for 4 years now. The reason for having introduced an API and config option was because it's potentially slow with infinite scrollback. During these 4 years I haven't seen anyone complaining about it being slow, even despite some vte-apps (e.g. mate-terminal) not even having this option yet (i.e. rewrapping is always enabled), whereas support infinite scrollback. Shall we demote it to a hidden pref and see if anyone notices? :-) It doesn't quite fit in the "Text Appearance" section anyway since it's about behavior, not appearance (in _that_ sense). Shall we do it now (we've added two new entries to this tab and it's become a bit crowded), or next cycle (to give more time for beta testers to speak up)?
[Obviously, it'd still be enabled by default, and one would need to dig into dconf to disable rewrap-on-resize.]
@chpe, opinion (for 3.28)?
Yes, let's make it a no-UI-pref only.
Created attachment 367241 [details] [review] Fix
As bizarre as it may sound, I received a bug from a RHEL 7 user, where a specific tcsh prompt combined with "Rewrap on resize" causes the prompt to get weirdly shifted when the window is resized. Here's the relevant ~/.cshrc snippet: if ( $?tcsh ) then if ( $?TERM ) then if ( "`env | grep -i term | grep -i xterm`" == "" ) then set prompt = "\n%m - %n - %/ - $shell\n%h%#: " else set prompt = "\n%B%m - %n - %/ - $shell\n%h%#:%b " endif endif endif Maybe this counts as a reason to expose the preference in the UI? Similar (?) Bash and KornShell prompts that aren't affected: if [[ $SHELL == '/bin/bash' ]]; then if [ ! -z ${TERM+x} ]; then PS1='\n\h - \u - \w - $SHELL\n\!\$: ' fi fi if [[ $SHELL == '/bin/ksh' ]]; then if [ ! -z ${TERM+x} ]; then if [[ $USER == 'root' ]]; then PS1=$'\n`hostname -s` - `logname` - $PWD - $SHELL\n#: ' else PS1=$'\n`hostname -s` - `logname` - $PWD - $SHELL\n$: ' fi fi fi
Here's the downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1596328 I don't know if you can access it, though.
Or maybe this counts as a reason to fix tcsh? :-) Okay, seriously: With this prompt, simply pressing the Up arrow to invoke the previous command is broken for me (on Ubuntu 18.04). Seems to me that even without resizing, it's unusably broken. Is this the default tcsh config of RHEL 7, or is it a custom one? Does the up arrow work there as expected? Then the first "\n" in the prompt is translated by tcsh into a widthful of spaces, with no terminating newline. Hence vte thinks it's the same logical line as the hostname-username-currentdir-shell line of the prompt, hence rewraps it as a single paragraph. Interestingly the second "\n" of the prompt is just emitted as a "\n", as expected. No idea why the first one is treated specially while the second one isn't. More precisely, it places the cursor in the last column, then prints 2 spaces, then a carriage return. This is the standard workaround to make sure a newline is started when the last command didn't terminate with one. So seems to me that tcsh automagically applies this workaround exactly when there's no reason (since the prompt begins with a newline anyway), and doesn't apply it when it would make sense. A tcsh expert could enlight me what is it that I'm missing. (Yes I can access the downstream bug.)
(In reply to Egmont Koblinger from comment #7) > With this prompt, simply pressing the Up arrow to invoke the previous > command is broken for me (on Ubuntu 18.04). Indeed, the up arrow key is broken for me too on Fedora 27. But I don't know much about tcsh, so no idea how sane this prompt is. > Seems to me that even without > resizing, it's unusably broken. Is this the default tcsh config of RHEL 7, > or is it a custom one? It's a custom prompt, not the default, no.
I'm not against bringing back this pref UI if there's a good reason, but a rarely used shell with a custom config which is broken anyways in other aspects is quite unlikely to convince me :)
Continuing in https://gitlab.gnome.org/GNOME/vte/issues/135...