On Thu, 2023-09-21 at 23:31 +0200, Egmont Koblinger wrote:
> 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).
What I did notice that libvte and gnome-terminal packages were both
Christoph Anton Mitterer, le jeu. 21 sept. 2023 22:56:31 +0200, a ecrit:
> It's a bit weird, I can *no* longer reproduce it.
I can't either, be it with or without my patches.
Samuel
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 exactl
Hey there.
It's a bit weird, I can *no* longer reproduce it.
I have now (and everything else except libheif* at the current versions
of unstable):
libvte-2.91-0:amd64 0.74.0-2
gnome-terminal 3.50.0-1
If I use my original PS1 and the command I've mentioned before, go back
with the Up key and then
Christoph Anton Mitterer, le mar. 19 sept. 2023 14:23:47 +0200, a ecrit:
> On Tue, 2023-09-19 at 13:47 +0200, Samuel Thibault wrote:
> > I can't reproduce it.
>
> Interestingly, I've just been able to reproduce it even with 0.73.99-1:
This is reproducible also with 0.74.0-2, which has my patches
Christoph Anton Mitterer, le mar. 19 sept. 2023 14:23:47 +0200, a ecrit:
> > Random difference guesses:
> >
> > - Does it happen with a plain
> >
> > PS1="$ "
> >
> > prompt?
>
> It does indeed not happen with that prompt string.
Ok, so the prompt does matter.
> My PS1 is a bit more complex,
Hi Chris,
> Interestingly, I've just been able to reproduce it even with 0.73.99-1:
This makes sense. I was wondering how a patch that supposedly only
touches a11y (how the contents are read out loud) could have an effect
on the actual emulation behavior.
Can you try under xterm or other non-VTE
On Tue, 2023-09-19 at 13:47 +0200, Samuel Thibault wrote:
> I can't reproduce it.
Interestingly, I've just been able to reproduce it even with 0.73.99-1:
I have this command:
$ exiftool -p '${CreateDate} ${FileName}' * 2> /dev/null
press enter, then Up key, then I move the cursor behind the 2 an
On Tue, Sep 19, 2023 at 7:45 AM Egmont Koblinger wrote:
> Jeremy, I recommend you to revert that patch and hold it off until it
> gets fixed and receives a fair amount of testing.
Well, this was one way to get some testing :)
But yes, I am removing the patch from Debian Unstable now.
Thank you,
Hello,
Christoph Anton Mitterer, le mar. 19 sept. 2023 01:11:53 +0200, a ecrit:
> What I do is, getting a line from the history, either via the Up-key
> or via incremental reverse searh (Ctrl-R) and when I then edit this
> line (e.g. remove a character), another character is wrongly swallowed,
> a
Hi,
It's apparently the same as Debian bug #1052172, caused by Debian
backporting an untested patch that just made it to upstream's
development branch and apparently hasn't received proper testing.
Upstream discussion begins at
https://gitlab.gnome.org/GNOME/vte/-/issues/88#note_1849187 .
Jeremy
Package: libvte-2.91-0
Version: 0.74.0-1
Severity: important
Hey.
After upgrading to 0.74.0-1 I've experienced some weired behaviour when
editing history lines in bash (via libreadline).
What I do is, getting a line from the history, either via the Up-key
or via incremental reverse searh (Ctrl-
12 matches
Mail list logo
