On Sun, Jun 21, 2009 at 5:25 AM, Ville M. Vainio <[email protected]> wrote:

>
> However, most people are ok with (and recommend using) annotations like
>
> // --- Construction & destruction


// --- Construction & destruction END


This idea has merit.  It's been discussed before, and it's probably time to
do something about it.

As usual, clones are problematic: they don't get linked properly when
re-reading an @auto file. One solution is to disable the clone command when
the presently-selected node is in an @auto file. Another solution: creating
a table of clones somewhere in the file.  But if people don't like
sentinels, they are not likely to accept this.

Disabling clones isn't perfect: one could switch from @thin to @auto after
creating clones.  However, it's a good compromise--it alerts the user that
there are significant limitations to @auto.

BTW, the same convention supports section references:

    // -- <<section ref>>

I'll put this on the list.

It could be very cheap to support annotations like that, to yield
> 2-level tree (any more levels, and the source code gets confusing).


I see no reason to limit the nesting level, and it would likely be easier to
support a general convention than to keep track of nesting level.

The END part should probably be optional (i.e. starting a new section
> should automatically end the previous section). END would be inserted
> only if the next function was a toplevel one again.


Something like that.  I will probably use something like:

    // ++ Name
    // -- Name

I dislike using END because headlines could end in END.  We could even make
the actual conventions a matter of taste, for the truly fastidious :-)

Edward

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to