Hi,

> It's a bit weird, I can *no* longer reproduce it.

VTE's emulation behavior didn't change recently. Bash/Readline could
have changed, I don't know (might be interesting to check their Ubuntu
packages' changelogs). Or you're executing somewhat different steps.

If the printed prompt is exactly the same (including all the bells and
whistles that it prints, like the username, hostname, working
directory, previous command's exit value, background job stuff), and
the terminal width is exactly the same (is it?), and you're pressing
the same keys to invoke the same previous commands or editing the
current command in the exact same way, then you should see the exact
same behavior. Any difference in any of these could make the bug
appear or vanish.

Also make sure that the previous command's output ended with a
newline, that is, the prompt begins in the first column. Otherwise
it's common to see misbehavior while editing.

> @Samuel, could you please also try whether you can still reproduce it?
> If not, I'd say we might close the issue.

By now we are sure that we're talking about two separate issues. The
line editing misbehavior is surely independent from Samuel's patch.
You casually mentioned that you saw a crash, that one is probably
caused by that patch, but there's no stack trace here, and we already
have two other bugreports that focus on that crash and contain way
more information.

> That's interesting... why do you think so? The command substitution
> should also be bash, and I'd have thus expected \[ and \] inside it
> have therefore the same representation as outside and should thus be
> identical?

Vague memories from things I saw multiple times, maybe in bash's doc,
maybe on forums, I can't recall. I might be wrong. Actually, I might
mistake it with the prompt string you pass to readline if you're
programming against that library. In that case your prompt looks good
to me. Sorry, it's too late here and I'm too tired to look it up or
investigate right now.


cheers,
e.

Reply via email to