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
19 matches
Mail list logo
