emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: python-mode: make sure output is not eaten
Date: Wed, 30 Aug 2006 18:10:33 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

> #> > Agreed. But why is removing "_emacs_out ()" any more selective than
> #> > removing ">>> _emacs_out ()"?
> #> 
> #> We're talking about "^_emacs_out " vs "^\\(>>> \\)?_emacs_out": clearly
> #> one of the two regexps describes a superset of the other.  If you can
> #> guarantee that it'll always match "^>>> _emacs_out ", then it's
> #> a different question.

> I do not think it is a problem... The following patch seems to work for me:

But in what way is that better?

> #> I see no reason why the two should be so linked.
> python-send-command does very little beyond calling python-send-string.

It did a lot more: it waited for the command to terminate, which involves
monitoring the output, trying to recognize some special pattern in there.

> #> > or python-send-string doesn't work for multiline strings, in which case
> #> > the assert in python-send-command doesn't help at all (as you wrote,
> #> > nothing can call it with multiline command anyway).
> #> 
> #> In python-send-string, multiline strings work.  In python-send-command
> #> multiline strings were very likely to fail because we added "; print ...".
> #> Hence the presence of an `assert' (assertions are of no use to the user,
> #> their only meaning is for the programmer as a form of documentation that's
> #> slightly better sync'd with the code than mere comments).

> In other words, the only reason for the assert is that we have chosen to
> add "; print" instead of sending two commands?

Yup.

> I am not sure what should be printed by python-send-string, but maybe
> simple "print 1" would work best.

If the string is simple/short, then it should be printed, as if the user had
typed it in.

> Yes, but -- IMHO -- this is only due to the bad design decision of
> adding "; print"

;-)

> #> Also adding the assert to python-send-command did not restrict the
> #> user in any way, only the python.el hacker.

> Right. Fine, this is probably not important enough to warrant further
> discussion.

Especially since python-send-command doesn't wait for the command to
terminate any more, so it doesn't add any `print' any more, whether on the
same line or on a separate one.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]