I think that rl_insert_text and friends can probably only be used from
readline callback functions. So in principle maybe you could make it
work by having an rl_startup_hook that injects text if there is any
to inject. There would remain the issues of (a) is it portable across
a wide range
I wrote:
> Fabien COELHO writes:
>> 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
Fabien COELHO writes:
>> 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
ne 3. 11. 2019 v 20:58 odesÃlatel Fabien COELHO
napsal:
>
> 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
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 .
I did experiment with trying
Fabien COELHO writes:
> My point is to possibly not implicitely 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
> Instead of the above.
>> I agree it might be nicer if you could do that, but that's
Hello Tom,
psql=> select 1...
psql->
I cannot move back with readline to edit further, I'm stuck there, which
is strange.
I don't follow. readline doesn't allow you to edit already-entered lines
today, that is, after typing "select 1" you see
regression=# select 1
regression-#
On Mon, 2019-10-28 at 23:00 -0400, Tom Lane wrote:
> The attached patch teaches psql to redisplay any not-yet-executed
> query text after editing with \e. The fact that you don't get to
> see what you're about to execute has been complained of before,
> most recently at bug #16034 [1]. In that
Fabien COELHO writes:
>> The attached patch teaches psql to redisplay any not-yet-executed
>> query text after editing with \e.
> I've tested this patch. Although I agree that it is an improvement, I'm a
> little at odd with the feature as is:
>psql=> \e
># select 1...
> then:
>
Hello Tom,
The attached patch teaches psql to redisplay any not-yet-executed
query text after editing with \e.
[...]
I've tested this patch. Although I agree that it is an improvement, I'm a
little at odd with the feature as is:
psql=> \e
# select 1...
then:
psql=> select 1...
The attached patch teaches psql to redisplay any not-yet-executed
query text after editing with \e. The fact that you don't get to
see what you're about to execute has been complained of before,
most recently at bug #16034 [1]. In that thread I complained that
we needed some
11 matches
Mail list logo
