[Python-mode] Time for a new release?

Georg Brandl georg at python.org
Thu Jan 6 09:00:59 CET 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 06.01.2011 00:19, schrieb Barry Warsaw:
> Hi Georg,
> 
> On Jan 05, 2011, at 09:58 PM, Georg Brandl wrote:
> 
>>I have some more changes that I'd like to discuss before committing.  (These
>>are features in my patched version at bitbucket.org/birkenfeld/dotemacs).
> 
>>Basically:
> 
>>* a separate face for class names:  font-lock-type-face is meant for types in
>>  type declarations and therefore usually not a very noticeable face.  For
>>  example I like to have class names underlined, but having
>>  font-lock-type-face underlined looks very odd in c-mode.
> 
>>* a separate face for exception classes: somewhat redundant, but looks nice.
>>  Both for builtin exceptions and any name after a raise or except.
> 
> Both of these sound good to me.  I checked out and tested your branch, and
> reviewed it.  I think there are only two minor issues that need fixing, but it
> otherwise looks good.

Okay, I'll have a look at the customization issue.

>>* special locking for escape sequences and %-formatting codes in strings, like
>>  the equivalent feature in elisp-mode.
> 
>>  (The code seems to have some issues with font-locking buffers, so I'd be
>>  glad for suggestions how to fix it.)
> 
> I'm not sure I understand what the issues are.  I tested it with a few Mailman
> files and it looked okay, though the extra bolding was a little off-putting
> (yeah, I'll be customizing those faces as soon as your changes land :).
> 
> What are the problems?  Not that I'm an expert on all the insane font-lock
> possibilities.

The problem is that after applying this patch, I see larger files
mis-highlighted when I open them and jump to somewhere in the middle of the
buffer (or when the point is placed there automatically on openening, because
that was my last editing position).

Basically, I guess some string boundary isn't recognized, and the highlighting
string <-> code is reversed: code is highlighted as string, and vice versa.
It can be "fixed" by moving point into a correctly highlighted region and
calling `font-lock-fontify-buffer'.

>>* no filling in code (that one is pretty simple, just remove the "fill-
>>  paragraph" in the last condition of py-fill-paragraph).
> 
> +1!  If that's the bug I think it is, it's been annoying me for about a
> bazillion years.  E.g. I want to be able to fill comments for sure, maybe
> strings, but never code.

Yep, that's that.

>>BTW, while looking at this, something is still not quite right with the
>>parsing of triple-quoted string literals... as can be witnessed when filling
>>a TQS with embedded SQS...
> 
> Can you provide an example?

Try filling this string:

"""
The output conforms to the XHTML version 1.0 Transitional DTD
(*almost* strict).  The output "contains" a minimum of formatting
information.  The cascading style sheet "html4css1.css" is required
for proper viewing with a modern graphical browser.
"""

It results in this:

"""
The output conforms to the XHTML version 1.0 Transitional DTD (*almost* strict).
The output"contains" a minimum of formatting
information.  The cascading style sheet "html4css1.css" is required
for proper viewing with a modern graphical browser.
"""

behaving as if the string stopped at the single double-quote before "contains".

The font-locking *seems* to be all-right, however I've still seen an instance
where the text between the single quotes has code-coloring -- cannot reproduce
though.

>>If I can figure out how to do it, I'll commit these changes separately to a
>>private branch on launchpad, so that they can be reviewed.
> 
> Two additional things would be nice if anyone's so inclined.
> 
> * Adding a NEWS file; I don't care how far back into history it goes.
> * Maybe some nice screen grabs of face examples so folks have a visual way of
>   seeing what their font-lock options are.

I'll see what I can do.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0ldrsACgkQN9GcIYhpnLA0RQCdHtQEmfop4YFg0zv8r6H0uA5I
oYEAn21pHlLZllzlnKanPwh76DyGQea3
=HFI+
-----END PGP SIGNATURE-----


More information about the Python-mode mailing list