-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Jan 06, 2011, at 09:00 AM, Georg Brandl wrote:
>Okay, I'll have a look at the customization issue. It doesn't appear to affect behavior and I have no idea how to fix it, so I think it shouldn't block your branch. >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'. But with no change to the buffer other than that? Sounds like possibly a bug in Emacs, though I also vaguely recall that font-lock did or does have some maximum limit of buffer size on which it operated. I think this was put in at the time where then-modern machines really couldn't keep up with on-the-fly highlighting. >>>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". Confirmed, and if you change those embedded double quotes to single quotes, the paragraph fills correctly. >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. Me neither with r372. >>>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. Thanks very much for adding the NEWS file! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNJfVrAAoJEBJutWOnSwa/rdEP/i+yMLtXrdvDLDDLJQj8lb2i ra0m5vPsRJ3lx++Y+vEQuiDSK47tg0LZOBprG9L4V+UbO/prQj9VvDYSxxQxKiF4 xbZXSPjzBeEc6SEXKlXceWt/GQTF/8D3481CwAihqsthfC+6qgrUSnfowzW/wJXj eNZUMHOOvBfHBwpWCYXGT0ZO0qMoJ4lbau+GOz/BBNnKYKO0K7+mDrywM6rheibz DLvSbYnUhFlwxQsNDkPDG33K5ZMb9+IOLj9bjBxYzEAP74eD2to1u7rGDKh7Nh+s gT5R30d81LjfYNlAbYx2X7cUwRxPdHeYMGFQtVyTZofgno+P1jYb+ML5QtR5Z2nI lIBFxSRcjEpOe7YOMld0srcRPt3NZkhF3IPU0TLtIic9gpf1fvjCFN/6nrQ1aczQ 10O23KB8gqIrJlX9V8oOnYeaM0n9VNpb/Bo+c4LPjHBe99N5/76HmwLCsa8/FwfT 4Gt06OfSxpLe5C7Ws7jpJH7eUG3ZRmsXy7/xcpPoXue8augVJCwHG+H8rHXYYQ2q cykYWbB6ZNQtKSEO8c7L/BiOx5nLXwbNJwPbTwJ88vtPo0DoIofM/FFNlGX7nVgk 4rXgCtox75NqS5fOzs01i4M9awaO4+Ml5pswhR9LaqXLCjA07exIpBdjsJwIgR3K 1AqOLi2PAnrtGoofO6VW =rdfN -----END PGP SIGNATURE----- _______________________________________________ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
