File in a file

[Terry Brown]

Hi Edward - hope your results are good news.

I noticed

file://leo/core/LeoPyRef.leo#To%20do:4-->@file%20../doc/leoToDo.txt:0-->Wishlist:4-->zz%20Can't%20or%20won't%20do:16-->Can't%20do:0-->bug%20in%20xml%20doc%20parts%20(hard%20to%20fix?):4-->@file%20xmlcommentbug.xml:1

aka

leo/core/LeoPyRef.leo#To do-->@file ../doc/leoToDo.txt-->Wishlist-->zz Can't or won't do-->Can't do-->bug in xml doc parts (hard to fix?)-->@file xmlcommentbug.xml

seems to be a @file in a @file, last one should be @@file maybe?

Cheers -Terry

[Terry Brown]

Also

leo/git/leo-editor/leo/plugins/leoPluginsRef.leo#Notes-->@file leoPluginNotes.txt-->@file test/syntax_error_plugin.py

> Cheers -Terry
>

[Edward K. Ream]

​​

On Mon, Apr 6, 2015 at 11:59 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

Hi Edward - hope your results are good news.

​Thanks.  I survived the test itself, which is cheery :-)
​

 

I noticed

​ [​

​​@file​

​ ​xmlcommentbug.xml] in ​

​[Leo's to-do list]

Good catch. Fixed at dc22643.

- Changed @file to @@file as you suggest.
- Reorganized the can't/won't fix section.  No part of it remains in the wishlist area.
- Removed all Tk bugs!
- Removed all clones from leoToDo.txt.

EKR

[Terry Brown]

On Mon, 6 Apr 2015 13:50:08 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> - Removed all clones from leoToDo.txt.

Interesting... I wasn't going to explain how I found the @file in a
@file, but since you said that...

If you use clones for creating task specific views of code, they're
extremely valuable. If you don't... they tend to be a nuisance. For
example making searches in the Nav pane much less informative. Nav
pane searches are also negatively impacted by @persistence, and
Recovered Nodes.

So I was writing a script to remove all three of those things (clones,
@persistence, Recovered Nodes), and I thought at one point I'd want to
do it by removing clones outside files, which would passively and safely
remove the clones inside files, but that distinction proved unimportant.
That's where the @file in @file check came in.

I know I asked this on IRC, but just to be sure: @persistence basically
allows gnx/uA persistence in @auto files, which is very cool, but
basically unnecessary now @clean is here? I haven't looked for a
@setting to prevent @persistence, but I should, it's not helpful for
Nav pane searches.

Cheers -Terry

[Edward K. Ream]

On Mon, Apr 6, 2015 at 2:00 PM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

I know I asked this on IRC, but just to be sure: @persistence basically
allows gnx/uA persistence in @auto files, which is very cool, but
basically unnecessary now @clean is here?

​Yes.  That's the way I see it.  Kent might disagree, since he prefers @auto in some situations.
​

 

I haven't looked for a

​ ​

@setting to prevent @persistence, but I should, it's not helpful for

​ ​

Nav pane searches.

​No setting required. Just delete all @persistence nodes.  Unless I am mistaken :-)

EKR

[Kent Tenney]

I use auto with persistence turned off via setting
@bool enable-persistence = False

so I wouldn't be the one to complain about it going away ...

> --
> 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 leo-editor+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Tue, Apr 7, 2015 at 6:47 AM, Kent Tenney <kte...@gmail.com> wrote:

I use auto with persistence turned off via setting
@bool enable-persistence = False

so I wouldn't be the one to complain about it going away ...

​This setting no longer has any effect.  Presumably you didn't notice​

 

​because the setting inhibited the creation of the @persistence node ;-)

EKR

[Terry Brown]

On Tue, 7 Apr 2015 09:28:00 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

So my interpretation - Leo won't (any more) create a @persistence node
for you, only use it if it already exists?

Cheers -Terry

[Edward K. Ream]

On Tuesday, April 7, 2015 at 9:54:40 AM UTC-5, Terry Brown wrote:

So my interpretation - Leo won't (any more) create a @persistence node
for you, only use it if it already exists?

Correct.  If this isn't correct it's a bug.

EKR

[Edward K. Ream]

