Mailing List Archive

[Markus Stenberg]
> At least by my experiences the Emacs mode (at least, two versions I
> tried, 3.75 and whatever came with Python 1.5.2) seems to have tons of
> bugs;

Yes, that would be entirely Barry Warsaw's fault -- pymode had no bugs when
I worked on it, and Barry is a known drug addict. Well, all right, I was
the drug addict, and I lied about Barry -- but I'm sure it's still all his
fault <wink>.

> to be more precise, it seems to think a lot more of my code than should
> be is string (and therefore is green and indentation doesn't work).

Offhand, that sounds like one bug. Try posting a minimal failing example?
Amorphous griping doesn't help. If you searched DejaNews before posting,
you may have noticed that reports of pymode bugs are conspicuous by absence.

things-are-fishier-than-you-suspect-ly y'rs - tim

Tim Peters <tim_one@email.msn.com> wrote:
> [Markus Stenberg]
>> At least by my experiences the Emacs mode (at least, two versions I
>> tried, 3.75 and whatever came with Python 1.5.2) seems to have tons of
>> bugs;

> Yes, that would be entirely Barry Warsaw's fault -- pymode had no bugs when
> I worked on it, and Barry is a known drug addict. Well, all right, I was
> the drug addict, and I lied about Barry -- but I'm sure it's still all his
> fault <wink>.

Barry's a musician, 'nuff said. :-) But he likes Indian food, so he must
be Dutch... do those cancel out? :-)

>> to be more precise, it seems to think a lot more of my code than should
>> be is string (and therefore is green and indentation doesn't work).

> Offhand, that sounds like one bug. Try posting a minimal failing example?
> Amorphous griping doesn't help. If you searched DejaNews before posting,
> you may have noticed that reports of pymode bugs are conspicuous by absence.

WEll, I have noticed some problems with tripple-quoted strings on occasion,
but I see similar problems in other modes, so I THINK it's something to do
with how (x)emacs applie the font-lock-mode parameters.

Chris
--
| Christopher Petrilli ``Television is bubble-gum for
| petrilli@amber.org the mind.''-Frank Lloyd Wright

Markus Stenberg wrote:

> At least by my experiences the Emacs mode (at least, two versions I tried,
> 3.75 and whatever came with Python 1.5.2) seems to have tons of bugs; to be
> more precise, it seems to think a lot more of my code than should be is
> string (and therefore is green and indentation doesn't work).
>
> Funny thing is, it's colored properly when I load file but when I start
> editing some files' some parts, they turn green (comment-ish) and
> indentation starts to suck.
>
> Indentation being fairly neccessary feature for Python coding, is there
> some option I am missing or am I fucked? (read: forced to use vim or
> something)

I can't speak to the intimacy issue, but the python-mode syntax recognition
may be due to having a leading '(' open paren in the first column in one of
your docstrings. If so, emacs' syntax confusion (not to be mistaken for
poor gender identification) can be remedied by escaping the leading open
paren with a '\' backslash, like so:

\(this is what to do with parens in docstrings.)

If it is the problem, well, it's emacs' problem, not pymode. If it's not,
well, do track it down.

Oh, does that bug constitute the "tons" you mention, or were there others?
I never was good at estimating the weight of bugs - all that chiton, you
know.

Ken Manheimer
klm@digicool.com

Ken Manheimer <klm@digicool.com> writes:
> Markus Stenberg wrote:
> I can't speak to the intimacy issue, but the python-mode syntax recognition
> may be due to having a leading '(' open paren in the first column in one of
> your docstrings. If so, emacs' syntax confusion (not to be mistaken for
> poor gender identification) can be remedied by escaping the leading open
> paren with a '\' backslash, like so:

Ah, what's causing that problem?

> \(this is what to do with parens in docstrings.)
>
> If it is the problem, well, it's emacs' problem, not pymode. If it's not,
> well, do track it down.
>
> Oh, does that bug constitute the "tons" you mention, or were there others?
> I never was good at estimating the weight of bugs - all that chiton, you
> know.

Think there is two, as one of my (moderately large) modules has no
docstrings with ('s yet still exhibits that behavior. (ok, I got carried
away, but I was moderately frustrated over the feature :-P)

> Ken Manheimer
> klm@digicool.com

-Markus

--
Markus Stenberg
Finger fingon@mpoli.fi for PGP key -- PGP key id: 1024/5DAC7D21

[Christopher Petrilli]
> ...
> WEll, I have noticed some problems with tripple-quoted strings on
> occasion, but I see similar problems in other modes, so I THINK it's
> something to do with how (x)emacs applie the font-lock-mode parameters.

The Emacs language modes rely on heavy-duty functions written in C to do the
bulk of their parsing. These Emacs parsing functions are configurable, but
not quite configurable enough to capture all of Python's rules. In
particular, triple-quoted strings aren't in their repertoire and can't be
added, so given something like

"""
"Hi!" I'm a doc string
"""

Emacs "sees" it as a sequence of 4 strings with some crap in the middle:

