-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 outputcontains 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-
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