On Monday, April 6, 2015 at 2:01:21 PM UTC-5, Terry Brown wrote:

If you use clones for creating task specific views of code, they're
extremely valuable.  If you don't... they tend to be a nuisance.

I've been thinking about this remark ever since you first wrote it.

First, I've been wondering whether bookmarks can take the place of task views.  At present, I don't see how they can.  Terry, maybe you can tell me how.

The rest of this post is an entry in my Engineering Workbook, without any real end product.  Feel free to ignore.

Second, I've been wondering how to improve my clone-based workflow.  The clones in task views are a nuisance!  The same nodes show up over and over again in searches.

I use clone-find-all-flattened (cfa) command all the time.  It's the basis of how deal with truly complex bugs, but now I'm having "creative doubts". Putting up with any nuisance, no matter how seemingly small, quickly becomes unpleasant. Perhaps this is why experienced Leonistas like Terry avoid clones.

So the main question for me is: Is there a way to avoid duplicate hits in the find command?

Perhaps I should have asked this question 15 years ago, but recent improvements have changed my workflow:

1. Command history.  How did we ever live without this?
2. @button whatever @args add preloads "whatever" into the history.
3. I use @button cfa-start-node @args add to customize the cfa command for leoPy.leo and leoPlugins.leo.

This combination make it much easier to use the cfa commands.  More importantly for this discussion, it suggests a new design pattern.

Let's use some magical thinking.  We want Ctrl-F/F3 to prefer clones in a task view to clones in @file trees.  Come to think of it, we want the Alt-G to do the same thing!

This is magical thinking (at present) because clones may be part of several task views.

Perhaps Ctrl-F/F3 themselves can be made smarter, but this could easily turn into an heroic task.

Perhaps the @button cfa nodes could provide hints to the find commands.

That's enough for now.  I'll see if I can convert magic to engineering :-)

Edward

[Kent Tenney]

clones are akin to links in the file system, specifically, hard links.
Documentation often cautions against hard links, they tend to confuse.

What if clones were like symlinks?
When you clone to create a debug view, it would make sense that the view
nodes are not primary, they point to the nodes in the @file tree. 'Find' could
differentiate between nodes and links.

[Terry Brown]

On Wed, 8 Apr 2015 06:57:44 -0500
Kent Tenney <kte...@gmail.com> wrote:

> clones are akin to links in the file system, specifically, hard links.
> Documentation often cautions against hard links, they tend to confuse.
>
> What if clones were like symlinks?

I think clones are hard link like, as you say, and bookmarks are sym
link like - sym links being pointers to somewhere else that may or
maynot exist.

But whereas a bookmarks.py bookmark just teleports you to the node in
its home position, perhaps there could be a kind of sym link node that
has the same headline and content as the node it points to, such that
editing the headline or content of the sym link node changes the target
node, but without going to the target nodes position.

When I was thinking about clones the other day I realized they're very
peer to peer, there's no way Leo can easily distinguish the 'original'
from the 'copy', even though we clearly thing the one in the @<file>
tree is the original and the one in the view tree is the copy.

So there might be ways to allow find to know what to report and what to
skip, but everything that parses the outline would have to make the
same checks against false / duplicate hits.

So the better solution might be to attempt to convince Edward that
bookmarks can take the place of clones for the creation of views :-)

I'm assuming I know what a view is, a collection of nodes pulled from
elsewhere that are collectively the nodes needed to work on a problem.
Bookmarks can certainly handle that application, perhaps I need to make
a better bookmark video.

Cheers -Terry

[Kent Tenney]

On Wed, Apr 8, 2015 at 8:30 AM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:
> On Wed, 8 Apr 2015 06:57:44 -0500
> Kent Tenney <kte...@gmail.com> wrote:
>
>> clones are akin to links in the file system, specifically, hard links.
>> Documentation often cautions against hard links, they tend to confuse.
>>
>> What if clones were like symlinks?

Continuing the file system analogy ...

>
> I think clones are hard link like, as you say, and bookmarks are sym
> link like - sym links being pointers to somewhere else that may or

> maynot exist.

IE a 'broken link' indicated by a red icon or some such

>
> But whereas a bookmarks.py bookmark just teleports you to the node in
> its home position,

