On Tue, Feb 24, 2015 at 5:48 AM, <[email protected]> wrote:
>
> Did you try this on Leo itself, having some hundreds of thousands of lines
>>> in one Leo file?
>>>
>>
>> No, because we aren't going to use @clean for Leo.
>>
>>
>> I tried it on a significant project: pylint. Loading a single .leo is
>> fast, regardless of size. I compared loading the entire project with @file
>> vs. @edit, without significant difference.
>>
>>
>
> Does this mean that some projects are not suitable for @clean?
>
It means that some projects are more suitable for @file :-) I've written
about this in the new programming tutorial, but it's not up on the web
yet. Here is the discussion:
QQQQQ
This tutorial discussed @clean first for three reasons:
1. To avoid making excuses for sentinel lines.
2. To brag about the @clean update algorithm.
3. It is often more convenient to avoid sentinels. For example, when I
study other people's code I do the following:
- Create a git repo of the directory to be studied, adding all the source
files and doing an initial commit.
- Use an `import script`_ to create the desired @clean nodes.
- Explicitly save all the imported files using Ctrl-Shift-W
(write-at-file-nodes).
- Use `git`_ diff to ensure that no important changes have been made while
importing the nodes.
- Use git diff to track any changes I make (such as adding tracing or
debugging statements) for the purposes of studying the code.
Using @clean is an essential part of this work flow. The diffs would be
much harder to read if I had imported files into @file trees instead.
Nevertheless, there are advantages to using @file instead of @clean. All
these advantages arise because external files created by @file contain
explicit outline structure.
1. Leo can read @file trees more quickly and without guesses. There is
never any need for you to move ambiguous lines from one node to another.
2. Sentinels allow you to share structure simply by sending the external
file. This is an overwhelming advantage for Leo's developers.
3. A minor advantage: @file makes Leo files smaller. Leo stores the entire
@clean *tree* in the .leo file, but only stores the top-level @file *node*
in the .leo file.
In short: use @clean for most purposes. Use @file when all developers in a
project use Leo.
QQQQQ
What would be the best way to proceed to bring a really large project with
> thousands of files (i.e. Eric or PyQt or only the PyQt documentation) under
> Leo control using @clean?
>
Use a recursive import script. I use this one::
c.recursiveImport(
dir_ = r'C:\Python27\Lib\site-packages\pylint-1.3.1-py2.7.egg\pylint,
kind = '@clean', #'@nosent','@auto','@file',
one_file = False,
safe_at_file = False, # True converts @clean to @@clean
theTypes = ['.py',],
)
> How would the import of such a project work?
> Would Leo decide which files to save with @clean and which files to keep
> outside of Leo?
>
Use the workflow described above in the new tutorial.
The recursive import script above will prompt you for saves when you save
the outline after doing the import. Respond with "cancel" and you will
only save the .leo file, not any of the new @clean trees.
The next time you reload Leo all the @clean trees will be "live". This is
why I recommend creating a git repo on the imported files *first*, before
doing the import. That way you can use git to double-check the imports
and any changes that may have been made.
If you want Leo to appeal to wider audience of programmers Leo should be
> able to import 'legacy' projects without hassle.
>
It's easy and safe with the workflow I have just discussed.
> Nobody likes to work with two development environments: an old one for
> legacy projects, and Leo for new projects.
>
That's why I am so excited about @clean. It allows you to manage legacy
files with Leo without affecting them in any way. Unless you want to.
Edward
--
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/d/optout.
