[Patches] [ python-Patches-494066 ] Access to readline history elements

noreply@sourceforge.net noreply@sourceforge.net
Mon, 17 Dec 2001 12:00:38 -0800


Patches item #494066, was opened at 2001-12-16 20:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chuck Blake (cblake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access to readline history elements

Initial Comment:
The current readlinemodule.c has a relatively minimal
wrapper around the functionality of the GNU readline
and history libraries.  That may be fine, and since
some try to use libeditline instead it may be the best.

However the current module does not enable any access
from within Python to the libreadline maintained list
of input lines.  The ideal thing would be to actually
export that dynamically maintained C list as a Python 
object.  In lieu of that more complex change, my patch
simply adds very simple history_get() and history_len()
methods.  This is the least one needs to access the
list.  I'm pretty sure the library functions go waaaay
back, probably to the merger of the history and
readline libraries.

This patch also adds one final little ingredient which
is rl_redisplay() in the wrapper for rl_insert_text().
Without this the user cannot see the inserted text
until they type another character, which seems pretty
undesirable.

Together these two updates allow the regular Unix
readline-enabled shell to perform "auto indentation".
I.e., inserting into the edit buffer the leading 
whitespace from the preceding non-result producing
line.  Since it can be editted, one can just backspace
a couple times to reverse the autoindent.

This makes the basic readline-enabled read-eval-print 
loop substantially more pleasant.  I can provide an
example PYTHONSTARTUP file that shows how to use it.
Only a tiny 8 line or so pre_input_hook is needed and
a slightly smart sys.ps1 or sys.ps2 object that
communicates via a variable to our hook function 
whether or not the parser is expecting more input.

----------------------------------------------------------------------

>Comment By: Chuck Blake (cblake)
Date: 2001-12-17 12:00

Message:
Logged In: YES 
user_id=403855

I have something this in my ~/.py/rc.py (STARTUP file).
The just_did_a_result var is also maintained by sys.ps1.

    def auto_indent():
        global just_did_a_result
        if just_did_a_result:
            just_did_a_result = 0
            return
        last = readline.history_get(readline.history_len())
        spc = len(last) - len(last.lstrip())
        if spc > 0:
            readline.insert_text(last[ : spc])
    readline.set_pre_input_hook(auto_indent)

I don't know if you have a system where set_pre_input_hook
is available.  Unless you have access to the history or at
least the very last input line from within Python, then it
doesn't seem very useful.  That is because there is no way
for your input_hook to know when/what it should stuff text
into your command buffer.

The redisplay() is innocuous when it happens to be
unnecessary, so it shouldn't be very objecionable.
It's an interactive prompt so hyper-optimization isn't
very important or noticeable.  Even on a slow terminal
it is only a few characters in one command prompt being
re-drawn.

If it is really an issue, though, then an alternative to
adding my redisplay() fix would be to export another
function from readline to Python, namely rl_redisplay().
Anyone's Python code could then just call it as necessary.

Longer term, it seems like an awful lot more libhistory and
libreadline functionality could profitably be included in 
the readline module.  That's surely a 2.3 or later change,
but the exporting of rl_redisplay() might be a closer step
in that direction.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-17 11:40

Message:
Logged In: YES 
user_id=6380

Hm, I was going to see if the insert_text fix was a simple
enough fix to apply to 2.2, but I don't have an example of
where this is needed. If I call it from the startup hook the
text I insert is already being displayed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494066&group_id=5470