Re: [Bug-readline] Refresh readline notion of terminal size

[Carlos Pita]

Just to let you know. Regarding python:

- ipython 5 is no longer a problem since it has moved to prompt toolkit[1].
- python 3.5.2 fixes the resizing issue (search for #23735):
https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-2

Cheers
--
Carlos

[1] This also applies to many repls moving to jupyter, since jupyter
console is also using pt.

On Thu, Jul 21, 2016 at 4:41 PM,  <address@hidden> wrote:
> On Thu, Jul 21, 2016 at 12:24:57PM -0400, Chet Ramey wrote:
>> On 7/19/16 6:42 PM, address@hidden wrote:
>> > Thanks Chet. I know Python and R have a similar model. I think the
>> > question is not whether it is OK for Readline to take over the
>> > application's signal handling, but whether it was OK for Readline to
>> > catch signals and then forward them to the application - as it was
>> > doing before 6.3.
>>
>> Sigh.  This is a different question.  Readline still does this, as it
>> always has.
>
> It seems we're rehashing old conversations. I think the change that
> you made in 6.3, which I am referring to, was to make Readline no
> longer catch signals outside of rl_callback_read_char(), thus
> requiring application programmers to re-implement Readline's signal
> handlers. I understand that forwarding is still done for signals
> received within this function.
>
>> It was not OK to do cleanup and other processing in a signal
>> handler, so Readline does this now from a function that is not
>> called in a signal handling context.
>
> Yes, there is RL_CHECK_SIGNALS which is not exposed to the application.
> That's why I proposed exposing a function which does the same thing in
> my original message about this:
>
> https://lists.gnu.org/archive/html/bug-readline/2016-04/msg00066.html
>
> This would require all callback interface consumers to make a
> pre-approved 1-line change to their code, not ideal but better than 10
> lines IMHO.
>
> Frederick