My point is to distinguish the templating function that's currently
accomplished with "cross-file clones" -- clones within @file branches
-- from the code maintenance function.  I recommend doing that by
keeping clones out of @file branches, and adding @template branches
where clones can be put.

Then the user would explicitly choose between 1) feeding Leo from an
external file by use of @file, letting Leo keep the structure of that
external file while letting you create views on it; and 2) creating
new external files out of pieces of other files by use of @template.
This also separates the two use cases explicitly with distinct @
branch types, making it easier to manage eternal files.  It might
also, though I'm not sure, mitigate "clone wars" because
@template-created external files are separate from @file-maintained
external files, and @template branches might also let you select from
a number of different priority/reconciliation algorithms.

I'm not saying take away any functions from Leo, just distinguish the
function of templating to produce external files derived from other
external files, from the function of maintaining an external file that
isn't built from other files.


Seth

On Thu, Jan 19, 2012 at 6:11 AM, HansBKK <[email protected]> wrote:
> On Thursday, January 19, 2012 3:14:52 AM UTC+7, Differance wrote:
>> The generating content thing is in tension with the fact Leo is a tool for
>> working with external files for a particular kind of purpose: editing code,
>> which is linear and of a nature where things have their (one) place.  You're
>> doing something wrong if you're creating external code files that are
>> designed to have many places update with the same actual textual code, which
>> you are aiming at changing in one location and having multiple places in the
>> external files update textually and redundantly from that.  Code isn't like
>> that: you call a function that resides in its one right place, and update
>> that single instance of that function, not replicate the text of that
>> function all over.
>
>> I tend to think that you have to choose between having a particular
>> purpose in relationship to external files, or putting everything inside the
>> Leo outline (i.e., no more files, just one uniform distributed format that
>> serves in place of all files).  People aren't thinking about making a
>> uniform kind of format like that (everything inside the outline), so it's
>> necessary to decide on the function in relation to external files that Leo
>> is designed for.  Trying to take the function Leo is designed for, and then
>> add all sorts of other things (templating, general graphs), is just going to
>> make the problem of keeping external files and the Leo outline in sync more
>> complex, and possibly create purposes that are at odds with each other or
>> otherwise impossible.
>
>
> --------------------
>
> The most significant advances in technology are rarely used by the audience
> for which they where originally intended, nor solely for their intended use.
> From a completely different context, but not so long ago:
>
> On Wednesday, October 19, 2011 9:24:45 PM UTC+7, Edward K. Ream wrote:
>> Here, I'll summarize, without explanation, what I think Leo is now, or
>> soon will be:
>
>> 1. A premier platform for scripting, programming and searching.
>
>> 2. A completely flexible and arbitrarily expandable filing cabinet for all
>> kinds of (text) data, and by reference, any kind of data.
>
>> 3. A generator/creator of (text) data and documents of all kinds:
>> including, but not limited to, programs, web sites, and .pdf, .html and .tex
>> files.
>
>> 4. A rendering engine for rST, html and svg and other graphics sources, as
>> well as pictures, svg files and movies included by reference.
>
>> 5. A platform for studying, manipulating and verifying complex data,
>> especially computer programs.
>
> ====================
>
> I hope to continue to use Leo for many of these purposes, and hope to be
> able to help make it easier for others to do the same, including those that
> are less able and eager to climb the relatively steep learning curve Leo
> currently presents.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/leo-editor/-/4URS7xiyK60J.
>
> 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.

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