Re: continuation lines

Tim Peters (tim@ksr.com)
Thu, 13 May 93 16:33:58 -0400

I think it's a neat idea. Especially this part:

> ... or initialize lists as follows:
>
> months = ['Jan', 'Feb', 'Mar', # first Q
> 'Apr', 'May', 'Jun', # second Q
> 'Jul', 'Aug', 'Sep', # third Q
> 'Oct', 'Nov', 'Dec'] # fourth Q
>
> (Code using backslashes still works, but note that a line can't have a
> backslash *and* a comment, so there's a definite improvement here.)

I see I've accumulated a lot of initializers like

ix = [ 0x418, 0x280, 0x778, 0x58f, 0x3f1, \
0x0c0, 0x241, 0x7c1, 0x60f, 0x613, \
0x67f, 0x4f7, 0x2cd, 0x425, 0x4d3, \
0x75a, 0x6d8, 0x601, 0x320, 0x1a9, ]

and I bet an embedded comment or two wouldn't have hurt them <snort>.

One downside: it would take a major rewrite of python-mode.el to deal
with this correctly. E.g., now a line is a continuation line if & only
if it's not the first line in the file, and the preceding line ends with
a backslash that's not part of a comment. A simple-enough regexp can
deal with that reliably, & Python mode takes full advantage of that.

When the definition changes to require consideration of bracket nesting
depth too, regexps no longer suffice, and the alternatives are very messy
and/or slow (e.g., look up the docs for parse-partial-sexp, then realize
they explained it as clearly as they could given the function's inherent
complexity <0.9 grin>).

Without such changes, Python mode will treat the new-style continuation
lines as if they were not continuation lines, and that has some
irritating aspects.

too-hard-to-fix-in-the-time-i-can-make-so-i'll-call-it-a-feature<smile>-
ly y'rs - tim, who likes the idea very much anyway