Doesn't this negate the benefits of a view? I imagine a view of nodes
to allow staying in one tree while working with nodes living hither and yon.

perhaps there could be a kind of sym link node that
> has the same headline and content as the node it points to, such that
> editing the headline or content of the sym link node changes the target
> node, but without going to the target nodes position.

Right, same as a symlink, open and edit: the link is a proxy for the node

>
> When I was thinking about clones the other day I realized they're very
> peer to peer, there's no way Leo can easily distinguish the 'original'
> from the 'copy', even though we clearly thing the one in the @<file>
> tree is the original and the one in the view tree is the copy.

Hence the advice to avoid using hard links in the file system

>
> So there might be ways to allow find to know what to report and what to
> skip, but everything that parses the outline would have to make the
> same checks against false / duplicate hits.

if not p.symlink:
do_stuff(p)
else:
continue

[Kent Tenney]

On Wed, Apr 8, 2015 at 8:50 AM, Kent Tenney <kte...@gmail.com> wrote:
> On Wed, Apr 8, 2015 at 8:30 AM, 'Terry Brown' via leo-editor
> <leo-e...@googlegroups.com> wrote:
>> On Wed, 8 Apr 2015 06:57:44 -0500
>> Kent Tenney <kte...@gmail.com> wrote:
>>
>>> clones are akin to links in the file system, specifically, hard links.
>>> Documentation often cautions against hard links, they tend to confuse.
>>>
>>> What if clones were like symlinks?
>
> Continuing the file system analogy ...
>>
>> I think clones are hard link like, as you say, and bookmarks are sym
>> link like - sym links being pointers to somewhere else that may or
>
>> maynot exist.
> IE a 'broken link' indicated by a red icon or some such
>
>>
>> But whereas a bookmarks.py bookmark just teleports you to the node in
>> its home position,
>
> Doesn't this negate the benefits of a view? I imagine a view of nodes
> to allow staying in one tree while working with nodes living hither and yon.

Somewhat analogous to the difference between current 'hyperlinking' and
Ted Nelson's vision of 'transclusion'

hyperlinks send you to content living somewhere else
transclusion pulls content from somewhere else to here

Transclusion is a great pattern, underutilized.

[Edward K. Ream]

​​

​On Wed, Apr 8, 2015 at 8:30 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

When I was thinking about clones the other day I realized they're very
peer to peer, there's no way Leo can easily distinguish the 'original'
from the 'copy', even though we clearly thing the one in the @<file>
tree is the original and the one in the view tree is the copy.

​Yes.  Internally all clones are actually the exact same vnode.

However, we can distinguish between positions of vnodes. A clone in an @file tree could be treated differently from its other clones in other areas. We have only just begun to explore the possibilities.

I've just finished re-watching your bookmarks video.  It's excellent.  Reactions below.

So there might be ways to allow find to know what to report and what to
skip, but everything that parses the outline would have to make the
same checks against false / duplicate hits.

​In my ENB reply in this thread, I mentioned that recent developments re command history have shifted my thinking. This has created an avalanche of ideas.  See below.

​The key idea, imo, is to distinguishing nodes or contexts.​

 

​To repeat, we have only just begun to explore the possibilities.

In effect, @button cfa-Code @args add limits the clone-find-all-flattened command to the top-level code node.

We could apply these ideas to bookmarks!

So the better solution might be to attempt to convince Edward that
bookmarks can take the place of clones for the creation of views :-)

​​You already have, modulo minor concerns. I like how bookmarks work, but I don't like using the mouse to shift nodes. The bookmark pane should not be necessary. Leo's tree is the best organizer possible.

I am going to play around with bookmarks immediately, treating any required mouse clicks as symptoms that bookmark commands are missing. (If they are missing ;-)  In other words, I'll treat the bookmarks pane as a prototype, not as any real limitation of bookmarks themselves.

I could have done this long ago, but now the way forward is much clearer:

1. I want a distinguished context to form the anchor of bookmarks and their commands.  Perhaps it already is possible. Could be done with @button/@command or it could be a side effect of one or more bookmark commands.

This anchor should eliminate mouse clicks from bookmark commands.  The bookmarks-mark-as-source could create the anchor explicitly, if need be.  This command is somewhat similar to bookmarks-mark-as-target. 

