On Wed, Dec 16, 2015 at 2:12 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote:
>>> So I now think that print.c shouldn't be involved at all, and the right
>>> thing to do is just have
Merlin Moncure writes:
> This is working great. Is there anything left for me to do here?
Nope, it's committed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote:
> I did some more experimentation and concluded that actually, this problem
> has nothing whatsoever to do with pager invocations. What seems to really
> be happening is that libreadline activates its SIGWINCH handler only
Tom Lane wrote:
> I did some more experimentation and concluded that actually, this problem
> has nothing whatsoever to do with pager invocations. What seems to really
> be happening is that libreadline activates its SIGWINCH handler only while
> it's being called to collect input, which is fine
Merlin Moncure writes:
> On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote:
>> So I now think that print.c shouldn't be involved at all, and the right
>> thing to do is just have gets_interactive() invoke the resize function
>> immediately before calling
I wrote:
> Merlin Moncure writes:
>> See https://bugs.python.org/issue23735 for background. Apparently
>> this is expected behavior (and we are far from the only ones
>> complaining about it):
>> "And so we reach where we are. If a SIGWINCH arrives while readline is
>> not
Andres Freund writes:
> Hm. rl_reset_screen_size() works well for me. rl_resize_terminal() not
> so much. Apparently the reason for that is that rl_reset_screen_size()
> doesn't set ignore_env to to true when calling
> _rl_get_screen_size(). I've verified that just toggling
I did some more experimentation and concluded that actually, this problem
has nothing whatsoever to do with pager invocations. What seems to really
be happening is that libreadline activates its SIGWINCH handler only while
it's being called to collect input, which is fine in itself, but *it does
Alvaro Herrera writes:
>> I did some more experimentation and concluded that actually, this problem
>> has nothing whatsoever to do with pager invocations. What seems to really
>> be happening is that libreadline activates its SIGWINCH handler only while
>> it's being
Alvaro Herrera wrote:
> I wonder if we're doing the proper things. According to their manual,
> http://git.savannah.gnu.org/gitweb/?p=readline.git;a=blob_plain;f=doc/readline.html;h=9b7dd842764c81ad496c38a2794361cad964ee90;hb=7628b745a813aac53586b640da056a975f1c443e#SEC44
Note: the above link
On Wed, Dec 16, 2015 at 12:06 PM, Andres Freund wrote:
> On 2015-12-16 13:02:25 -0500, Tom Lane wrote:
>> I think the most reasonable way to handle this is to put the
>> call into a new function exported from input.c, where it can be
>> made conditional on useReadline.
>
>
On 2015-12-16 13:02:25 -0500, Tom Lane wrote:
> > If we really want to we could basically directly use
> > _rl_get_screen_size() - which seems to have been present from before
> > 4.0. It's not declared static...
>
> Nah, I don't think we should rely on calling undocumented internal
> readline
On 2015-12-16 12:02:26 -0500, Tom Lane wrote:
> [ squint... ] What readline version are you using, and do you have
> LINES/COLUMNS set in your terminal environment?
libreadline-dev:
Installed: 6.3-8+b4
Both are set - I think bash does that.
> It may be that the echo stuff is not good, but
Andres Freund writes:
> ... based on that I'm inclined to just go with resize - redisplaying the
> query after the pager might be desirable, but I think it's an actual
> behavioural change.
Hmm ... given that we've not printed "Time:" yet (in \timing mode),
I think you're
On 2015-12-16 12:23:28 -0500, Tom Lane wrote:
> It may be that we can't fix this in readline versions that precede the
> introduction of the resize function. Let me go experiment on my pet
> dinosaurs.
I'm not particularly bothered by not supporting old readline versions
here. If we really want
Andres Freund writes:
> On 2015-12-16 12:23:28 -0500, Tom Lane wrote:
>> It may be that we can't fix this in readline versions that precede the
>> introduction of the resize function. Let me go experiment on my pet
>> dinosaurs.
> I'm not particularly bothered by not
On 12/14/2015 01:57 PM, Merlin Moncure wrote:
This may be moot; some testing demonstrated that libedit was not
impacted so it really comes down to having the right readline api call
available. Looking at the code ISTM that libedit resets the terminal
on every prompt.
Did you manage to figure
Andreas Karlsson writes:
> Did you manage to figure out why one was better than the other? The
> differences between the functions seem rather subtle.
I'm a bit suspicious of Merlin's recommendation as well. Looking at
the readline 6.3 sources, it is rl_resize_terminal() not
Hi,
First off: Glad that you investigated, this has been bugging me.
On 2015-12-14 15:57:22 -0600, Merlin Moncure wrote:
> Also, after some experimentation I had better luck with
> rl_reset_screen_size() (vs rl_resize_terminal()) that seemed to give
> more regular behavior with the prompt. So
On 2015-12-16 11:21:53 -0500, Tom Lane wrote:
> It looks to me like what it's doing is repainting the current line
> on the theory that it might be messed up. Since we are, at this
> point, presumably *not* in the middle of accepting a command line,
> that should be unnecessary but also harmless.
On Mon, Dec 14, 2015 at 2:50 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Quick followup: rl_resize_terminal() exists in GNU readline at least as
>>> far back as 4.0 (released Feb 1999). However, it doesn't seem to be there
Merlin Moncure wrote:
> On Tue, Dec 8, 2015 at 2:33 PM, Merlin Moncure wrote:
> > On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
> >> I wrote:
> >>> Merlin Moncure writes:
> The following patch deals with a long standing gripe of
Tom Lane wrote:
> I wrote:
> > Merlin Moncure writes:
> >> The following patch deals with a long standing gripe of mine that the
> >> terminal frequently gets garbled so that when typing.
>
> > Hm. I wonder whether rl_resize_terminal() exists in every iteration
> > of
Alvaro Herrera writes:
> Tom Lane wrote:
>> Quick followup: rl_resize_terminal() exists in GNU readline at least as
>> far back as 4.0 (released Feb 1999). However, it doesn't seem to be there
>> at all in libedit; I don't see it in OS X Yosemite's headers, anyway.
>>
Hello,
The following patch deals with a long standing gripe of mine that the
terminal frequently gets garbled so that when typing. I guess this
problem is entirely dependent on pager settings and your interaction
patterns with the window (in particular, if you tend to resize the
window when the
Merlin Moncure writes:
> The following patch deals with a long standing gripe of mine that the
> terminal frequently gets garbled so that when typing.
Hm. I wonder whether rl_resize_terminal() exists in every iteration
of libreadline and libedit.
On Tue, Dec 8, 2015 at 2:33 PM, Merlin Moncure wrote:
> On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
>> I wrote:
>>> Merlin Moncure writes:
The following patch deals with a long standing gripe of mine that the
terminal
On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
> I wrote:
>> Merlin Moncure writes:
>>> The following patch deals with a long standing gripe of mine that the
>>> terminal frequently gets garbled so that when typing.
>
>> Hm. I wonder whether
I wrote:
> Merlin Moncure writes:
>> The following patch deals with a long standing gripe of mine that the
>> terminal frequently gets garbled so that when typing.
> Hm. I wonder whether rl_resize_terminal() exists in every iteration
> of libreadline and libedit.
Quick
On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
> I wrote:
>> Merlin Moncure writes:
>>> The following patch deals with a long standing gripe of mine that the
>>> terminal frequently gets garbled so that when typing.
>
>> Hm. I wonder whether
30 matches
Mail list logo