since 4.3.4, artifact-appearance at prompt

since 4.3.4, artifact-appearance at prompt

[Russell Hoover]

If, at my zsh prompt, I hit return several times quickly (to repeat the
appearance of the prompt for several lines in a row), such that sometimes
a blank line appears before the prompt does, I always now get, at the
leftmost column of the blank line, the appearance of a percent-sign
backgrounded in orange.

This has only happened since I started using zsh-4.3.4, and I'm wondering
what I can do to get rid it.

My prompt is this (minus colors):

[panix1:~]  [v4.3.4]  zsh  507 -->

And it is created by this line in my .zshenv (where it is all one line,
though these 4 parts of it are separated by two spaces between each of them):

export PS1=$'%{\e[1;32m%}[$red%m$white:$cyan%~$green]
[%{\e[m%}%{\e[36m%}v$ZSH_VERSION$green]
%{\e[m%}zsh%(2L./$blue$SHLVL.)$yellow%(2v:$grey/$yellow+%2v:)
$white! %$red--$yellow> %{\e[m%}'


I also have a right-prompt:

t7  Saturday  2007/11/03  19:28:21

created by this line in my .zshenv:

export RPS1=$'%{\e[1;34m%} %l  $yellow%D{%A  %Y/%m/%d  %T} %{\e[m%}'

I wonder what may have changed with version 4.3.4 that's caused the
artifact.  Thanks for any tips.

-- 
                         // rj@panix.com //

Re: since 4.3.4, artifact-appearance at prompt

[Bart Schaefer]

On Nov 3,  7:43pm, Russell Hoover wrote:
} Subject: since 4.3.4, artifact-appearance at prompt
}
} If, at my zsh prompt, I hit return several times quickly (to repeat the
} appearance of the prompt for several lines in a row), such that sometimes
} a blank line appears before the prompt does, I always now get, at the
} leftmost column of the blank line, the appearance of a percent-sign
} backgrounded in orange.

You're witnessing effects of the new PROMPT_SP option, apparently combined
either with some race condition on echoing the newlines you're typing, or
with an odd right-margin line-wrap behavior of your terminal emulator.

Re: since 4.3.4, artifact-appearance at prompt

[Russell Hoover]

On Sat 11/03/07 at 06:30 PM -0700,
Bart Schaefer <schaefer@brasslantern.com> wrote:

> You're witnessing effects of the new PROMPT_SP option, apparently combined
> either with some race condition on echoing the newlines you're typing, or
> with an odd right-margin line-wrap behavior of your terminal emulator.

Thanks, I disabled PROMPT_SP for now, since it's on by default.  I don't
deal with long lines in the ZLE that much and I'd rather not see that "%"
on a blank line  where I'm not sure it's doing me any good (when my prompt
is already on the next line).

-- 
                         // rj@panix.com //

Re: since 4.3.4, artifact-appearance at prompt

[Atom Smasher]

On Sat, 3 Nov 2007, Russell Hoover wrote:

> On Sat 11/03/07 at 06:30 PM -0700, Bart Schaefer 
> <schaefer@brasslantern.com> wrote:
>
>> You're witnessing effects of the new PROMPT_SP option, apparently 
>> combined either with some race condition on echoing the newlines you're 
>> typing, or with an odd right-margin line-wrap behavior of your terminal 
>> emulator.
>
> Thanks, I disabled PROMPT_SP for now, since it's on by default.  I don't 
> deal with long lines in the ZLE that much and I'd rather not see that 
> "%" on a blank line where I'm not sure it's doing me any good (when my 
> prompt is already on the next line).
===================

would it be reasonable to have an SPPROMPT parameter, or something 
similar, to control what's displayed there? i guess a default would be 
'%S%#%s' but the option would still be useful if it's output could be set 
to ''. IMHO the PROMPT_SP option is nice, and it would be better to turn 
off (or otherwise modify) it's verbose output, rather than turn off the 
option.


-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"The reasonable man adapts himself to the world; the
 	 unreasonable one persists in trying to adapt the world to
 	 himself. Therefore all progress depends on the
 	 unreasonable man."
 		-- George Bernard Shaw

Re: since 4.3.4, artifact-appearance at prompt

[Bart Schaefer]

On Nov 4,  8:00pm, Atom Smasher wrote:
}
} > On Sat, 3 Nov 2007, Russell Hoover wrote:
} > "%" on a blank line where I'm not sure it's doing me any good (when my 
} > prompt is already on the next line).

Note in passing:  You're not supposed to see the % on a blank line.  The
PROMPT_SP trick is supposed to emit just enough spaces so that, *if* the
line is blank, then when the PROMP_CR carriage return is printed, you'll
be returned to the position where the % appears and the normal prompt
will cover it up.