2. I want a command to select the "my bookmarks" node in the video.  Say bookmarks-select-source-bookmarks.  Additional ideas below.

3. Once the user selects the container node selected, normal Leo commands can navigate to the desired bookmark.

4. Now I want a bookmark command (it may already exist), say bookmarks-go, to simulate a left-click on the bookmark in the bookmark pane.  Again, no need for the bookmarks pane!

The video shows various manipulations of tags in the bookmark pane.  All could replaced by actions on the child bookmarks of the bookmarks node

The only drawback to using bookmarks is that selecting a bookmark node shows you neither its body pane nor its children.  Otoh, the body text is a great place for description, notes, etc.  Furthermore, renaming bookmark nodes (rather than their target nodes) can be very handy.

5. Pre-loaded, outline-specific commands in Leo's command history amplify the effect of the commands discussed above.  No need for lots of key bindings.

Better, no need to laboriously jump around the outline.  A pre-loaded, outline-specific @button command can simply select the desired bookmark anchor. It's one line of code.

The @button command is dynamic because it is local (outline specific). When my desired set of bookmarks changes, (when I want to focus on another task) I can simply change the target in the @button node. No need to reload the outline. The changes take immediate effect.

This is look promising and easy!  A big day for Leo...

I'm assuming I know what a view is, a

​​

collection of nodes pulled from
elsewhere that are collectively the nodes needed to work on a problem.

​Correct.
​

 

Bookmarks can certainly handle that application, perhaps I need to make
a better bookmark video.

​Your video is fine.  Watching it again at this creative moment was perfect.

​Edward

P.S. There will always be a need for clones, because they really are hard links, which is essential when using clones in a data-oriented way rather than a search-oriented way.

EKR

[Terry Brown]

On Wed, 8 Apr 2015 08:50:46 -0500
Kent Tenney <kte...@gmail.com> wrote:

> > But whereas a bookmarks.py bookmark just teleports you to the node
> > in its home position,
>
> Doesn't this negate the benefits of a view? I imagine a view of nodes
> to allow staying in one tree while working with nodes living hither
> and yon.

So the critical thing here is that bookmarks have their own display
pane, so in the tree you jump to wherever the node really lives, the
bookmark listing pane doesn't change, so you can click the sibling
bookmark to the one you just clicked, which may move the tree somewhere
else entirely, without the list of nodes in your view, the bookmark
pane, changing or moving.

In your post video watching response you talk about wanting to navigate
bookmarks using keys - there are already some commands for that, but I
haven't really tested them for usability - it would be possible to
simply have a `select-bookmark-pane` command after which the cursor
keys and enter do what you expect.

The video's a bit out of date in that (a) bookmarks are now
hierarchical, and (b) have a right-click context menu. And a couple of
soft regressions, clicking in the bookmark pane to create a bookmark
always creates that bookmark at the beginning of the list, no matter
where you click, and nothing stops you adding the same bookmark
multiple times now.

Bear in mind that free_layout can be used to arrange the bookmarks as a
skinny column if preferred.

Cheers -Terry

[Kent Tenney]

OK, just watched the video, I guess I should have before
previous comments ... I'd sound less foolish if.

I can see how well they work, however they introduce several new idioms:
- nodes in a body pane instead of the tree pane
- clicking in one part (empty space) of a body pane to put content there
- clicking in another part (button) of a body pane to change focus
- persisting is called 'layout'
- use of the top secret rclick on border

I want rclick menu to offer 'Bookmarks' option which creates a floating
pane, clicking on which would add the currently focused node.

I want rclick on a button in the bookmark pane to offer 'delete', 'rename' ...

I want Leo to save and restore this pane transparently

[Terry Brown]

On Wed, 8 Apr 2015 11:23:09 -0500
Kent Tenney <kte...@gmail.com> wrote:

> OK, just watched the video, I guess I should have before
> previous comments ... I'd sound less foolish if.
>
> I can see how well they work, however they introduce several new
> idioms:
> - nodes in a body pane instead of the tree pane

They're bookmarks in the bookmark pane, not nodes in a body pane :)

> - clicking in one part (empty space) of a body pane to put content
> there
> - clicking in another part (button) of a body pane to change focus

