On 6/12/17 9:49 PM, Paul Peet wrote:
> Yes, indeed, rewrapping the contents on resize breaks this assumption.
>
> Given that in a(n obviously non-representative) poll about 1.5 years
> ago at https://opensource.com/life/15/11/top-open-source-terminal-emulators,
> terminal emulators that now (not
Well, I seriously have no idea what approach would be the right one to
fix this but I've responded on the other side and this was Egmont
Koblinger (vte developer) response:
Yes, indeed, rewrapping the contents on resize breaks this assumption.
Given that in a(n obviously non-representative)
On 6/12/17 4:24 PM, Chet Ramey wrote:
> On 6/12/17 4:08 PM, Paul Peet wrote:
>> Is there a flag in macOS's Terminal? It's because I am also
>> experiencing this bug on macOS's Terminal :) (with bash).
>
> I doubt it. My testing wasn't very scientific. I just opened up a new
> Terminal, ran bash-4.
On 6/12/17 4:08 PM, Paul Peet wrote:
> Is there a flag in macOS's Terminal? It's because I am also
> experiencing this bug on macOS's Terminal :) (with bash).
I doubt it. My testing wasn't very scientific. I just opened up a new
Terminal, ran bash-4.4, typed a bunch of characters, and constantly r
Is there a flag in macOS's Terminal? It's because I am also
experiencing this bug on macOS's Terminal :) (with bash).
On Mon, Jun 12, 2017 at 9:47 PM, Chet Ramey wrote:
> On 6/12/17 3:45 PM, Paul Peet wrote:
>> Well, I can try to re-open this issue on the gnome-terminal/vte3 side.
>> Perhaps I ca
On 6/12/17 3:45 PM, Paul Peet wrote:
> Well, I can try to re-open this issue on the gnome-terminal/vte3 side.
> Perhaps I can convince them to take an approach where the terminal
> isn't violating the assumptions of the display engine by introducing a
> new flag or something like that.
Maybe. I kn
Well, I can try to re-open this issue on the gnome-terminal/vte3 side.
Perhaps I can convince them to take an approach where the terminal
isn't violating the assumptions of the display engine by introducing a
new flag or something like that.
On Mon, Jun 12, 2017 at 9:27 PM, Chet Ramey wrote:
> On
On 6/12/17 2:24 PM, Paul Peet wrote:
> I guess this is why I don't get the garbage output with gnome-terminal
> and dash. Dash doesn't use readline apparently.
Dash doesn't support line editing at all out of the box, though you can
build it using libedit.
>
> So, what can be done to actually fix
I guess this is why I don't get the garbage output with gnome-terminal
and dash. Dash doesn't use readline apparently.
So, what can be done to actually fix this?
On Mon, Jun 12, 2017 at 7:55 PM, Chet Ramey wrote:
> On 6/12/17 1:38 PM, Paul Peet wrote:
>> Uhmm, I am not sure how to interpret thes
On 6/12/17 1:38 PM, Paul Peet wrote:
> Uhmm, I am not sure how to interpret these results (All shells or
> terminals have been tested with Ubuntu 17.04):
>
> gnome-terminal + bash: Happens
> gnome-terminal + zsh: This bug also happens here, lines are getting
> removed/repeated...
> gnome-terminal
Uhmm, I am not sure how to interpret these results (All shells or
terminals have been tested with Ubuntu 17.04):
gnome-terminal + bash: Happens
gnome-terminal + zsh: This bug also happens here, lines are getting
removed/repeated...
gnome-terminal + dash: Does not happen. (I changed the
PS1="userna
On Sun, Jun 11, 2017 at 12:29:33AM +0200, Paul Peet wrote:
[...]
> Unfortunately, I am still getting the same behavior as before (This
> also happens with xterm for some reason.)
Please do consider that Readline has little knowledge about what has
been written to the terminal. That's the terminal'
Okay, I did the follwing:
> git clone https://git.savannah.gnu.org/git/bash.git
> cd bash && git checkout devel
> ./configure --prefix=/ --with-curses --enable-readline
> make
I then changed the default shell (in gnome-terminal) to the newly built bash.
> echo $BASH_VERSION
4.4.12(1)-maint
Unfo
On Sat, Jun 10, 2017 at 07:21:36PM +0200, Paul Peet wrote:
> If I understand this correctly this prompt (see below) shouldn't
> contain any invisible sequence, therefore it doesn't require the
> wrapping with \[ and \].
>
> PS1="\u@\h\$"
>
> So bash should be able to correctly calculate the promp
If I understand this correctly this prompt (see below) shouldn't
contain any invisible sequence, therefore it doesn't require the
wrapping with \[ and \].
PS1="\u@\h\$"
So bash should be able to correctly calculate the prompt size and
such, but by resizing the window it still results in a corrupt
On Sat, Jun 10, 2017 at 06:49:13PM +0200, Paul Peet wrote:
> declare -- PS1="\\[\\e]0;\\u@\\h:
> \\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
> "
[...]
> > Bash relies on \[ and \] to determine how much space is occup
declare -- PS1="\\[\\e]0;\\u@\\h:
\\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
"
On Sat, Jun 10, 2017 at 6:47 PM, George wrote:
> On Sat, 2017-06-10 at 11:20 -0500, Eduardo Bustamante wrote:
>
> On Sat, Jun 10, 201
On Sat, 2017-06-10 at 11:20 -0500, Eduardo Bustamante wrote:
> On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote:
> >
> > I would like to report a bug with bash (readline?). This bug can be
> > reproduced by opening gnome-terminal with bash running. By quickly
> > horizontally resizing the
On Sat, Jun 10, 2017 at 04:56:35PM +0200, Paul Peet wrote:
> I would like to report a bug with bash (readline?). This bug can be
> reproduced by opening gnome-terminal with bash running. By quickly
> horizontally resizing the terminal window you can see that the buffer
> seems to be corrupted as yo
I would like to report a bug with bash (readline?). This bug can be
reproduced by opening gnome-terminal with bash running. By quickly
horizontally resizing the terminal window you can see that the buffer
seems to be corrupted as you see repeated or even removed lines or
characters.
At first I tho
20 matches
Mail list logo
