Bob> Then either it's a bug in readline, or you have some kind of
Bob> local configuration problem. If you search around the Fink
Bob> project and find out that they're applying any patches, let
Bob> me know and I'll see if I can do something, but I'm not going
Bob> to research this further on my own.
Hi Bob,
Just wanted to update you on this. Fernando took a deeper look at
this, and found that a readline macro needs to be set at compile time
to prevent the space from being inserted. This is normally set by the
python configure, which apparently apple does not use
define_macros=[('HAVE_RL_COMPLETION_APPEND_CHARACTER', None)],
The complete post is below. Thanks for taking a look at this.
JDH
From: Fernando Perez <[EMAIL PROTECTED]>
Subject: Re: [IPython-user] Re: OSX tab completion
To: Robert Kern <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Date: Fri, 01 Apr 2005 19:03:27 -0700
Organization: Applied Mathematics, University of Colorado at Boulder
Robert Kern wrote:
>> Robert, does this mean you also have the same problem? I didn't
>> realize that this was a widespread OSX issue. If someone has a
>> definitive solution/answer to this, please let me know so I can add
>> this information to the user's guide for future reference.
> Yes, I have the same problem. I am using my own build of readline
> 5.0. Unless I get more info very soon, this is also the build that
> will be in MacEnthon.
OK, this is definitely controlled by the python build of readline.c.
Here are some pointers. From the Gnu readline manual at
http://cnswww.cns.cwru.edu/~chet/readline/readline.html,
I found this note:
Variable: int rl_completion_append_character
When a single completion alternative matches at the end of the
command line, this character is appended to the inserted completion
text. The default is a space character (` '). Setting this to the null
character (`\0') prevents anything being appended automatically. This
can be changed in application-specific completion functions to provide
the "most sensible word separator character" according to an
application-specific command line syntax specification.
Indeed, in the Python 2.4.1 source tree, in Modules/readline.c, around
line 717 we find:
#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
rl_completion_append_character ='\0';
#endif
Now, a grep of the whole source tree reveals:
planck[Python-2.4.1]> egrep -rn HAVE_RL_COMPLETION_APPEND_CHARACTER *
configure:19433:#define HAVE_RL_COMPLETION_APPEND_CHARACTER 1
configure.in:2861: AC_DEFINE(HAVE_RL_COMPLETION_APPEND_CHARACTER, 1,
Modules/readline.c:487:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
Modules/readline.c:579:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
Modules/readline.c:716:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
Modules/readline.c:858:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
pyconfig.h.in:375:#undef HAVE_RL_COMPLETION_APPEND_CHARACTER
So what appears to occur is that under OSX, for whatever reason,
configure is NOT defining the HAVE_RL_COMPLETION_APPEND_CHARACTER
macro, and hence the rl_completion_append_character is never reset to
'\0'. In this case, as indicated above, the readline library will
default to appending a space.
With this info, it should be possible to track down why under OSX (at
least under certain builds), the HAVE_RL_COMPLETION_APPEND_CHARACTER
macro is not being defined. Worse case, you could just modify
readline.c to make the above change unconditionally, without worrying
about this macro (just strip the ifdef/endif).
Note that this variable is NOT exposed publically by the python
readline API, so this has to be fixed at build time, you can't reset
it later at runtime via any kind of user setting (at least not that I
can see).
I hope this helps some.
Best,
f
_______________________________________________
IPython-user mailing list
[EMAIL PROTECTED]
http://scipy.net/mailman/listinfo/ipython-user
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