So should something be done to make it look less like a body pane?
Nothing really springs to mind, although a slightly different
background color would be possible. Slightly different from the body
pane, I mean.

> - persisting is called 'layout'
> - use of the top secret rclick on border

Ok, see below.

> I want rclick menu to offer 'Bookmarks' option which creates a
> floating pane, clicking on which would add the currently focused node.
>
> I want rclick on a button in the bookmark pane to offer 'delete',
> 'rename' ...

That's one of the areas where the video's out of date - bookmarks.py
has a whole bunch of Shift-Alt-Ctrl-Wiggle-Shuffle-Bump-click
qualifiers for different left click operations I could never remember,
and consequently also now has a right click menu with rename, delete,
etc.

> I want Leo to save and restore this pane transparently

So when I first read this I thought - it does, you create and save a
layout and it's restored when you load, it was right there in the
video :-) Then I realized what you mean, you want the layout parts to
be handled by the bookmarks plugin. Again, the video is a little out
of date, the bookmarks-show command sort of does that. Well, the
start of that, anyway, it identifies the current node as the bookmarks
node for the outline and opens a bookmark pane to show / manipulate the
bookmarks.

It should be easy enough to have it check for a layout called
'Bookmarks', create it if it's not found, load it, and set it as the
default for the outline.

Currently free_layout supports manually floating (separating entirely
from the Leo window) panes, but they're not persisted. That's really a
separate issue from bookmarks.

But making the bookmarks plugin automatically create and use a
persistent layout with a bookmarks pane should be straight forward and
a great idea - thanks :)

Cheers -Terry

[Edward K. Ream]

​​

​On Wed, Apr 8, 2015 at 11:23 AM, Kent Tenney <kte...@gmail.com> wrote:

I can see how well they work, however they introduce several new idioms:
- nodes in a body pane instead of the tree pane
- clicking in one part (empty space) of a body pane to put content there
- clicking in another part (button) of a body pane to change focus
- persisting is called 'layout'
- use of the top secret rclick on border

​Despite Terry's answers to this, I have similar concerns.

In fairness to Terry, is a hard design problem, and potentially a lot of work.

Let's do a thought experiment.

Suppose the bookmark pane looked and worked like Leo's existing outline pane, except that the nodes were bookmarks. Let's call this the bookmark outline pane. Optionally, there could be a bookmark body pane, containing data associated with each bookmark: notes, explicit UNL's to the target node, whatever.

How useful would this be?

There would be many advantages.  The appropriate key bindings would be in effect, so one could navigate, expand and collapse, organize, create and destroy nodes as usual.  Creating a node would, presumably, create a bookmark.  You get the idea.

Navigating the bookmark

​outline pane would select the corresponding node in the main outline, which would update the main body pane. If the bookmark outline pane also contained a bookmark body pane, this pane too would automatically update. Important: when navigating the bookmark pane, focus would stay in the bookmark pane even though the nodes in the outline pane are also being selected.

This is pretty much the way present bookmarks plugin works.  In particular, selecting a node in the outline shows that node in context, a very good thing.

Despite all the coolness just described, this platinum design has a few drawbacks.

1. This design takes a lot of real estate.  I hadn't originally intended to mention it, but the design is looking good enough that it now seems important to point out this drawback explicitly. :-)

2. This design implies constant switching back and forth between the main outline and the bookmark outline. A new toggle-active-outline-pane command would work, but we would be using it a lot.

3. It's easy to blithely talk about how focus will stay in the bookmark panes while also Leo selects nodes in the body pane, but this will be very difficult to do.  We are talking about messing with some of the most complex logic in all of Leo.  The present bookmarks plugin finesses this problem by never having focus :-)

Summary

This design could work. When I started this reply I didn't realize how good it could be.  It would take lots of real estate, and lots of tricky code, but it's not out of the question.

Leo's history might have been very different had I started with bookmarks instead of clones.

However, there is another question to ask.  Is it possible to improve Leo's find commands to eliminate unwanted hits during searches?  I'll discuss this in another thread.

Edward

[Edward K. Ream]

On Thursday, April 9, 2015 at 3:41:43 AM UTC-5, Edward K. Ream wrote:

Leo's history might have been very different had I started with bookmarks instead of clones.