This is why I say you're either in a race condition -- e.g., zsh prints
the spaces but before it can backspace and print the prompt, you hit
enter again and the teminal advances to the next line [*] -- or there's
something unexpected about the right-margin auto-wrap behavior of your
terminal, such that the PROMPT_SP spaces cause a new line where one
should not be.

[*] I can't make this happen no matter how fast I hammer on the enter
key, so I suspect this is related to other problems with slow prompts.

Ok, that got windier than I intended.  Back to the real reply:

On Nov 4,  8:00pm, Atom Smasher wrote:
}
} would it be reasonable to have an SPPROMPT parameter, or something 
} similar, to control what's displayed there?

It wouldn't be unreasonable, but it would require the prompt_sp code to
be able to compute the exact visible width of that substitution -- that
is, users would have to be just as careful with %{ and %} as they are
in the prompt itself, maybe more so.

If you want to control what appears there, you can unsetopt prompt_sp
and insert the equivalent sequence into your PS1 string or precmd
function, as described in FAQ 3.23:

    # Skip defining precmd if the PROMPT_SP option is available.
    if ! eval '[[ -o promptsp ]] 2>/dev/null'; then
      function precmd {
        # An efficient version using termcap multi-right:
        print -nP '%B%S%#%s%b'      # Output % or #
        echotc RI $((COLUMNS - 3))
        echo -n '  '                # Output 2 spaces
      }
    fi

If you change the "print -nP" string to be wider, increase the "3" in the
echotc to compensate.  It should always be 2 more than the width of the
print output.

A suggestion I'll throw out in case someone feels like running with it:
Perhaps there should be a %-expando for PS1 that performs the "echotc RI"
of the correct width based on the current %(l..) value (if you see what
I mean), followed by the two spaces.  Suppose that's %P (not necessarily
the best choice, just the first unused letter to come to mind).  Then one
could just do

    PS1="%B%S%#%s%b%P$PS1"

and customize the part to the left of the %P any way they like.  Or %P
could take an "argument" like %D does, if that would be easier:

    PS1=%P{%B%S%#%s%b}$PS1"

Any thoughts from the -workers on that?

Re: since 4.3.4, artifact-appearance at prompt

[Wayne Davison]

On Sun, Nov 04, 2007 at 09:48:03AM -0800, Bart Schaefer wrote:
>       function precmd {
>         # An efficient version using termcap multi-right:
>         print -nP '%B%S%#%s%b'      # Output % or #
>         echotc RI $((COLUMNS - 3))
>         echo -n '  '                # Output 2 spaces
>       }

You should replace the 2-space echo with a print that also outputs a CR:

       print -n '  \r'

This makes it less likely that the user's type-ahead after this output
will cause the screen to scroll (and is what the current code does).
Yes, the PROMPT_CR option is going to output a CR too, but it does so
after enough of a delay that I would sometimes see an inverted % on an
empty line if my type-ahead echoed between the PROMPT_SP output and the
PROMPT_CR output.

>     PS1=%P{%B%S%#%s%b}$PS1"
> 
> Any thoughts from the -workers on that?

It is better to output the %P portion as early as possible in the
post-command-run code, so outputting it as an actual part of the prompt
would probably not be desirable.  The PS1 string could get carved up
into early and normal prompt pieces, but it would probably just be
better to have an environment variable that specifies what to output.
e.g.:

PROMPTSP=%{%B%S%}%#%{%s%b%}

However, an alternative to having the user use %{ ... %} would be to
have the user just tell us how wide their string is:

PROMPTSP=1:%B%S%#%s%b

..wayne..

Re: since 4.3.4, artifact-appearance at prompt

[Bart Schaefer]

On Nov 4,  2:16pm, Wayne Davison wrote:
} Subject: Re: since 4.3.4, artifact-appearance at prompt
}
} On Sun, Nov 04, 2007 at 09:48:03AM -0800, Bart Schaefer wrote:
} >       function precmd {
} >         # An efficient version using termcap multi-right:
} >         print -nP '%B%S%#%s%b'      # Output % or #
} >         echotc RI $((COLUMNS - 3))
} >         echo -n '  '                # Output 2 spaces
} >       }
} 
} You should replace the 2-space echo with a print that also outputs a CR:
} 
}        print -n '  \r'

In that case we ought to update both the FAQ, and the C code that
handles PROMPT_SP.  I copied the above right out of the FAQ, except
for changing the first "print".

} Yes, the PROMPT_CR option is going to output a CR too, but it does so
} after enough of a delay that I would sometimes see an inverted % on an
} empty line if my type-ahead echoed between the PROMPT_SP output and the
} PROMPT_CR output.

This appears to be what Russell is experiencing, too.

} It is better to output the %P portion as early as possible in the
} post-command-run code, so outputting it as an actual part of the prompt
} would probably not be desirable.

I'm willing to believe that.

} e.g.:
} 
} PROMPTSP=%{%B%S%}%#%{%s%b%}