""
"\n "
Hi!
" I'm a doc string\n "
""

elisp is too slow to do the character-at-a-time parsing that would be needed
to fix cases like this, so-- like all other language modes --pymode settles
for what it can get. AFAIK it should *never* screw up in the absence of
triple-quoted strings, though, and you can help it make sense of those by
pretending you're the Emacs C parsing function, using judicious backslash
escapes until you stop confusing yourself <wink>.

you-want-to-see-a-nightmare-try-perl-mode-ly y'rs - tim

I've often noticed that emacs font locking is weird with
TQS's. the strangest thing is that with one TQS, the next
line of code can end up in string color, but if you move
that line of code around by temporarily adding leading
whitespace or moving further down the file, it will change
to regular code fonts without me ever changing the TQS above
it.

while i haven't looked closely at the pymode code, i do
think that emac's fontifying stuff works on a certain
limited amount of context only (in terms of surrounding
characters to the cursor). with such a contstraint, it
seems amazing to me that pymode does as well it does
fontifying stuff.

at any rate, i'll opt for a little sporadic twiddling of
source code over using vi(m) or something anyday.

scott

On 29 Apr 1999 07:48:21 +0300, Markus Stenberg <mstenber@cc.helsinki.fi> wrote:
>Ken Manheimer <klm@digicool.com> writes:
>> Markus Stenberg wrote:
>> I can't speak to the intimacy issue, but the python-mode syntax recognition
>> may be due to having a leading '(' open paren in the first column in one of
>> your docstrings. If so, emacs' syntax confusion (not to be mistaken for
>> poor gender identification) can be remedied by escaping the leading open
>> paren with a '\' backslash, like so:
>
>Ah, what's causing that problem?
>
>> \(this is what to do with parens in docstrings.)
>>
>> If it is the problem, well, it's emacs' problem, not pymode. If it's not,
>> well, do track it down.
>>
>> Oh, does that bug constitute the "tons" you mention, or were there others?
>> I never was good at estimating the weight of bugs - all that chiton, you
>> know.
>
>Think there is two, as one of my (moderately large) modules has no
>docstrings with ('s yet still exhibits that behavior. (ok, I got carried
>away, but I was moderately frustrated over the feature :-P)
>
>> Ken Manheimer
>> klm@digicool.com
>
>-Markus
>
>--
> Markus Stenberg
>Finger fingon@mpoli.fi for PGP key -- PGP key id: 1024/5DAC7D21
>
>

Markus Stenberg wrote:

> Ken Manheimer <klm@digicool.com> writes:
> > Markus Stenberg wrote:
> > I can't speak to the intimacy issue, but the python-mode syntax recognition
> > may be due to having a leading '(' open paren in the first column in one of
> > your docstrings. If so, emacs' syntax confusion (not to be mistaken for
> > poor gender identification) can be remedied by escaping the leading open
> > paren with a '\' backslash, like so:
>
> Ah, what's causing that problem?

I can't recall exactly, but what i've retained is that it's inherent in the
emacs syntax parsing mechanism, and not surmountable in any apparant way by
an application like emacs-mode.

> > \(this is what to do with parens in docstrings.)
> >
> > If it is the problem, well, it's emacs' problem, not pymode. If it's not,
> > well, do track it down.
> >
> > Oh, does that bug constitute the "tons" you mention, or were there others?
> > I never was good at estimating the weight of bugs - all that chiton, you
> > know.
>
> Think there is two, as one of my (moderately large) modules has no
> docstrings with ('s yet still exhibits that behavior. (ok, I got carried
> away, but I was moderately frustrated over the feature :-P)

I've been there! After tripping over the problem a few times (and probably
being told the fix on a few occasions), the last time i did a binary-style
hunt for the culprit by removing and reinserting chunks of text until i
found the line that was responsible. It was a bit painful, but once i
found a repeatable test for the problem i pinpointed the cause, bopped my
forehead and said "that again", and have recognized it since.

If the other file is showing the same symptom without the same cause, i
suggest that you try a similar hunting expedition, and report back the
cause if you turn up anything interesting...

Ken Manheimer
klm@digicool.com

>>>>> "MS" == Markus Stenberg <mstenber@cc.Helsinki.FI> writes:

