Re: python-mode: make sure output is not eaten

[Stefan Monnier]

> #> Yes, of course.  BTW do you have any idea why the current code uses "\n\n"?

> Not, not really -- it looks to me like an attempt to fix some prompt
> problems which didn't quite work. Or it may be an attempt to have 
> C-c C-s work for indented blocks, as Steven suggested.

I've installed a half-way solution which I believe keeps the old behavior
when needed.

> Not really, at least not in my testing... the problems I am seeing
> come from the fact that when eldoc sends commands, Python responds
> with line that looks like "_emacs_out reload(module)\n>>> " and the
> comint filter needs to remove the trailing prompt as well.

I've added python-preoutput-skip-next-prompt for that purpose.  This way
such prompts should get removed unambiguously.

> OTOH, I like your solution of printing prompt only if there is some
> other output -- seems clean to me.

That's just what was there before (modulo the fact that it didn't catch all
situations).

> You have misspelled command as "comand" in 
>     (defun python-send-command (command)

Thanks.  Fixed.

> Other than that, your patch looks OK to me. Please install, it's
> definitely an improvement.

I've installed a variation of it.  Please fix it as you see fit.

> However, if you change the
>    (string-match "\\`_emacs_out \\(.*\\)\n\\'" line)
> to
>    (string-match "\\`\\(?:>>> \\)?_emacs_out \\(.*\\)\n\\'" line)

> then you do not need to do the trick of augmenting commands with ";
> print" statement: things work just fine if you do python-send-string
> followed by python-send-receive.

Silently interpreting/removing output from the process is always risky,
since the output may appear for other reasons than the ones we expected.
So I'd rather be extra careful to only recognize _emacs_out when I'm sure
it's really the internal thingy.


        Stefan