Clones - what people really want...
Terry Brown
thread]
I think [the OP's clone use] is a use of clones that forces you to deal
with rules about what's safe and what's not safe which are easy to
forget or get wrong. This is the same point Edward hit on recently:
http://groups.google.com/group/leo-editor/msg/12b9531a9b3025bb
Most programming languages have import / include mechanisms for
referencing common code. Ditto document generation systems like LaTeX,
DocBook, and rst. There are numerous templating systems for handling
repetition in HTML and similar outputs. Those are safe, DRY compliant
ways of addressing these needs.
*But* they all require specific knowledge - by appearing to offer a
generic solution to these needs which works for multiple output types
(code, HTML, rst, etc.) Leo's clones are very appealing. However I
don't think (Edward?) that was what they were designed / intended for.
Rather, they're intended to provide views / collections / bookmarks of
currently interesting parts of files. Personally I think UNLs are a
safer way of doing that, but clones do it very nicely, as long as you
don't break the rules.
That's where I think these issues about what clones do is coming from.
Perhaps Leo could offer some kind of generic solution by providing some
sort of templating system which could be applied to any text file
output. But it would still require a distinction between source files
and output, or built, files. Kind of cross-file section references.
Cheers -Terry
HansBKK
Perhaps Leo could offer some kind of generic solution by providing some sort of templating system which could be applied to any text file output. But it would still require a distinction between source files and output, or built, files. Kind of cross-file section references.
I've enjoyed using %include- type ("macro"?) syntax elsewhere, and in fact one of my use cases for Leo does use that feature of Txt2Tags, but of course that's being handled "downstream" in the toolchain from Leo.
I believe that specific facility would be a useful alternative to cloning in many cases, but I can't speak to the idea of what a more complete, generic templating system would mean for Leo.
Edward K. Ream
> [egotistical repetition of my posting which was buried in another
> thread]
No problem. We have been discussing a lot lately. The repetition is
appreciated.
> Leo's clones are very appealing [for reducing code repetition] However I don't think (Edward?) that was what they were designed / intended for.
15 years ago I didn't realize that clones (sections) are bad style
compared to functions. So my original intentions and designs have
changed considerably. Also, Python makes it easy to replace sections
by functions returning lists of values. With Pascal and C this is
much less convenient, which tempts people to use sections when they
should not, imo.
> Rather, [clones are] intended to provide views / collections / bookmarks of currently interesting parts of files.
That's how I use clones. As I said, I consider cloned section
definitions to be bad style, especially when used between files.
Of course, html-like languages don't have functions, so something must
be done, regardless of style.
> Personally I think UNLs are a safer way of doing that, but clones do it very nicely, as long as you don't break the rules.
UNL's are indeed a different way of referring to nodes, but clones
have the great advantage of showing all their descendants.
> That's where I think these issues about what clones do is coming from.
>
> Perhaps Leo could offer some kind of generic solution by providing some
> sort of templating system which could be applied to any text file
> output. But it would still require a distinction between source files
> and output, or built, files. Kind of cross-file section references.
Interesting idea. It's likely no accident that templating systems are
so popular on the web, because of the deficiencies of html and xml.
Feel free to discuss ideas for templating in Leo. It might help a lot
of people.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > Perhaps Leo could offer some kind of generic solution by providing some
> > sort of templating system which could be applied to any text file
> > output. But it would still require a distinction between source files
> > and output, or built, files. Kind of cross-file section references.
>
> Interesting idea. It's likely no accident that templating systems are
> so popular on the web, because of the deficiencies of html and xml.
> Feel free to discuss ideas for templating in Leo. It might help a lot
> of people.
Basically something like
"""
Module for doing something
[<[URL for GPL boilerplate text]>]
"""
etc. So '[<[' and ']>]' would be some project level configurable
delimeters, and the "URL" would be some scheme we'd need to flesh out
to reference contents of nodes relative to the current (e.g. children),
relative to the top of this outline, or in other outlines. It should
also allow including non-Leo content, like text files.
It might be more bang for buck to integrate Genshi into Leo
http://genshi.edgewall.org/
*NOTE* Genshi works with plain text too, most of the docs document its
HTML/XML usage.
There's also http://cheetahtemplate.org/ another Python based template
language I'm not familiar with.
I think some combination of these things would address people using
clones to generate output. You can't get away from a source-file /
output-file dichotomy, but I don't think that's so bad for this
application. For people using clones to construct views of source
code, this approach would be irrelevant.
Cheers -Terry
Edward K. Ream
> On Tue, 17 Jan 2012 06:00:40 -0600
> "Edward K. Ream" <edre...@gmail.com> wrote:
>
>> > Perhaps Leo could offer some kind of generic solution by providing some
>> > sort of templating system which could be applied to any text file
>> > output. But it would still require a distinction between source files
>> > and output, or built, files. Kind of cross-file section references.
>>
>> Interesting idea. It's likely no accident that templating systems are
>> so popular on the web, because of the deficiencies of html and xml.
>> Feel free to discuss ideas for templating in Leo. It might help a lot
>> of people.
On second thought, I am skeptical of any such scheme. The problem
isn't in defining a template, the problem is updating the template
based on changes to external files.
The short form of the thought: templates would be easy if we only used @nosent.
But in the world of two-way flow of information (@file, @auto),
templates are not going to work.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> On second thought, I am skeptical of any such scheme. The problem
> isn't in defining a template, the problem is updating the template
> based on changes to external files.
>
> The short form of the thought: templates would be easy if we only used @nosent.
>
> But in the world of two-way flow of information (@file, @auto),
> templates are not going to work.
Only if you're trying to protect people from the "complexity" of a
split between source and output files. I'd argue that that can't be
done without exposing yourself to all sorts of risks from the
(mis)application of clones.
If you accept that what you're editing in Leo are the source files and
when you want the output you 'File->Generate outputs from templates' or
whatever, changes to external files aren't a problem.
The plus for supporting a templating system in Leo is that all these
systems work by rendering some sort of 'context' information in the
template, and in Leo the context could include access to the Leo
outline structure, which would be great leveraging of Leo's data model.
Cheers -Terry
Ville M. Vainio
This reminds me of my earlier valuespace work, and jinjarender plugin. That's all I have time for, in way of comments right now :)
On Tue, 17 Jan 2012 06:00:40 -0600
"Edward K. Ream" <edre...@gmail.com> wrote:
> > Perhaps Leo could offer some kind of generic solution by providing some
> > sort of templating system which could be applied to any text file
> > output. But it would still require a distinction between source files
> > and output, or built, files. Kind of cross-file section references.
>
> Interesting idea. It's likely no accident that templating systems are
> so popular on the web, because of the deficiencies of html and xml.
> Feel free to discuss ideas for templating in Leo. It might help a lot
> of people.
Basically something like
"""
Module for doing something
[<[URL for GPL boilerplate text]>]
"""
etc. So '[<[' and ']>]' would be some project level configurable
delimeters, and the "URL" would be some scheme we'd need to flesh out
to reference contents of nodes relative to the current (e.g. children),
relative to the top of this outline, or in other outlines. It should
also allow including non-Leo content, like text files.
It might be more bang for buck to integrate Genshi into Leo
http://genshi.edgewall.org/
*NOTE* Genshi works with plain text too, most of the docs document its
HTML/XML usage.
There's also http://cheetahtemplate.org/ another Python based template
language I'm not familiar with.
I think some combination of these things would address people using
clones to generate output. You can't get away from a source-file /
output-file dichotomy, but I don't think that's so bad for this
application. For people using clones to construct views of source
code, this approach would be irrelevant.
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To post to this group, send email to leo-e...@googlegroups.com.
To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> This reminds me of my earlier valuespace work, and jinjarender plugin.
> That's all I have time for, in way of comments right now :)
Right, I kept meaning to reference that, but kept forgetting.
http://groups.google.com/group/leo-editor/browse_thread/thread/d37b6f79d5cbaa73
http://groups.google.com/group/leo-editor/browse_thread/thread/31fe09d20ae60791
etc.
valuespace basically increases the granularity of the Leo data model, which increases the complexity of addressing, but also makes the potential for template / substitution things even more interesting.
Ville M. Vainio
Edward K. Ream
> This reminds me of my earlier valuespace work, and jinjarender plugin.
> That's all I have time for, in way of comments right now :)
Thanks for reminding us of these plugins. Here is what I consider to
be the most important part of the jinjarender docstring, as far as
this discussion goes::
Conceptually, [@jinja] acts like @nosent - tree is parsed,
template is expanded and content is written to the file.
As I was saying, having this work like @nosent simplifies matters
greatly. We only have to worry about one-way text generation: from
the @jinja node to the external text, not vice versa. In this case,
clones cause no additional complications (unless you clone an @edit
node containing the *output* file!!)
Edward
Matt Wilkie
I don't understand. I didn't have the concepts of clones, sections,
templates and functions as distinct things in my mind. There were all
more or less synonyms to me.
--
-matt