UPDATE: free-layout layout loading
Terry Brown
the current outline was loaded for you), any extraneous panes, i.e.
panes not used by the custom layout, were left off to one side. This
was annoying, but seemed safer than closing them.
On second thoughts, it makes more sense to close them. The free-layout
system already has mechanisms to avoid closing vital panes. Now
switching between layouts does exactly what you'd expect, and doesn't
leave panes laying around the layout if they're not in the layout.
Ironically the itch which prompted this change was better solved by
another approach. On top of all the short an long term project to-do
juggling I do with Leo, I wanted a *2* pane Leo window to track things
I'm going to do today, particular small tasks which might not be in my
regular todo tracking files, e.g. because someone just walked in to my
office and asked for something.
So basically I wanted a Leo layout like the attached. Initially I used
the new pane closing layout loading behavior to close the tree pane,
and then switched to the tree tab in the log/tab pane. But this was
only so so because every time a log message appeared it hid the tree
tab. So now the layout is Leo's regular 3 pane layout, with the
log/tab pane on the left set to zero width.
Cheers -Terry
mdb
showing Tabs, with one Tab being the 'Body' pane?
I know how to create new panes, ala c.frame.log.selectTab('Test')
but not how to make a pane act as the Body.
Also like to add a pane that shows the node attributes
Terry Brown
mdb <mdbo...@gmail.com> wrote:
> Terry-- can "free-layout" a two panel view with the non tree panel
> showing Tabs, with one Tab being the 'Body' pane?
Yes, particularly after yesterday's change, if you delete the body pane
(right click splitter bar, 'Remove 1 right' or where ever it is) it
will automatically become a tab. After yesterday's change this layout
will load properly (assuming you save it to associate it with an
outline) because it will now delete the Body pane on load, shunting it
to a tab, whereas before it would leave it for the user to do that.
Cheers -Terry
HansBKK
Plus I'm finding the core multiple-body-editors less than stable regarding my cursor position, not too useful when copying and pasting between two very long nodes (sorry OT).
Bit first I want to check it's purely a UI thingie, no content-relevant changes to data structures, no potential consequences if used for a while then disabled?
Are multiple outline panes possible for the same leo file? (I know I don't want much 8-)
Terry Brown
HansBKK <han...@gmail.com> wrote:
> OK my curiosity is overcoming my caution, this may be the first non-default
> plug-in I try.
>
> Plus I'm finding the core multiple-body-editors less than stable regarding
> my cursor position, not too useful when copying and pasting between two
> very long nodes (sorry OT).
>
> Bit first I want to check it's purely a UI thingie, no content-relevant
> changes to data structures, no potential consequences if used for a while
> then disabled?
free_layout itself has no data consequences. But it's most useful when
you're arranging other plugin panes, it allows you to arrange the core
three panes somewhat more freely, but it doesn't do anything different
multiple-body pane wise.
> Are multiple outline panes possible for the same leo file? (I know I don't
> want much 8-)
Nope - Edward feels about multiple outline panes the way I feel about
clones ;-)
Cheers -Terry
HansBKK
free_layout itself has no data consequences. But it's most useful when
you're arranging other plugin panes, it allows you to arrange the core
three panes somewhat more freely, but it doesn't do anything different
multiple-body pane wise.
> Are multiple outline panes possible for the same leo file? (I know I don't
> want much 8-)Nope - Edward feels about multiple outline panes the way I feel about
clones ;-)
How would/do you accomplish what I'm doing without clones? breaking down large texts into chunks and then re-factoring into different org schemes to make sense of it, while leaving the original "data-stream" intact?
Terry Brown
HansBKK <han...@gmail.com> wrote:
> On Friday, December 16, 2011 11:27:11 AM UTC+7, Terry wrote:
> >
> >
> > free_layout itself has no data consequences. But it's most useful when
> > you're arranging other plugin panes, it allows you to arrange the core
> > three panes somewhat more freely, but it doesn't do anything different
> > multiple-body pane wise.
> >
> So is there a "companion" plugin that makes use of free_layout to do so?
Not really. But there are quite a few plugins which create new types
of pane, and free_layout manages these. It also allows more flexible
handling of the three core panes (tree, body, and "log-tabs"), but
doesn't change the way multiple body editors work (splits within one
pane). The stickynotes plugin basically creates extra body editors in
separate windows, but plain text with no highlighting or Leo text
editing features only. The tabula plugin (or perhaps it's just part of
sticknotes) allows many of the stickynote windows to be managed in a
tiled / cascaded / tabbed manager window.
I think that a major step forward for Leo will be more modular body
editors so you can have multiple full fledged syntax highlight Leo key
aware windows where ever you want them.
> > > Are multiple outline panes possible for the same leo file? (I know I
> > don't
> > > want much 8-)
> >
> > Nope - Edward feels about multiple outline panes the way I feel about
> > clones ;-)
> >
> I have to admit the fact that someone of your centrality to Leo doesn't
> make use of what I see as its most compelling feature, has got me a bit
> nonplussed. Do you use it just as a coding IDE? I'm guessing the data
> model, exposure to scripting control are your thing?
>
> How would/do you accomplish what I'm doing without clones? breaking down
> large texts into chunks and then re-factoring into different org schemes to
> make sense of it, while leaving the original "data-stream" intact?
I think the functionality clones provide is extremely useful, I'm just
not so keen on the way they do it. If anything I'd say I view Leo as a
general data management environment more the Edward does. I use if for
light weight project management, bookmark management, web page
generation, and database design, as well as coding.
But I prefer other kinds of links, like UNLs, which can jump between
separate Leo outlines, and in some cases the links provided by the
backlinks plugin. Both are fragile, you can delete the node at one end
of the link without the other end knowing, but because they're not
doing all sorts of gymnastics to maintain their existence, they don't
have unexpected side effects, either.
I'm not exactly sure how I'd do what you're doing, perhaps point to
nodes of interest with lists of UNLs and generate the pointed to
content with some sort of script, if needed. And I appreciate that
clones make it easier to generate thins without resorting to scripting
Leo with python, if that's not your thing.
Cheers -Terry
HansBKK
So when you refer to "other outlines" "any open outline" "separate outlines", are you referring to separate .leo files? I assume that any operations that your plugins enable between separate .leo files can also be used to between separate trees/branches within a given .leo file, but obviously not the other way.
I haven't started actually using multiple .leo files yet, and so far am planning to try to keep everything in one until I hit some sort of performance problem. Is that idea carrying KISS too far? My problem is that my various topic domains have many points of overlap, very rarely does one topic have truly "clean edges", and dealing with changing filepaths seems like one extra headache I'd like to avoid.
Terry Brown
HansBKK <han...@gmail.com> wrote:
> Sorry Terry, just to clarify my understanding, does "outline" in Leo-speak
> always equal ".leo file"?
Well, that's what I meant in that case, I think it's generally what
'outline' means, whereas 'tree' may mean the whole outline, or a
subtree.
> So when you refer to "other outlines" "any open outline" "separate
> outlines", are you referring to separate .leo files? I assume that any
Yes.
> operations that your plugins enable between separate .leo files can also be
> used to between separate trees/branches within a given .leo file, but
> obviously not the other way.
Right, basically the bookmarks plugin and quickmove plugin in setting
up bookmarks are using the UNL (Universal Node Locator?) syntax, a
special kind of Leo centric URL. I think it's in the docs, used to be
a separate plugin but moved into the core.
Cheers -Terry