Check for readline 2.2 features. This should make it possible to
compile readline.c again with GNU readline versions 2.0 or 2.1; this
ability was removed in readline.c rev. 2.49. Apparently the older
versions are still in widespread deployment on older Solaris
installations. With an older readline, completion behavior is subtly
different (a space is always added).
readline in all python versions is configured
to append a 'space' character for a successful
completion. But for almost all python expressions
'space' is not wanted (see coding conventions PEP 8).
For example if you have a function 'longfunction'
and you type 'longf<TAB>' you get 'longfunction '
as a completion. note the unwanted space at the
end.
The patch fixes this behaviour by setting readline's
append_character to '\0' which means don't append
anything. This doesn't work with readline < 2.1
(AFAIK nowadays readline2.2 is in good use).
An alternative approach would be to make the
append_character
accessable from python so that modules like
the rlcompleter.py can set it to '\0'.
[Ed.: I think expecting readline >= 2.2 is fine. If a completer wants
another character they can append that to the keyword in the list.]
This was submitted by Moshe, but apparently he's too busy to check it
in himself. He wrote:
Here is a function in GNU readline called add_history,
which is used to manage the history list. Though Python
uses this function internally, it does not expose it to
the Python programmer. This patch adds direct interface
to this function with documentation.
This could be used by friendly modules to "seed" the
history with commands.
This patch allows the readline module to build cleanly with GNU
readline 4.2 without breaking the build for earlier GNU readline
versions. The configure script checks for the presence of
rl_completion_matches in libreadline.
always:
- #undef HAVE_CONFIG_H (because otherwise chardefs.h tries to include
strings.h)
- #include readline.h and history.h
and we never declare any readline function prototypes ourselves.
This makes it compile with readline 4.2, albeit with a few warnings.
Some of the remaining warnings are about completion_matches(), which
is renamed to rl_completion_matches().
I've tested it with various other versions, from 2.0 up, and they all
seem to work (some with warnings) -- but only on Red Hat Linux 6.2.
Fixing the warnings for readline 4.2 would break compatibility with
3.0 (and maybe even earlier versions), and readline doesn't seem to
have a way to test for its version at compile time, so I'd rather
leave the warnings in than break compilation with older versions.
This fixes the first half of bug #110611: the immediate exit when ^C
is hit when readline and threads are configured.
Also added a new module variable, readline.library_version.
handlers "return void", according to ANSI C.
Removed the new Py_RETURN_FROM_SIGNAL_HANDLER macro.
Left RETSIGTYPE in the config stuff, because it's not clear to
me that others aren't relying on it (e.g., extension modules).
and a couple of functions that were missed in the previous batches. Not
terribly tested, but very carefully scrutinized, three times.
All these were found by the little findkrc.py that I posted to python-dev,
which means there might be more lurking. Cases such as this:
long
func(a, b)
long a;
long b; /* flagword */
{
and other cases where the last ; in the argument list isn't followed by a
newline and an opening curly bracket. Regexps to catch all are welcome, of
course ;)
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
new:
readline.get_begidx() -> int
gets the beginning index in the command line string
delimiting the tab-completion scope. This would
probably be used from within a tab-completion
handler
readline.get_endidx() -> int
gets the ending index in the command line string
delimiting the tab-completion scope. This would
probably be used from within a tab-compeltion
handler
readline.set_completer_delims(string) -> None
sets the delimiters used by readline as word breakpoints
for tab-completion
readline.get_completer_delims() -> string
gets the delimiters used by readline as word breakpoints
for tab-completion
fixed:
readline.get_line_buffer() -> string
doesnt cause a debug message every other call
Purify) being caused by a bug in the readline library. Nothing we can
do about it.
Cause: readline_initialize_everything() throws away the return value
from rl_read_init_file(), but that happens to be the last reference to
a dynamically allocated char*.
save and restore the tstate, but explicitly calling
PyEval_SaveThread() does reset it! While I think about how to fix
this for real, here's a fix that avoids getting a fatal error.
set_completer(function)
parse_and_bind(string)
read_init_file(filename)
The first is the most exciting feature: with an appropriate Python
completer function, it can do dynamic completion based on the contents
of your namespace!
Guido van Rossum
Martin v. Löwis
Mark Hammond
Skip Montanaro
Neal Norwitz
Neil Schemenauer
Andrew MacIntyre
Michael W. Hudson
Tim Peters
Marc-André Lemburg
Fred Drake
Moshe Zadka
Andrew M. Kuchling
Thomas Wouters
Peter Schneider-Kamp
Barry Warsaw