About the readline library, too complicated for me -- I'm not a UNIX(tm)
hacker & God willing never will be <0.4 grin>. I noted too with some
dismay that the "Input to Processes" section of the Elisp manual sez
> Some operating systems have limited space for buffered input in a
> PTY. On these systems, the subprocess will cease to read input
> correctly if you send an input line longer than the system can handle.
> You cannot avoid the problem by breaking the input into pieces and
> sending them separately, for the operating system will still have to
> put all the pieces together in the input buffer before it lets the
> subprocess read the line. The only solution is to put the input in a
> temporary file, and send the process a brief command to read that
> file.
That one doesn't seem to be a problem on your or my systems, but
apparently it's an unsolvable problem on some other systems. I find it
hard to imagine that *any* system is too lame to accept one (say) 80-
character line at a time, though!
> >for i in 1,2,3:
> > print i
> >a = b
>
> The problem I see here is that if "a = b" were another for statement
> ...
Point taken. It would be unpleasant for the user (albeit in different
ways) whether you did or didn't display the first loop's output first --
can't win!
> >for i in 1,2,3: print i
> >a = b
> >
> >Python "should have" known that the for loop was a one-liner ...
>
> It isn't, an 'else' clause can still follow on the next line!
Oops <turning red and hanging head in shame>.
> >This [proceeding after an error] bothers me less than the preceding
> >problems. ...
>
> OK, it's a second order problem, but I still don't like it:
Me neither.
> to me, "C-c |" means roughly "try this region". I want it to fail
> as a unit.
Ya, I share that view; it is subtly different from "send the region to
the process" in several respects, though. I should change the docs to
make that clear.
> >Question: A while back you were considering adding a new Python function
> >comparable to the csh "source" (or sh/ksh ".").
>
> You can simulate ". filename" with "exec(open(filename, 'r').read())"
> so after all I don't think you need a separate "source" or "execfile"
> built-in function after all.
Last time this came up, I was concerned about the semantics of name-
resolution inside exec. I.e., that exec'ing a string doesn't always do
the same thing as typing the string in. In the context of code sent
over by py-mode, though, I *think* the local & global namespaces will
always be the same, so that it's not a problem (or may be a problem, but
so subtle that I can't think of how it might fail -- you?).
But you had another objection to the "execfile" approach, and I think it
still holds (we were talking about debuggers at the time):
> [you, in old mail from 13 Jan 92]
> Sure (there even is a trick to get at the caller's name spaces) but
> when reading from a file the debugger gets a fair chance of printing
> source code lines -- the string passed to exec or eval is not saved,
> but filenames are.
So here's file tempfile.py:
1
2
a = 2 +
3
print 'got here'
And here's an Emacs Python buffer in action:
>>> exec(open('tempfile.py','r').read())
Unhandled exception: SyntaxError: invalid syntax
Stack backtrace (innermost last):
File "<stdin>", line 1
>>>
I believe this is an example of the problem you were talking about in
January, right? The error msg isn't helpful.
If instead I'm editing tempfile.py and do a `C-c C-c', the current
version of py-execute-region (you don't have that yet) yields:
>>> ## working on region...
Parsing error: file <stdin>, line 4:
a = 2 +
^
Unhandled exception: SyntaxError: invalid syntax
>>>
and an "Unexpected response from Python -- syntax error?" error msg is
dumped to the echo area.
The line number is off (because of the inserted "if 1:"), and the
leading tab on the offending line will be mysterious too, but even so
it's a much better error msg than we got by exec'ing the file. So in
the absence of another approach, I'd rather take a chance on explaining
the convolutions (the new) py-execute-region undertakes.
in-a-maze-of-twisty-little-passages-ly y'rs - tim