[Python-mode] apropos py-bug-numbered-tests
andreas.roehler at online.de
Tue Mar 15 21:55:18 CET 2011
Am 15.03.2011 21:09, schrieb Barry Warsaw:
> On Mar 15, 2011, at 07:47 PM, Andreas Röhler wrote:
>> To tackle remaining bugs, would
>> change some lisp of python-mode.el towards more common
>> forms. For example `py-save' now is as macro
>> `ignore-errors' available.
> The question is cross-Emacsen compatibility, and also compatibility with older
> Emacsen. E.g. how far back does ignore-errors support and does it work with
`ignore-errors' is a compiled Lisp macro
-- loaded from "cl-macs"
(ignore-errors &rest BODY)
Execute BODY; if an error occurs, return nil.
Otherwise, return result of last form in BODY.
That should work.
BTW in cases, XEmacs misses a form, think it's better to implement it
for XE as we have done, rather than maintain python-mode specific forms.
>> Also `py-point' forms IMHO rather obfuscate the code. Did
>> see the explanation for it, but don't think it pays.
> I do like py-point a lot.
Code was more verbose without it, so I do think it
> helps, and should be pretty easy to understand. OTOH, I guess you're doing
> the most work on the code now, so you get to decide. However I wouldn't
> necessarily recommend ripping it all out (IOW, "if it ain't broke, don't fix
>> Do I have green light for such a clean up?
> I'll leave it up to you, with the above caveats.
Listen, Barry: the code is intrinsic for me to an extend, that I don't
know how to fix the remaining bugs mentioned. All these bugs are absent
in the components branch, because it's simplified from the scratch -
more or less...
Tried to backport some solution and could resolve some issues. But again
and again going trapped into some wire.
Obviously no one else could solve that over the years also. That's not a
surprise. We are in some labyrinth, before some gordic knots.
OTOH it's a pleasure for me to see solutions from different sides,
python.el, components- and python-mode. So if you permit, will try to
range things still.
Tell if cannot bear it any longer :-)
>> Would commit every logical step, so it should be easy to
>> revert, should some mistake occur.
> Maybe getting the tests working first would be a good idea? That way, you
> have some baseline to prove that your changes aren't breaking the code. What
> do you think?
More information about the Python-mode