fill-paragraph and TeX word wrapping in peppy-0.7.0.2
Rob McMullen
wrapping algorithm:
http://www.ics.uci.edu/~eppstein/software.html
which, in case you're interested, is included in a minor update of
peppy: peppy-0.7.0.2 available at www.flipturn.org/peppy. The
fill-paragraph (aka word wrapping) action seems to work reasonably
well -- it knows what comment characters are associated with the major
mode and will fill a comment block and text inside triple quotes in
python mode. C/C++-style comments are coming soon.
Next project other than that is getting the
tab-to-indent/electric-return to work correctly. I've stepped through
the elisp comments in emacs, but it would be cool if there were
something in python already debugged. IDLE has
newline_and_indent_event and smart_indent_event that seem to do the
right thing, but of course that's written for Tkinter. Anyone have an
implementation based on the STC that I can steal^H^H^H^H^Hborrow? I'd
like one that works as well as the emacs version and can handle things
like indenting to the right place in the middle of a list or dict
definition, and what's currently in peppy is little better than just
indenting to the previous line's indentation. Worse, in fact, because
it gets it wrong about 20% of the time.
Rob
Josiah Carlson
>
> Chris Barker pointed me to a python implementation of the TeX word
> wrapping algorithm:
>
> http://www.ics.uci.edu/~eppstein/software.html
Yep, David's implementation works like a charm (he sometimes covers it
in his intro algorithms course, or at least he did the first time I
TA'd for him), though the textwrap module in Python may be what people
expect in terms of "wrap this paragraph of text to X lines".
> Next project other than that is getting the
> tab-to-indent/electric-return to work correctly. I've stepped through
> the elisp comments in emacs, but it would be cool if there were
> something in python already debugged. IDLE has
> newline_and_indent_event and smart_indent_event that seem to do the
> right thing, but of course that's written for Tkinter. Anyone have an
> implementation based on the STC that I can steal^H^H^H^H^Hborrow? I'd
> like one that works as well as the emacs version and can handle things
> like indenting to the right place in the middle of a list or dict
> definition, and what's currently in peppy is little better than just
> indenting to the previous line's indentation. Worse, in fact, because
> it gets it wrong about 20% of the time.
PyPE does pretty well in terms of auto indent on return for Python
code, including the handling of open parens, curly braces, and square
braces (tuple, list, or dictionary definitions). It doesn't so much
handle closing stuff, but that's only because it errs on the side of
doing less work. Someone who wants it to be better could easily add
that handling (there may even be stubs to do so, it's been so long
since I mucked with that code).
- Josiah
Rob McMullen
> Yep, David's implementation works like a charm (he sometimes covers it
> in his intro algorithms course, or at least he did the first time I
> TA'd for him)
Small world!
> PyPE does pretty well in terms of auto indent on return for Python
> code, including the handling of open parens, curly braces, and square
> braces (tuple, list, or dictionary definitions).
I know you do most of your work on Windows, but have you seen this
bizarro error before? I can't get PyPE to turn on the Python lexer
because it's having a problem with Red():
[ Tue Oct 23 21:30:48 2007 ] Style Change failed for python, assuming plain text
Traceback (most recent call last):
File "pype.py", line 4518, in changeStyle
StyleSetter.initSTC(self, stylefile, language)
File "/opt/python/PyPE-2.8.8/StyleSetter.py", line 133, in initSTC
stc.StyleSetSpec(num, style)
File "/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/stc.py",
line 4905, in StyleSetSpec
return _stc.StyledTextCtrl_StyleSetSpec(*args, **kwargs)
PyAssertionError: C++ assertion "Ok()" failed at
../src/gtk/colour.cpp(132) in Red(): invalid colour
I'm at wx 2.8.6.0
Thanks,
Rob
Josiah Carlson
> > Yep, David's implementation works like a charm (he sometimes covers it
> > in his intro algorithms course, or at least he did the first time I
> > TA'd for him)
>
> Small world!
I have a few theories about that, but they aren't quite topical ;)
> > PyPE does pretty well in terms of auto indent on return for Python
> > code, including the handling of open parens, curly braces, and square
> > braces (tuple, list, or dictionary definitions).
>
> I know you do most of your work on Windows, but have you seen this
> bizarro error before? I can't get PyPE to turn on the Python lexer
> because it's having a problem with Red():
Hrm. I've never seen that before. I typically use wxPython 2.8.3.0
ansi on Windows and unicode on linux, though my office Windows machine
either runs 2.8.4.0 or 2.8.4.2 ansi (I can't remember at the moment)
and works just fine. Checking using 2.8.6.0 unicode on Windows seems
to work fine.
Upgrading Ubuntu (6.06) to wxPython 2.8.6.0 unicode from the wxwidgets
apt repository and running PyPE seems to work fine for me. Do you
have any references to 'red' in your stc-styles.rc.cfg? Unless you
have changed the contents of yours, it shouldn't have any (it's the
same one I use all the time). I know it's total blasphemy, but have
you tried the source version on Windows and/or the Windows binaries?
- Josiah
Rob McMullen
> On 10/23/07, Rob McMullen <rob.mc...@gmail.com> wrote:
> > I know you do most of your work on Windows, but have you seen this
> > bizarro error before? I can't get PyPE to turn on the Python lexer
> > because it's having a problem with Red():
>
> apt repository and running PyPE seems to work fine for me. Do you
> have any references to 'red' in your stc-styles.rc.cfg?
It's definitely something to do with the Boa styling, but I can't
pinpoint it. There's nothing obviously wrong with the stc-styles
file, but if I replace it with another one I have lying around, pype
starts (but I must have left something out because I don't actually
get any syntax highlighting). But doesn't give me the error.
> Unless you
> have changed the contents of yours, it shouldn't have any (it's the
> same one I use all the time). I know it's total blasphemy, but have
> you tried the source version on Windows and/or the Windows binaries?
It was the default stc-styles file, so I don't know why it's messing
up on mine. I might upgrade to the latest svn of wxPython and see if
it's still is a problem.
But, I was able to fire up the ol' windows box and try it out. It's
working fine on Windows, and I see that your indent-on-return does the
right thing in lists, dicts, nested structures, and within
continuation lines, so I'll take a look at it. The one thing I might
try to enhance is returning to the base intention level after closing
a continuation line, e.g.:
self.blah(arg1, arg2,
arg3, arg4)
^
where pype places the cursor at the ^ instead of under the 's' after
hitting return after the close paren.
Rob
Josiah Carlson
>
> On 10/24/07, Josiah Carlson <josiah....@gmail.com> wrote:
> > On 10/23/07, Rob McMullen <rob.mc...@gmail.com> wrote:
> > > I know you do most of your work on Windows, but have you seen this
> > > bizarro error before? I can't get PyPE to turn on the Python lexer
> > > because it's having a problem with Red():
> >
> > Upgrading Ubuntu (6.06) to wxPython 2.8.6.0 unicode from the wxwidgets
> > apt repository and running PyPE seems to work fine for me. Do you
> > have any references to 'red' in your stc-styles.rc.cfg?
>
> It's definitely something to do with the Boa styling, but I can't
> pinpoint it. There's nothing obviously wrong with the stc-styles
> file, but if I replace it with another one I have lying around, pype
> starts (but I must have left something out because I don't actually
> get any syntax highlighting). But doesn't give me the error.
Do you restart PyPE? Do you switch to some other syntax highlighting,
then switch back to Python?
> > Unless you
> > have changed the contents of yours, it shouldn't have any (it's the
> > same one I use all the time). I know it's total blasphemy, but have
> > you tried the source version on Windows and/or the Windows binaries?
>
> It was the default stc-styles file, so I don't know why it's messing
> up on mine. I might upgrade to the latest svn of wxPython and see if
> it's still is a problem.
>
> But, I was able to fire up the ol' windows box and try it out. It's
> working fine on Windows, and I see that your indent-on-return does the
> right thing in lists, dicts, nested structures, and within
> continuation lines, so I'll take a look at it. The one thing I might
> try to enhance is returning to the base intention level after closing
> a continuation line, e.g.:
>
> self.blah(arg1, arg2,
> arg3, arg4)
> ^
>
> where pype places the cursor at the ^ instead of under the 's' after
> hitting return after the close paren.
That is known and expected behavior ;), where it errs on the side of
doing less work. Technically, in order to be correct in all cases,
one may need to check all previous lines. And for the size of source
files I typically end up editing (and sometimes the way I edit), going
as far back as necessary can cause a noticeable delay (something that
I hate when I'm writing software, which is why I don't use Wing IDE,
and some others).
- Josiah
Rob McMullen
> On 10/24/07, Rob McMullen <rob.mc...@gmail.com> wrote:
> > but if I replace it with another one I have lying around, pype
> > starts (but I must have left something out because I don't actually
> > get any syntax highlighting). But doesn't give me the error.
>
> Do you restart PyPE? Do you switch to some other syntax highlighting,
> then switch back to Python?
Yep, as I mentioned, I just replaced the stc-styles.rc.cfg from the
pype distribution with one from peppy back when I was using the Boa
styling scheme like PyPE does. (I use Editra's styling now, btw.)
Anyway, I found the problem. This missing '#' in the
stc-styles.rc.cfg distributed with PyPE-2.8.8 caused the error, so you
might want to update your source distribution.
$ diff stc-styles.rc.cfg ../tmp/stc-styles.rc.cfg
22c22
< style.python.014=fore:#ffffff,back:000000
---
> style.python.014=fore:#ffffff,back:#000000
> > The one thing I might
> > try to enhance is returning to the base intention level after closing
> > a continuation line, e.g.:
> >
> > self.blah(arg1, arg2,
> > arg3, arg4)
> > ^
> >
> > where pype places the cursor at the ^ instead of under the 's' after
> > hitting return after the close paren.
>
> That is known and expected behavior ;), where it errs on the side of
> doing less work. Technically, in order to be correct in all cases,
> one may need to check all previous lines. And for the size of source
> files I typically end up editing (and sometimes the way I edit), going
> as far back as necessary can cause a noticeable delay (something that
> I hate when I'm writing software, which is why I don't use Wing IDE,
> and some others).
Yeah, there's always some corner case that would cause unacceptable
delay. I figure that emacs does it (mostly) correctly, and if emacs
can do it in elisp without me noticing, the same ought to be possible
in python. :) Heck, emacs didn't have noticeable delay back when I
was running on [insert-dating-myself-hardware-reference-here], so to
do it emacsishly correct should be reasonable.
Rob