Re: [Python-mode] Time for a new release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Jan 07, 2011, at 12:24 PM, Georg Brandl wrote: 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. OK, it is now merged. Cool, thanks. Meanwhile, I found the bug -- I was trying to do too much at once. But please do test the solution as well. I've got r374 and will test it with real world code over the next few days. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNJzYQAAoJEBJutWOnSwa/Q7QQAI4lnzTNbfKhYsp0uGDQcj7N qHtA0zR8oD32KAc6GauWpTJBF/Y4tGkssshLgZ0PVgsEdcUGXyWjNPCWVDeYFBTf pA4ZFSct/8+gGCIukCRtT9RjvuxCSTnbmWxH6ngiaezFv6xSGOtcJwjnecPxtPt2 nSoJ+b0FQA9YyBjFqbrnKKNHel8M0TKFbuv3VGa/P6qy+GobBLdA9/OOzvbP41rs ZrK0OIbBjQdZ+DV6of2CYs2fcq5ojLfa0QbNPqvUexPso4vNxGCrMAU3Y4Q+I9ze xkM9siPrbHinjSiQ+mR+3bzIcj3Nfhbe23R4ul3gpu1dMbeIj6z60bODUv0SJyr2 kK/bCSAmI+k6c+74ETcx5fgDONkyZ4Vz7iPbTsshp2XVUY+ehASgYbKuDkYzeZwM /nSc2/lFiP4Guly/fQdkBfXhnbzRqka72XJGOfLblUlsrnd8BWijY+1dKxhMIFQo hjVDiuTxSJZ0wHX8aGUZHKcLoRjhgjNy62N/lYDd62FPVQplEMxyqd2HrzXDvOfY eHqb0wozB0AAqJ3wGtgDmgFx3EvZKIF0QpBAUaYmG0FQcEE3OehfpF9mkXPThVfW 0+eKEYZzYPoHiRl0CHiWZsYj795NxEehgF3HiFWdiDyHJVJARfKc3vWKyavn+x6M V37/1oywiJPrxFEi0jjO =3EwK -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Time for a new release?
-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
Re: [Python-mode] Time for a new release?
-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 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. 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
Re: [Python-mode] Time for a new release?
Am 05.01.2011 19:45, schrieb Barry Warsaw: Thanks Andreas and Georg for your recent commits to python-mode.el. I wonder if it isn't time to start thinking about an official release, probably of 5.2? Is there anything else anybody would like to get in, say over the next couple of days? If not, I'd be happy to do a release on Friday, but wouldn't mind if someone else wanted to do it instead. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode Hi Barry, I'm glad seeing python-mode proceeding. As for a release, AFAIU we don't have reached Milestone 5.1.1 yet. Bug #473525 isn't dealt with. Wanted to look at next days. Too for my taste there are much more bugs we could adress an current code base still. I'm pretty sure more triple-quote-string bugs exists. Hopefully I'll be at it next month. Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Time for a new release?
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Georg, On Jan 05, 2011, at 09:58 PM, Georg Brandl wrote: 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? Embed a single-quoted string in a triple-quoted one: This is a single-quoted string inside a triple-quoted one. It does not color properly; the contents inside the single-quoted string are not colored as if it were part of the string. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis Many situations can be clarified by the passing of time. -- Theodore Isaac Rubin ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
