Re: [PATCH] Readline not being able to handle long lines

[Mihail Konev]

Sorry for splitting a message into two.

On Wed, Nov 30, 2016 at 07:34:25AM +0500, Mihail Konev wrote:
> On Tue, Nov 29, 2016 at 10:02:08AM -0500, Greg Wooledge wrote:
> > On Tue, Nov 29, 2016 at 02:14:11PM +0500, Mihail Konev wrote:
> > > > Buggy (replace the ^-sequences in the second line):
> > > > PS1="[\${PWD##*/}]\$ "      # set the prompt
> > > > PS1="^[]0;\$PWD^G^M$PS1"    # set the window title
> > > > 
> > > 
> > > Turns out this was the only one buggy.
> > > So it was all the (mis-) googled PS1 customizations,
> > > that are actually incompatible with bash 3.2.0 and higher.
> > 
> > This is just plain wrong in any bash version.  Any part of the prompt that
> > does not cause the cursor to change position needs to be protected inside
> > \[ \].  Thus, the sequence from ESC to BEL on line 2 of your script should
> > be inside \[ \].
> > 
> > Using a CR (^M) probably screws things up as well.  I don't even know why
> > you have that in there.  If you want to ensure the prompt always starts
> > on a new line, use a newline instead of a CR, which will presumably
> > start to overwrite the last line of the previous command's output, if
> > that output doesn't end with a newline of its own.  I would not expect
> > this to be the desired behavior.

CR there cancels \e]0;
LF should indeed be used instead. But the 'bug' would still be there.

Just CR would not change the window title,
and just BEL would prevent both prompt and command being edited from
being displayed.

> > 
> > In any case, you have a working prompt in your original email, so you
> > could just stick with that one.
> 
> Yes. This was all the \[ \] , the lack of them.
> 
> They are bash-specific, and when the ^G^M works in mksh 52
> (somehow not overwriting the previous command), it /looks/ like
> pitfall of the former (which actually is a fast-rendering feature).

The entire .bashrc config worked (after few edits), not just PS1.
And this made it look like bash was mibehaving.

> 
> Nitpicked version control due to non-clean-room testing, therefore.
>