However, there is another question to ask.  Is it possible to improve Leo's find commands to eliminate unwanted hits during searches?  I'll discuss this in another thread.

Before going there, I should ask:

Can we use Leo's existing outline pane instead of the bookmarks pane?

Well, clearly we could.  However, the present plugin doesn't seem oriented for this mode of operation.  I would have expected the bookmarks-bookmark command to add an @bookmark node as a child of the @bookmarks (plural) node if the @bookmarks node exists.  This could be done easily.

Alas, there is no way to "half-select" the target of bookmark while keeping the selected @bookmark node selected :-)  So navigating the @bookmarks tree won't be as useful as in the platinum design. 

As a workaround, the bookmarks plugin could define the bookmarks-toggle-context command that would switch between the last selected node in the @bookmarks tree and the last selected node outside the @bookmarks tree. This is an example of using context to our advantage.  It might work pretty well and could be done easily.

This "gold" design could deliver most of the advantages of the platinum design, at a fraction of the effort and without requiring the bookmarks pane or any other additional real estate.  Imo, it's good enough to be worth doing immediately.

However, it's time to get b2 out the door, so I'll wait a day or three before starting this project.  Unless Terry beats me to it :-)

Edward

[Kent Tenney]

How about using the log pane?
There could be multiple sets of bookmarks, each in a tab.
instead of competing with tree and body.

I don't think bookmarks really need to be hierarchal

[Terry Brown]

On Thu, 9 Apr 2015 05:25:41 -0500
Kent Tenney <kte...@gmail.com> wrote:

> How about using the log pane?
> There could be multiple sets of bookmarks, each in a tab.
> instead of competing with tree and body.
>
> I don't think bookmarks really need to be hierarchal

The hierarchy is very useful, my top level bookmarks are

ToDo Tasks Edits Projects Links Info Other

Within those, Projects is mostly different work projects,
Links is various web bookmark stuff
Other is actually mostly Leo ;-)

Then within Other there's a Leo core and Leo plugins division

Also there are options to control how may layers of hierarchy are shown
at once, it need only be one, with an up-arrow for the previous level
up.

Cheers -Terry

[Kent Tenney]

The targets are all in the current file?
or have bookmarks gone inter-file

I vacillate between huge Leo files and many smaller ones,
currently in a many/small phase. I can see the hierarchy
benefit in larger ones.

[Terry Brown]

On Thu, 9 Apr 2015 03:41:42 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> ​​

> ​On Wed, Apr 8, 2015 at 11:23 AM, Kent Tenney <kte...@gmail.com>
> wrote:
>
> >
> > I can see how well they work, however they introduce several new
> > idioms:
> > - nodes in a body pane instead of the tree pane
> > - clicking in one part (empty space) of a body pane to put content
> > there
> > - clicking in another part (button) of a body pane to change focus
> > - persisting is called 'layout'
> > - use of the top secret rclick on border
> >
>
> ​Despite Terry's answers to this, I have similar concerns.
>
> In fairness to Terry, is a hard design problem, and potentially a lot
> of work.
>
> Let's do a thought experiment.
>
> Suppose the bookmark pane looked and worked like Leo's existing
> outline pane, except that the nodes were bookmarks. Let's call this

> the *bookmark outline pane*. *Optionally*, there could be a* bookmark
> body pane*, containing data associated with each bookmark: notes,

> explicit UNL's to the target node, whatever.

Rather than a bookmarks body pane, it would be better to spend time on
the "body editor as a relocatable widget" project that's been drifting
around for years. If that was done, it would be trivial to have an
editor showing the bookmark's body.

The bookmarks pane is basically a tree view, although it works
horizontally as well as vertically.

As you know from reading Plugins -> Bookmarks -> About ;-) there are
commands to use the bookmarks from the keyboard:

General bookmark commands

bookmarks-open-bookmark opens the bookmark in the selected node if the
node has an ancestor which contains @bookmarks in its heading.

bookmarks-open-node, like bookmarks-open-bookmark but without
the ancestor requirement.

bookmarks-switch
move between your working position in the outline, and the current
bookmark, in the outline. This is the keyboard friendly no extra pane
alternative to the mouse based bookmark pane navigation described
below.

bookmarks-bookmark
Add the current node as a bookmark at the current level in the
bookmarks tree. Another keyboard friendly alternative.

