[IPython-user] Re: XEmacs execute buffers/regions only once

Alexis Gallagher alexis at alexisgallagher.com
Mon Jun 28 19:57:06 CDT 2004


Alexander (and others),

Thanks for the help on my issue with Xemacs + ipython on OS X. (For
those tuning in late, the problem is that xemacs + ipython mode does not
correctly recognize the completion of "process code" commands like
py-execute-*.)

After a couple weeks' break, I'm feeling brave enough to dive into the
debugging of this. And I see no alternative, since the other suggestions
have not panned out. To recap my adventures...:

Alexander Schmolck wrote:

>> Another observation: I just double-checked and I'm getting exactly
>>  the same problem when I run XEmacs in text console with TERM=ansi.
>>  Under that configuration, the colorization of the ipython buffer 
>> within xemacs is a bit off -- in "In [2]:", for instance, only the 
>> "2]:" are colored blue. I'm not sure if this is a clue to XEmacs's 
>> parsing problem.
> 
> 
> Quite possibly (this definitely should not happen)-- maybe something
>  is screwed up with Xemacs/OS X? Is there anybody else on this list 
> who uses the same configuration?
> 
> 
> Could you check what happens in GNU Emacs?
> 

GNU Emacs I have _not_ tried successfully. I installed GNU emacs with
fink (the OS X package manager) but I am quite lost in it and was not
sure how to get its python shell up & running. Any quick tips would be
appreciated.

As for the idea that the ipython mode regexes were failing to match,
that this is why the mode didn't know when processing was done, and that
this was also producing the colorization failure I described, I'm afraid
that theory has taken a dent.

I studied the colorization failure more carefully, and have noted that
it only appears when xemacs is running in a bash shell with a TERM of
"ansi" or "cygwin" -- that is, when I'm ssh'd into the machine in text
mode. But the ipython colorization seems to work fine within xemacs when
it was started under a bash shell with a TERM of xterm-color, even
though the buffer processing still fails in this configuration.

This is a dent in the theory that it's the same regex matching that's
failing in both cases. How could colorization work if the prompt
matching was failing? But it does seem odd that these would be
unrelated problems.

>> And a hypothesis: Is it possible the .el files in 
>> ipython-emacs-0.3.tgz out of psync with ipython 0.50?
> 
> No, I don't think so (ipython-emacs-0.3.tgz is the latest from the 
> ipython webpage, right?)
> 
> I will send you the ipython.el and python-mode.el I personally use, 
> just to absolutely sure. If you check with C-h f python-mode that you
>  are actually using the right file (which, unlike unfiddled 
> python-mode.el should contain lines starting with `ipython'), and you
>  are then I really don't have a clue what the problem might be

I get the same behavior with the .el files you sent me.

> (oh, one other thing you could try running xemacs with -vanilla and 
> loading the stuff by hand; that will make sure that there is no 
> interaction between other configuration options).

I also get the same behavior when I start xemacs -vanilla and then load
the .el files manually. So this confirms the problem is not due to my
init.el, or to a conflict with another package.

So it seems like something specific to OS X, or to XEmacs, python, or
ipython as installed on my machine by the fink package manager.

> [snip & relocated]
> 
> I fear if everything else fails, you will have to debug it yourself 
> by stepping through the code (or inserting 'message's etc). I can't 
> currently see where the problem might come from.
> 

I'm up for that. But I'm not exactly an old hand with elisp. Can you
recommend some likely points in ipython.el for stepping and/or
debugging.

Thanks again for the tips.

All the best,
alexis




More information about the IPython-user mailing list