Hello Tom,
>> I was suggesting something much simpler than rethinking readline handling.
>> Does not mean that it is a good idea, but while testing the patch I would
>> have liked the unfinished line to be in the current editing buffer,
>> basically as if I had not typed <nl>.
>
> I did experiment with trying to do that, but I couldn't get it to work,
> even with the single version of libreadline I had at hand. It appears
> to me that readline() starts by clearing the internal buffer. Even if
> we could persuade it to work in a particular readline version, I think
> the odds of making it portable across all the libreadline and libedit
> versions that are out there aren't very good. And there's definitely no
> chance of being remotely compatible with that behavior when using the
> bare tty drivers (psql -n).
Argh, too bad.
This suggests that readline cannot be used to edit simply a known string?
:-( "rl_insert_text" looked promising, although probably not portable, and
I tried to make it work without much success anyway. Maybe I'll try to
investigate more deeply later.
Note that replacing the current buffer is exactly what history does. So
maybe that could be exploited by appending the edited line into history
(add_history) and tell readline to move there (could not find how to do
that automatically, though)? Or some other history handling…
> In practice, if you decide that you don't like what you're looking at,
> you're probably going to go back into the editor to fix it, ie issue
> another \e. So I'm not sure that it's worth such pushups to get the
> data into readline's buffer.
For me \e should mean edit, not edit-and-execute, so I should be back to
prompt, which is the crux of my unease with how the feature behaves,
because it combines two functions that IMO shouldn't.
Anyway the submitted patch is an improvement to the current status.
--
Fabien.
