[Types-sig] A late entry
Thu, 16 Mar 2000 17:58:56 -0500 (EST)
font-lock is only one of the problems, and even it is only partially
driven by regexps. There are C primitives that handle things like
parsing over a string, comment, or s-expression. These cannot be
taught that a non-embedded unescaped tick opens a string sometimes but
not other times. Having actually implemented support for dual-comment
styles in a single buffer (i.e. /*...*/ and //...\n) I can tell you
that this stuff is really really tricky.
So somebody (not me :) is either going to have to rewrite the syntax
parsing model and primitives from scratch, or throw out anything that
actually uses the primitives. Font-locking is one thing, but there
may be more subtle breakages. I have no idea how well cperl-mode
handles this stuff, but they've already been down that road.
You could also argue that Py3K shouldn't have to cater to a 20 year
old technology like Emacs, and you'd probably be right. I'd still
grumble though :) I'd also be interested in seeing what the IDLE
developers think about such syntax changes.
My prediction stands: it'll never get done, even if it were possible.
Meaning, I really don't think it's worth the effort, and I can't
imagine anybody actually spending the time to do it.
>>>>> "JV" == John Viega <John@list.org> writes:
JV> Now that might not be worth the effort, but I'd like to assume
JV> that the emacs problems can be fixed and are worth fixing to
JV> gain a syntax that's more natural to people who are actually
JV> familiar with this stuff. At least, let's please do that for
JV> the sake of discussing these concepts in this thread, because
JV> I get confused very easily :)
Sure! Use whatever notation makes sense for the current discussions.
You're first point is more interesting because I don't think /any/ of
these typing issues will seem natural to the vast majority of Python
hackers. I could be wrong, and besides you know my biases already, so
I'll shut up now :).