interpreter improvements

[Quinn Dunkan]

On Thu, 26 Jul 2001 14:56:41 -0500, Skip Montanaro <skip at pobox.com> wrote:
>
>    Quinn> The other observation is that line editing belongs in the
>    Quinn> terminal emulator or window system, not seperately in every
>    Quinn> single program that runs under it.  If you use a terminal
>    Quinn> emulator with cut and paste and line editing then all programs
>    Quinn> automatically have those features.
>
>As others (including Guido) have observed, having a line editing subsystem
>that knows about the structure of the language you are using can be a boon.
>With readline support I can recall individual lines I've typed at the
>interpreter, however readline knows nothing about Python's block structure,
>so I can't recall entire blocks that correspond to (for instance) "if",
>"for", or "while" statements.

You don't have to know the language to cut and paste and edit blocks, you just
need a mouse and a terminal which doesn't think it's still a teletype.  My
"other observation" above was taking the position that readline is the wrong
solution.  I don't use readline if I can avoid it, and happily cut and paste
and edit blocks in the top level, and then cut and paste them right into
the editor, or the other way around.

It does require turning off the '>>> ' and '... ' prompts (which python won't
let you do without hacking pythonrun.c (I think) which I think is a bug), but
it's my opinion that this is the correct behaviour anyway (no prompt).

It's also convenient for return values to be printed like

2 + 2
#-> 4

since that doesn't mess up a cut and paste and is easily filtered out.


I greatly prefer not building special language-awareness into a mechanism,
because then it can work in a simple and uniform manner for every application
and language that involves text, as opposed to having an ad-hoc intrusive
only-works-on-one-editor complicated and hard to get right mechanism.