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.
