[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: python-mode: make sure output is not eaten
From: |
Slawomir Nowaczyk |
Subject: |
Re: python-mode: make sure output is not eaten |
Date: |
Sat, 26 Aug 2006 14:41:30 +0200 |
On Fri, 25 Aug 2006 18:53:41 -0400
Stefan Monnier <address@hidden> wrote:
#> > 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.
Have you installed the complete patch? Because current version of the
CVS code doesn't quite work for me... it hangs emacs whenever I try
python-send-buffer (I need C-g to get it make it responsive again),
which seems to be related to the "while" loop in python-send-receive
never finishing due to the (local-variable-p 'python-preoutput-result)
in python-preoutput-filter never being true...
I do not understand the purpose of most of your code, so I do not know
how should it be fixed.
In general, I do not particularly like your patch (I am talking about
prompt handling, there are a couple of other things you have changed
which look OK).
I still think
(python-send-string "import emacs")
(python-send-receive "print '_emacs_out ()'")
is cleaner than
(python-send-receive "import emacs; print '_emacs_out ()'")
I do not understand why "command" python-send-command shouldn't contain
newline... It should work just fine with multiple lines, the only thing
which might cause problems is indentation, and even that only if there
is an indented block at the very end.
If you are thinking about conditionally adding one or two newlines after
python-send-string, than the correct condition should be "add double
newline if and only if the last line is indented", IMHO.
I do not understand the purpose of python-preoutput-result variable. It
is used in python-send-receive and in python-preoutput-filter, but those
uses seem unrelated... if I read the code correctly, python-send-receive
will call (make-local-variable 'python-preoutput-filter), but it will
also always call (kill-local-variable 'python-preoutput-filter)... what
is the point of it? And when could testing (local-variable-p
'python-preoutput-result) in python-preoutput-filter make sense?
Also, python-mode-running doesn't seem to be used anywhere.
#> > 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.
I do not think this is the right way to solve the problem. IMHO, the
variable should be called python-inhibit-output and should prevent
*anything* from being printed in Inferior Python buffer -- thus,
functions like eldoc could bind it to 't and we would not need to worry
about them at all.
After all, it doesn't matter how the output of python-eldoc-function
looks like, it should never appear in the comint buffer. And it would
let us simplify the common case of *user* wanting to run Python code.
#> > 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.
I do not quite understand... You never *know* that it is the internal
thingy anyway (try typing "print '_emacs_out'" in the Inferior Python
buffer)...
I do not see the danger of removing the prompt in front of _emacs_out.
--
Best wishes,
Slawomir Nowaczyk
( address@hidden )
If vegetarians love animals so much, why do they eat all their food???
- Re: python-mode: make sure output is not eaten, (continued)
- Re: python-mode: make sure output is not eaten, Slawomir Nowaczyk, 2006/08/22
- Re: python-mode: make sure output is not eaten, Stefan Monnier, 2006/08/24
- Re: python-mode: make sure output is not eaten, Steven Huwig, 2006/08/24
- Re: python-mode: make sure output is not eaten, Steven Huwig, 2006/08/24
- Re: python-mode: make sure output is not eaten, Slawomir Nowaczyk, 2006/08/25
- Re: python-mode: make sure output is not eaten, Steven Huwig, 2006/08/25
- Re: python-mode: make sure output is not eaten, Ken Manheimer, 2006/08/25
- Re: python-mode: make sure output is not eaten, Stefan Monnier, 2006/08/25
- Re: python-mode: make sure output is not eaten, Slawomir Nowaczyk, 2006/08/25
- Re: python-mode: make sure output is not eaten, Stefan Monnier, 2006/08/25
- Re: python-mode: make sure output is not eaten,
Slawomir Nowaczyk <=
- Re: python-mode: make sure output is not eaten, Stefan Monnier, 2006/08/26
- Re: python-mode: make sure output is not eaten, Slawomir Nowaczyk, 2006/08/26
- Re: python-mode: make sure output is not eaten, Stefan Monnier, 2006/08/28
- Re: python-mode: make sure output is not eaten, Slawomir Nowaczyk, 2006/08/30
- Re: python-mode: make sure output is not eaten, Stefan Monnier, 2006/08/30
- Re: python-mode: make sure output is not eaten, Slawomir Nowaczyk, 2006/08/31