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, <[email protected]> wrote: > On Thu, Jul 21, 2016 at 12:24:57PM -0400, Chet Ramey wrote: >> On 7/19/16 6:42 PM, [email protected] 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 _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
