I am still discovering new implications in the project to replace @file by
@auto, thereby eliminating all (or almost all) sentinels.
This project continues to look like a breakthrough. There are many ways
forward. I see no gotchas at present.
Here are some thoughts relating to doing without sentinels:
===== A change of view
Just contemplating replacing @file with @auto is disorienting. In the @file
way, all aspects of the desired result are specified fully and explicitly
by sentinels. In the @auto way, as much as possible is specified
implicitly. This is a profound difference in attitude. In practice,
though *almost all* sentinels are redundant. Even in @file trees, few
nodes would be different from the nodes created by @auto. I never realized
this before!
===== Special cases
At present, the nodes created by @auto would not be exactly the same as
those created by @file. We would like to allow simple, unobtrusive markup
to make @auto more flexible. I'll say more about markup later.
Here is a more-or-less complete list:
A. Organizer nodes.
B. Nodes that contain more than one function or method.
You could call this a special case of an organizer node.
C. Nodes that contain "extra" text, either at the start of the node or at
the end of a file.
Typically, the extra text consists merely of comment lines preceding a
class, method or object, but sometimes node are preceded by definitions and
followed by assignments. For example:
def foo():
pass
bar = foo
D. Leading and trailing lines of a file.
@first and @last are not needed in @auto trees: they would be inserted
correctly without further ado. However, we might want to "pretty" the
resulting @auto tree with special cases for:
- Shebang lines.
- Opening docstrings (if short).
- Closing code such as:
if __name__ == '__main__':
<< trailing code >>
===== Markup
There are several considerations in the design of markup:
1. It should be simple enough, and rare enough, so as not to distress
non-Leo users. Ideally, the markup would hardly be noticeable.
2. It should be flexible and configurable, to meet the needs of both Leo
users (Leonard and Linda) and non-Leo users (Ned and Nancy).
As a thought experiment, we could even image a pattern language
(alternatively, a set of options) that would allow the *rare* additional
markup to blend right in with Nancy's existing usage.
Eventually, we might even embed options in something like vim's modelines.
For starters, however, we can do prototyping with very simple comments.
You might call them "sentinels light". These comments would be much
simpler than org-mode headlines or exiting Leo sentinels. Here are some
ideas:
#< <<headline>> starts an organizer node.
#<. <<headline>> starts a node containing arbitrary text.
#<+ starts code to be appended at the end of a node.
#<- starts code to be prepended to the start of the next node.
#> ends any of the markup above.
#= <<headline>> Specifies a custom headline for the following node.
*Important notes*:
1. This proposed markup is simply a prototype.
The intention is to adapt Leo to Nancy's already existing coding standards,
not to propose markup that Nancy should follow (or accept).
2. Whatever the form of the markup, it will be much more rare than existing
Leo sentinels. A typical file will contain very few of these kludges.
===== Prototyping
The way forward is to verify that the new @auto read code can duplicate any
outline specified by using the new markup (inserted by the @auto write
code). Once that is verified, we can work on generalizing the markup that
the @auto read code will accept.
Your comments, please.
Edward
P.S. The question of reconstituting clone links based on idea that
headlines carry identity is at least as interesting as the markup issues
discussed here. In some ways, however, clone issues are easier to deal
with, because they do not concern Nancy in any way.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
