Heyas again!Yes, that's it. Yes, that's a downside of that proposal. On the other hand, your example might ALSO have the same interpretation - there's no way to tell the difference, because the difference is in the amount of whitespace on a line. That's why I'd rather have the system ignore empty lines/lines with only space all together.I think that paying to attention to indentation on whitespace-only lines is a long series of hairy bugs waiting to happen. I don't think anyone wants to debug by checking WHITESPACE on blank lines. I sure don't, I make enough mistakes already :-).
But this adds a rather big disadvantage - that you have to care about
the indentation of comments! You can not any longer write foo bar
fie
bar naja
;; FIXME
hehe
muae
; some comment that's to long to fit in the small space to the right
mumu
;;;;;;;;;;;;;;;;;; SOME SPACER ;;;;;;;;;;;;;;;;;;;
naja hehe
Which sometimes makes an awful lot of sense, esp. the FIXME-part...It varies in exactly that way in Python. And I haven't had too much problems with that, except that it makes copy-pasting code into the interpreter hard.Another option I didn't mention was to "ignore whitespace-only lines". That would work well in files, but it would HIDEOUS for interactive use. It'd mean that you would have to enter your NEXT command before reading (and execution) of the previous command, making it CERTAIN that your output will be out-of-sync. And I think it'd be a VERY bad idea for the syntax to vary between interactive and non-interactive use... it's confusing, and makes debugging rough. Another solution would be to add another key-combindation interactively to mean "execute this, I'm done", but that would have the disadvantage of confusing people :( /Egil |
signature.asc
Description: OpenPGP digital signature

