[IPython-user] Getting IPython working with NTEmacs

Mon Feb 12 23:00:54 CST 2007

If pydb works stand-alone but not with IPython, it could be that Emacs is
not seeing the prompt correctly.  Applying the Debugger.py patch i posted
earlier ensures the prompt is 'ipydb> '.  There is also a bug in
ipython.el.  'pydb-pydbtrack-input-prompt' is incorrectly written as
'py-pydbtrack-input-prompt'.  Try evaluating:

(setq pydb-pydbtrack-input-prompt "\n[(]*ipydb[>)]+ ")  ; not py-pydb..

Hopefully that does the trick.  I think Emacs CVS has switched to python.el.
I'm still using python-mode.el so there may be other issues I'm not aware of.

"Barry Wark" <barrywark@gmail.com> wrote:

> I appologize for the naive question: I've been trying to follow the
> discussion in these threads while setting up my own emacs/ipython/pydb
> environment on OS X (using Carbon Emacs, from Emacs CVS 2007-01-19).
> It's been a long time since I've used emacs, so thigns are _very_
> rusty. Is the issue below related to this discussion or is there a
> known solution? Thanks for helping an emacs re-convert.
>
> Everything is working great, except that I can't figure out how to get
> the buffer containing the source of a .py file to track the current
> line in pydb when its invoked by %debug or %pydb in ipython. When I
> invoke pydb using M-x pydb, the source buffer tracks the current line.
>
> I'm using pydb 1.20 and have applied the diff and changes to
> ipython.el form this thread.
>
> Thanks for the help!
>
> Barry
>
> On 2/12/07, R. Bernstein <rocky@panix.com> wrote:
>> I'd like a couple days to look over.
>>
>> I've long thought the lack of a space at the end of the prompt a
>> little odd since it's different from the way pdb works, if not prompts
>> in general.
>>
>> As for the changes to pydb-pydbtrack-input-prompt, I should double
>> check with what is in pydb.el. I know with Bash debugger GNU Emacs
>> interface, bashdb.el, there's this problem right now where there are 3
>> versions: one that comes with bashdb, one that comes with Bash and one
>> that comes with (or will come with) GNU Emacs. We are working on
>> removing two out of those 3. I hope we don't have a similar problem
>> here with pydb-pydbtrack-input-prompt. Also, recently in the pydb
>> space I've started adding a little unit test for that code. In
>> particular checking over the regular expressions. Probably a little
>> unit test should be added here as well.
>>
>> As for the "run -d" with pydb, originally we were trying to make that
>> work and gave up as a result of reworking all of the extra hackery in
>> ipython that should probably be in pdb, but isn't because pdb doesn't
>> change all that often. So instead %pydb is the preferred way to run
>> pydb. Personally I'd be fine with having "run -d" just invoke pdb (and
>> perhaps give a warning if pydb is around that there is a %pydb magic.)
>>
>> Pydb should be consistent in its use of the output stream. (If not
>> it's a bug, but I don't think is the case for "list".) There are these
>> common routines errmsg and msg which are used for that. This is
>> because you don't know where the output may go, it could go to a
>> socket to a remote process or to a file or over a serial port. I
>> couldn't figure out what the right thing on the ipython side was to
>> get the colors right. So thanks for this.
>>
>> As for pydb's frame output, I generally try to follow gdb, not pdb. In
>> fact it generally *helps* front ends that support multiple
>> languages/debuggers because there is less variation in handling
>> them. That certainly was the case with ddd. It's been helpful also say
>> in Emacs since the same or very similar regular expressions can be
>> used. (However I don't know if the issue here is an ipython formatting
>> issue rather than a pdb versus gdb issue.)
>>
>> Finally I should say that in another day there will be another release
>> of pydb (1.21) it has lots of little usability changes (which I hope
>> will make things much better). Things like better command completion
>> and help using pydoc and automatic Python script resolution for
>> executables. I haven't specifically tested the ipython interaction
>> (yet).
>>
>>
>> Ville M. Vainio writes:
>>  > Can any other ntemacs user give this a spin before I (blindly) commit
>>  > it? Yet again, I don't have access to my win32 machine during
>>  > february.
>>  >
>>  > On 2/11/07, DaveS <davls@telus.net> wrote:
>>  > > I had a few issues getting IPython working smoothly with NTEmacs so I
>>  > > thought I would share my findings.
>>  > >
>>  > > First of all, my setup:
>>  > > NTEmacs 21.3.1
>>  > > Python 2.5
>>  > > IPython 0.7.3
>>  > > pydb 1.20
>>  > >
>>  > > I made some changes to Debugger.py for both pdb and pydb
>>  > > compatibility. (diff attached)
>>  > >  * add trailing space to prompts so emacs sees it. (python 2.5 case)
>>  > >  * set self.prompt for pydb
>>  > >  * pydb writes output to it's out stream in a least one spot (list command)
>>  > >  which causes problems with colours, so I initialized stdout to Term.cout.
>>  > >  This doesn't seems to cause any new problems.
>>  > >  * format_stack_entry was placing the '>' carrot on every frame, which
>>  > >  confused emacs, so I changed it to only place it on the current frame. (I
>>  > >  think plain pdb works this way)
>>  > >  * I tweaked the frame line colours to make things clearer. (this is
>>  > >  subjective but I like it better)
>>  > >
>>  > > A couple of minor items in ipython.el
>>  > >  * (setq py-pydbtrack-input-prompt...  should be
>>  > >  (setq pydb-pydbtrack-input-prompt
>>  > >  * I modified py-traceback-line-re to ignore '>' marked stack frames.
>>  > > (setq py-traceback-line-re
>>  > >            "\\(^[^\t >].+?\\.py\\).*\n   +[0-9]+[^\00]*?\n-+> \\([0-9]+\\)+")
>>  > >
>>  > > Also one minor item.  When using 'run -d' with pydb, no initial breakpoint
>>  > > gets set, so the instruction about using 'c' to start things gives a
>>  > > different result then when using pdb.
>>  > >
>>  > > After making these changes IPython and Emacs are working great together.
>>  > >
>>  > >
>>  > >
>>  > > --
>>  > > DS
>>  > >
>>  > > _______________________________________________
>>  > > IPython-user mailing list
>>  > > IPython-user@scipy.org
>>  > > http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>>  > >
>>  > >
>>  > >
>>  >
>>  >
>>  > --
>>  > Ville M. Vainio - vivainio.googlepages.com
>>  > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
>>  >
>> _______________________________________________
>> IPython-user mailing list
>> IPython-user@scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>>

-- 
DS