bookmarks-bookmark-child
Add the current node as a child of the current bookmark, if there is a
current bookmark. Another keyboard friendly alternative.

Real estate wise bookmarks require very little in a horizontal
orientation, just about two lines off the body panes area typically.

Really the only things I've heard that I don't think is largely covered
is bookmark body view, which would be best addressed by relocatable
body widgets, and keyboard navigation in the bookmark pane. That would
be a nice feature to have - you can navigate bookmarks with the keyboard
now with bookmarks-switch, but a command to focus the bookmarks pane
and use cursors keys and enter in there to navigate would be nice.

Cheers -Terry

> *How useful would this be*?

>
> There would be many advantages. The appropriate key bindings would
> be in effect, so one could navigate, expand and collapse, organize,
> create and destroy nodes as usual. Creating a node would,
> presumably, create a bookmark. You get the idea.
>

> Navigating the *bookmark *
> ​outline pane would *select *the corresponding node in the main

> outline, which would update the main body pane. If the bookmark
> outline pane also contained a bookmark body pane, this pane too would

> automatically update. *Important*: when navigating the bookmark pane,

> focus would stay in the bookmark pane even though the nodes in the
> outline pane are also being selected.
>
> This is pretty much the way present bookmarks plugin works. In
> particular, selecting a node in the outline shows that node in
> context, a very good thing.
>
> Despite all the coolness just described, this platinum design has a
> few drawbacks.
>
> 1. This design takes a lot of real estate. I hadn't originally
> intended to mention it, but the design is looking good enough that it
> now seems important to point out this drawback explicitly. :-)
>
> 2. This design implies constant switching back and forth between the
> main outline and the bookmark outline. A new
> toggle-active-outline-pane command would work, but we would be using
> it a lot.
>
> 3. It's easy to blithely talk about how focus will stay in the
> bookmark panes while also Leo selects nodes in the body pane, but
> this will be very difficult to do. We are talking about messing with
> some of the most complex logic in all of Leo. The present bookmarks
> plugin finesses this problem by never having focus :-)
>

> *Summary*

[Terry Brown]

On Thu, 9 Apr 2015 08:35:39 -0500
Kent Tenney <kte...@gmail.com> wrote:

> The targets are all in the current file?
> or have bookmarks gone inter-file

Definitely inter-file. They can also point to websites or pdf files or
whatever. Basically the first line of the bookmarks body gets sent to
g.handleUrl(), which checks for Leo / UNL based urls, and then treats
it like a regular URL.

Cheers -Terry

[Kent Tenney]

Doh

Thanks for being patient, I'm _very_ slowly getting up to speed here.
I hadn't bothered looking at the bookmark body, was only seeing the
clickables. Copy a UNL from another file paste into a new node in the
bookmark tree and Bob's your uncle. Cool.

OK, just discovered rclick on the clickables, offering 'Show child bookmarks'
Wow. Brilliant use of real estate, the tree is below instead of next to.

Other rclick goodies to figure out.

I think I'd best shut up and study for a while ...


On Thu, Apr 9, 2015 at 8:55 AM, 'Terry Brown' via leo-editor

[Edward K. Ream]

On Thu, Apr 9, 2015 at 8:46 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

​
​

​> ​

*Optionally*, there could be a* bookmark
> body pane*, containing data associated with each bookmark: notes,
> explicit UNL's to the target node, whatever.

Rather than a bookmarks body pane, it would be better to spend time on
the "body editor as a relocatable widget" project that's been drifting
around for years.  If that was done, it would be trivial to have an
editor showing the bookmark's body.

​Good.

The bookmarks pane is basically a tree view, although it works
horizontally as well as vertically.

​Ah.  Just figured out how to create a child bookmark.  Imo, the tree interface needs a lot of work.  It is far from intuitive.​

 

​But that's moot because I personally never want to see or use the bookmarks pane. I'll play with the @bookmarks tree and see what more, if anything​, would be good to have.

​

​  ​

bookmarks-switch
  move between your working position in the outline, and the current
  bookmark, in the outline.

​Good.

Really the only things I've heard that I don't think is largely covered
is bookmark body view

​Yeah, this is low priority.  Or rather, as you say, it's a different priority.

Edward