It looks like a simplification to @+others and @+ (aka @+<<) sentinels
will actually be something of a bug fix. This has turned out to be a
fairly picky topic. Feel free to ignore it--as I explain near the end
the proposed change is not likely to cause anyone any trouble.
Presently, Leo goes to great lengths to preserve the "spelling" of
whitespace that appears before @others directives and section
references. For example, in both the old and new schemes, if the
@others directive is indented by four spaces, the corresponding @
+others directive is
#@ @+others
while if the @others directive is indented (in the body text) by a tab
the @+others directive is:
#...@\t@+others
This seems strange, if not an outright bug. Indeed, Leo typically
"regularizes" leading whitespace in lines, and this convention
subverts this practice. The effect is, in practice, to insert hard
tabs in several places in Leo where imo they do not belong.
I inserted a trace in at.readStartOthers (the code that reads @+others
directives) that reports when the spelling of the whitespace following
the @# does not match the additional whitespace preceding the @#. At
present, there are two such hard tabs in the external code files in
leoPy.leo. In neither case are the tabs welcome.
I was actually surprised that leoPy.leo contains *any* hard tabs. I
shouldn't have been. Leo does, in fact, keep its hands off user
text. Leo "regularizes" only indentation that arises from outline
level. Besides the two hard tabs preceding @others directives,
leoPy.leo contains several other hard tabs. They could/should be
eliminated, but that would be *my* choice, not Leo's.
The argument for preserving whitespace before @others directives and
section references is as follows. At present, Leo does, in fact,
allow the user to insert hard tabs in leading whitespace, or anywhere
else. The convention is "consistent" in preserving *user-defined*
whitespace.
But this argument is wrong. True, Leo preserves the spelling of
whitespace for the @others line itself, but it *regularizes* the
indentation of following lines that results from the indentation of
the @others node. I have just double-checked this assertion: the hard
tab in front of an @others directive in leoGlobals.py does not cause
any other hard tabs to be inserted in the lines in the range of the
@others directive.
For example:
\...@others
indents (with @tab_width -4 in effect) all nodes in the range of the
@others with additional four *blanks*. So only the spelling of the
@others line itself gets preserved(!!)
Analogous remarks apply to section references.
In short, some case could have been made ages ago for preserving the
spelling of indentation of nodes in the range of @others directives
and section references, but this has never been done, and in fact I
see no possible reason to do so. This being so, it does not make any
sense to go to great lengths to preserving leading whitespace for the
@others or section references lines themselves.
These various details only became clear as I wrote this note. It
seems clear, now, that nobody is likely to object to dispensing with
this bizarre convention because it can not now have any possible
benefit.
OTOH, there *is* a benefit of dispensing with the convention when
writing new sentinels: it makes @+others and @+ sentinels better
looking. As always, I won't consider changing how *old* sentinels are
written: we absolutely must allow old versions of Leo to read old
sentinels!
In short, new sentinels provide the one and only chance to clean up
Leo a bit.
All comments welcome, though I don't expect many :-)
Edward
P.S. Sometimes I think my Leo life is taken up with mostly trivia,
but that's just the nature of programming. The details simply must be
handled with care.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
