On Thu, Apr 28, 2005 at 03:58:37PM -0400, Christos Zoulas wrote:
> In article <20050428193714.GD16676@quartz.newn.cam.ac.uk>,
> Patrick Welche  <prlw1@newn.cam.ac.uk> wrote:
> >On Thu, Apr 28, 2005 at 03:16:43PM -0400, Christos Zoulas wrote:
> >> In article <20050428184753.GC16676@quartz.newn.cam.ac.uk>,
> >> Patrick Welche  <prlw1@newn.cam.ac.uk> wrote:
> >> >libedit/readline.c declares "int rl_catch_signals = 1;". Should
> >> >libedit/readline/readline.h have a corresponding
> >> >"extern int rl_catch_signals;"  ?
> >> >
> >> 
> >> Sure, if it is part of the API...
> >
> >I just know that python's configure.in tests for it ;-)
> >
> >Another thing it tests for is rl_completion_matches, yet
> >
> >% nm -g /usr/lib/libedit.a | grep match
> >000021b4 T completion_matches
> >0000009c D rl_completion_display_matches_hook
> >000022f8 T rl_display_match_list
> >
> >that "completion_matches" looks rather similar...
> 
> I don't know. If you get it working, please send patches :-)

These things never turn out to be that easy ;-)
Sure completion_matches is just the old name for rl_completion_matches, so
that's fine (with associated matching function typedef), but that
innocent looking rl_catch_signals, which also does the trick, seems to
imply that we also have rl_free_line_state, rl_cleanup_after_signal etc.
I also see that readline has a separate signal handler for sigwinch, whereas
we have a signal handler for all which does the right thing for sigwinch..

End result is I pass the configure tests, but fail the build :-/

Anyway, that's all after the first attempt ;-)

Cheers,

Patrick