Re: Bracketed paste causes readline() to return multiple lines

[Martin Buck]

On Wed, Jan 03, 2024 at 10:37:46AM -0500, Chet Ramey wrote:
> On 1/2/24 7:21 PM, Martin Buck wrote:
> > Thanks for your quick explanation! May I suggest a big fat warning in the
> > docs next to the "single line, no newline" description of readline(), making
> > library users more aware of the fact that they can't rely on always getting
> > just a single line?
> 
> Readline has always been able to return lines with embedded newlines.

I guess I now understand where the confusion is coming from: For you a line
with an embedded newline is a single line whereas I considered that to be
two lines so far. For a newline inserted via quoted-insert your
interpretation really makes more sense if you think about the user's intent,
but for several lines pasted via bracketed-pasted, I prefer mine ;-)

> That's on the application, isn't it? If I can trick an application into
> misbehaving just because I quote a newline, I'd report that as a bug.

Well, calc just wants to read user input line by line. It doesn't know or
care about quoted newlines. A newline - no matter whether quoted or not -
simply ends a line. If that happens in the middle of a command, the
remainder of the command is read from the next line.

When adding readline support to calc, I read readline's documentation and
assumed that readline() returns exactly what calc expects (I just had to add
back the trailing newline which readline removed but calc wanted to see).
The documentation didn't give me a clue that I would have to perform
line-splitting myself. After all, the function I'm calling is named
readline(), not readlines() ;-)
That's how that bug came into existence. 

And that's why I suggested a minor clarification to the documentation to
avoid such misunderstandings. Maybe something like this:


--- doc/rltech.texi.orig        2024-01-05 11:28:53.304293627 +0100
+++ doc/rltech.texi     2024-01-05 12:20:54.159757025 +0100
@@ -86,6 +86,11 @@
 The line returned has the final newline removed, so only the
 text remains.
 
+Note that the "single line without final newline" property is only valid
+for normal user input. There are situations (e.g. bracketed paste,
+quoted-insert) where @code{readline} may return multiple lines and/or a
+final newline, so callers must not rely on this behavior.
+
 If @code{readline} encounters an @code{EOF} while reading the line, and the
 line is empty at that point, then @code{(char *)NULL} is returned.
 Otherwise, the line is ended just as if a newline had been typed.



And if I look at the ugliness of the bugfix I did now for calc, I'd still
vote for a function in libreadline returning input line by line, also in
bracketed paste mode...


> > I can see use in having this on by default, but I'm
> > not so sure about the "don't execute bound functions" part of it.
> 
> Do you think that pasting a set of characters including, say, tabs should
> preserve all the characters in the paste? Or should you drop some of them
> or have them affect the insert position? (I hate to pick on tabs, but that
> was the most common report.)

Call me convinced, tab is actually a good example why you want this.

Martin