Fabien COELHO <coelho@cri.ensmp.fr> writes:
> My point is to possibly not implicitely <return> at the end of \e, but to
> behave as if we were moving in history, which allows editing the lines, so
> that you would get
> psql=> select 1<cursor>
> Instead of the above.
>> I agree it might be nicer if you could do that, but that's *far* beyond
>> the scope of this patch. It would take entirely fundamental rethinking
>> of our use of libreadline, if indeed it's possible at all. I also don't
>> see how we could have syntax-aware per-line prompts if we were allowing
>> readline to treat the whole query as one line.
> 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).
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.
regards, tom lane