The internals of prompting already know that %B%S and %s%b don't occupy
any space.  %{...%} shouldn't be needed there.

} However, an alternative to having the user use %{ ... %} would be to
} have the user just tell us how wide their string is:
} 
} PROMPTSP=1:%B%S%#%s%b

The countprompt() function is exported from prompt.c for ZLE's use, so 
I don't think there's much to be gained there.

Re: since 4.3.4, artifact-appearance at prompt

[Wayne Davison]

On Sun, Nov 04, 2007 at 03:48:39PM -0800, Bart Schaefer wrote:
> In that case we ought to update both the FAQ, and the C code that
> handles PROMPT_SP.

The FAQ got updated back in July of 2005 (see revision 1.23).  The C
code doesn't need to be updated, as it already does the right thing.

..wayne..

Re: since 4.3.4, artifact-appearance at prompt

[Bart Schaefer]

On Nov 4, 10:01pm, Wayne Davison wrote:
} 
} The FAQ got updated back in July of 2005 (see revision 1.23).  The C
} code doesn't need to be updated, as it already does the right thing.

Hrm.  Why doesn't the top-level "make" invoke "make FAQ"?  Sorry for
the misquote.  Oy.

Re: since 4.3.4, artifact-appearance at prompt

[Oliver Kiddle]

Bart wrote:
> [*] I can't make this happen no matter how fast I hammer on the enter
> key, so I suspect this is related to other problems with slow prompts.

I've seen it happen occasionally over a slow ssh connection.

Could we perhaps do an stty -echo around the printing of the % up until
the newline is printed.

Is the default really printing %# (the prompt expansion) as opposed to a
literal % character? Making it easily configurable could be nice.

Oliver

Re: since 4.3.4, artifact-appearance at prompt

[Bart Schaefer]

On Nov 5, 11:28am, Oliver Kiddle wrote:
}
} Bart wrote:
} > [*] I can't make this happen no matter how fast I hammer on the enter
} > key, so I suspect this is related to other problems with slow prompts.
} 
} I've seen it happen occasionally over a slow ssh connection.
} 
} Could we perhaps do an stty -echo around the printing of the % up until
} the newline is printed.

It's apparent that the "\r" that is being printed at the end of the
promptsp output doesn't actually fix the problem Wayne described, or
Russell wouldn't be reporting it.  You can still get a % on a blank
line from typeahead.

On the other hand I think "stty -echo" in the midst of typeahead could
cause even more confusion.

} Is the default really printing %# (the prompt expansion) as opposed to
} a literal % character?

Yep, in fact it's "%B%S%#%s%b", see Src/utils.c:preprompt().

Re: since 4.3.4, artifact-appearance at prompt

[Wayne Davison]

On Sun, Nov 04, 2007 at 08:00:06PM +1300, Atom Smasher wrote:
> i guess a default would be '%S%#%s' but the option would still be
> useful if it's output could be set to ''.

Do keep in mind that if it were set to '', you may run a command like
"echo -n foo" and wonder why the -n option isn't working.  This is why
the output was made non-empty by default, so just be alert for that.

..wayne..

Re: since 4.3.4, artifact-appearance at prompt

[Benjamin Andresen]

Russell Hoover <rj@panix.com> writes:

> I always now get, at the leftmost column of the blank line, the
> appearance of a percent-sign backgrounded in orange.

I have the same problem. But the percent sign is inverted for me,
always the inverted terminal backgroud colour.  I tried to ask people
in #zsh, but nobody could reproduce it...

It especially often happens when I exit applications with ^D.
(Currently I can _only_ reproduce it that way.)

For instance, take this example:

$ PROMPT='zsh%% ' zsh -f
zsh% rc
% % (Inverted colour, after pressing ^D)
zsh% 

the same happens with sbcl, irb and some other line based application.
(Not ed though. And if I strace =rc, it doesn't show the percent sign,
but it does when I strace zsh. So I guess it's related to zsh.)

<snip from strace>
rt_sigaction(SIGINT, {0x80a2fc0, [], SA_INTERRUPT}, NULL, 8) = 0
write(10, "\33[1m\33[3m%\33[23m\33[1m\33[0m          "..., 167%
) = 167
rt_sigaction(SIGINT, {0x80a2fc0, [], SA_INTERRUPT}, NULL, 8) = 0
<snap>
(Important, the percent sign above is inverted.)

rc is the smallest binary I could get to show the problem and it looks
as if it isn't related to readline as I first thought.

zsh% ldd =rc
        linux-gate.so.1 =>  (0xb7f5a000)
        libm.so.6 => /lib/libm.so.6 (0xb7f24000)
        libutil.so.1 => /lib/libutil.so.1 (0xb7f20000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7f08000)
        libc.so.6 => /lib/libc.so.6 (0xb7dd2000)
        /lib/ld-linux.so.2 (0xb7f5b000)

I accepted the fate, I just wanted to give additional information. :-)

hth,
benny