MS> At least by my experiences the Emacs mode (at least, two
MS> versions I tried, 3.75 and whatever came with Python 1.5.2)
MS> seems to have tons of bugs; to be more precise, it seems to
MS> think a lot more of my code than should be is string (and
MS> therefore is green and indentation doesn't work).

MS> Funny thing is, it's colored properly when I load file but
MS> when I start editing some files' some parts, they turn green
MS> (comment-ish) and indentation starts to suck.

MS> Indentation being fairly neccessary feature for Python coding,
MS> is there some option I am missing or am I fucked? (read:
MS> forced to use vim or something)

Contrary to what Tim says, pymode was so buggy when I got it from him
that I renamed that pile of elisp `perl-mode' and rewrote the stuff
from scratch. Tim being a clever bot embedded himself in three elisp
defuns in the Python 1.5.2 version of the file. If you look at the
code closely you'll see that every 19,453rd time he gets run, he
decides to muck up your syntax coloring "just for the fun of it".

Okay, like Tim I lied too (about the "clever bot" part, and maybe
about the rest of it).

Since you don't say, let me make some educated guesses. Are you
running XEmacs (v20.something or 21.0)? In the code in question, do
you have an open parenthesis in column zero someplace higher up in a
triple quoted string (say a module docstring f'r instance)?

This is a known lose on XEmacs -- but it's not a bug caused by pymode.
XEmacs, and older versions of Emacs, makes an assumption that any
character with `open' syntax (e.g. `(', `[', `{') in column zero
starts a top level definition and thus short circuits X/Emacs'
built-in parsing primitives. Works great for Lisp and C; useless
suckage for Python. Unfortunately, AFAIK there's no way to disable
this in Python buffers under XEmacs.

The clue is the broken font-lockage for comments. This is all
controlled by primitives driven by syntax tables, so there's little
that pymode (or pymode's Legion of Corruptors) can mess up.

So the answer is: don't put open parens in column zero inside triple
quoted strings.

Hope that answers it. If not, hit C-c C-b in a python-mode buffer,
include a complete code sample and recipe for me to reproduce the
problem, and email the message to python-mode@python.org

-Barry

>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

| """
| "Hi!" I'm a doc string
| """

TP> Emacs "sees" it as a sequence of 4 strings with some crap in
TP> the middle:

| ""
| "\n "
| Hi!
| " I'm a doc string\n "
| ""

TP> elisp is too slow to do the character-at-a-time parsing that
TP> would be needed to fix cases like this, so-- like all other
TP> language modes --pymode settles for what it can get. AFAIK it
TP> should *never* screw up in the absence of triple-quoted
TP> strings, though, and you can help it make sense of those by
TP> pretending you're the Emacs C parsing function, using
TP> judicious backslash escapes until you stop confusing yourself
TP> <wink>.

Try something like the following for fun

-------------------- snip snip --------------------
'''Hey! I thought I warned you.
Don't even think about it!
'''
# yikes! Emacs thinks this is a string
# add a turd '
# now we're happy again
-------------------- snip snip --------------------

-B

What bothers me most with the Emacs mode's TQSs is
that editing gets terribly slow if there lots of them (and
they are long).
On each CR, Tab or : the current indent is computed,
which takes *much* longer than outside the String.
Can this be fixed?

Stefan

>>>>> "SF" == Stefan Franke <spamfranke@bigfoot.de> writes:

SF> What bothers me most with the Emacs mode's TQSs is
SF> that editing gets terribly slow if there lots of them (and
SF> they are long).
SF> On each CR, Tab or : the current indent is computed,
SF> which takes *much* longer than outside the String.
SF> Can this be fixed?

It's probably better with XEmacs, which has primitives that
python-mode can use to figure out if it's sitting inside a string or
not. Emacs doesn't have these.

That being said, I've had a few people report such problems but no one
who's been able to send me a code sample so I can profile it. If you
can do this, use C-c C-b to send a python-mode bug report and include
your sample.

-Barry

P.S. Everything you ever wanted to know about python-mode and
font-locking:

http://www.python.org/emacs/python-mode/faq.html

Hey, since I just found out via the current thread that py-mode has
colorizing, I was wondering why I don't have coloring in mine.

Using py-version "3.90"

and

GNU Emacs 20.2.1 (i386-redhat-linux, X toolkit) of Tue Jun 9 1998
on porky.redhat.com

sneaking a look at the message buffer:

Loading python-mode (compiled)...
Loading python-mode (compiled)...done
Local value of py-indent-offset set to 4
Unhighlighting
Done unhighlighting
highlighting 8: ;.*
highlighting 7: hilit-string-find
highlighting 6: ^\s *(def\(un\|macro\|advice\|alias\|subst\)[
] ... \()\|nil\)
highlighting 5: ^\s *(defvar\s +\S +
highlighting 4: ^\s *(defconst\s +\S +
highlighting 3: ^\s *(\(provide\|require\|\(auto\)?load\).*$
highlighting 2: \s *\&\(rest\|optional\)\s *
highlighting 1: (\(let\*?\|cond\|if\|or\|and\|map\(car\|concat\)\
|prog[n1*]?\|while\|lambda\|function\|set\([qf]\|car\|cdr\)?\|nconc\
|eval-when-compile\|condition-case\|unwind-protect\|catch\|throw\|error\)[
]

Colors work in the Java and C++ modes.

--

Greg Green
Boeing IS
http://www.seanet.com/~gpgreen/
work e-mail: gregory.p.green@boeing.com

For some reason you're still using hilite to do your syntax coloring.
You should trash hilite immediately and start using font-lock, which
is standard in Emacs and XEmacs now.

Unfortunately I can't help you much with the transition. I don't use
Emacs and I never used hilite (XEmacs never had it). Check on
comp.emacs or gnu.emacs.help for details.

-Barry