The next 5 weeks

53 views
Skip to first unread message

Edward K. Ream

unread,
Sep 21, 2017, 12:17:37 PM9/21/17
to leo-editor
Rebecca and I will be on vacation from September 20 until October 21 at the latest.  Before leaving, Leo 5.6b2 and final will go out the door.

I am still trying to integrate the lessons from my 50th reunion.  It was an unexpectedly important event in my life.  My programming productivity has taken a temporary hit as a result.

When I return I'll resume intense work on Leo.  Support for org-mode-like drawers has high priority.

Edward

Terry Brown

unread,
Sep 21, 2017, 2:11:40 PM9/21/17
to leo-e...@googlegroups.com
On Thu, 21 Sep 2017 09:17:37 -0700 (PDT)
"Edward K. Ream" <edre...@gmail.com> wrote:

> When I return I'll resume intense work on Leo.  Support for
> org-mode-like drawers has high priority.


Not familiar with org-mode drawers, but wondering if the attrib-edit
plugin is relevant.

It's docs. are below. It supports three ways of storing attributes on
nodes, in v.u, 'key: value' in the body, or as child nodes. I think
the v.u method is the one you'd want.

Cheers -Terry


Edits user attributes in a Qt frame.

This plugin creates a frame for editing attributes similar to::

Name: Fred Blogs
Home: 555-555-5555
Work: 555-555-5556

``attrib_edit`` is also intended to provide attribute editing for
other plugins, see below.

The editor panel appears in the Log pane in its own tab. If the free_layout
system is active you can move it into its own pane (e.g. below the body text)
by right clicking the pane dividers.

The attributes can be stored in different ways, three modes are implemented
currently:

v.u mode
These attributes are stored in the "unknownAttributes" (uA) data for
each node, accessed via v.u.

Field:
Attributes are lines starting (no whitespace) with "AttributeName:" in
the body text.

@Child
Attributes are the head strings of child nodes when the head string
starts with '@AttributeName' where the first letter (second character)
must be capitalized.

The plugin defines the following commands, available either in the
plugin's sub-menu in the Plugins menu, or as ``Alt-X attrib-edit-*``.

attrib-edit-modes
Select which attribute setting / getting modes to use. More than one mode
can be used at the same time.

You can also control which modes are active by listing them
with the @data attrib_edit_active_modes setting. For example::

Field:
@Child
# v.u mode

would cause only the "Field:" and "@Child" modes to be active be default.

attrib-edit-manage
Select which attributes, from all attributes seen so
far in this outline, to include on the current node.

attrib-edit-scan
Scan the entire outline for attributes so ``attrib-edit-manage``
has the complete list.

attrib-edit-create
Create a new attribute on the current node. If Field: or \@Child modes
are active, they simply remind you how to create an attribute in the log pane.
If the "v.u mode" mode is active, you're prompted for a path for the attribute.
For example::

addressbook First

to store the attribute in v.u['addressbook']['_edit']['First']

As a convenience, entering a path like::

todo metadata created|creator|revised

would create::

v.u.['todo']['metadata']['_edit']['created']
v.u.['todo']['metadata']['_edit']['creator']
v.u.['todo']['metadata']['_edit']['revised']


**Technical details**

See the source for complete documentation for use with other
plugins. Here are some points of interest:

- In addition to ``v.u['addressbook']['_edit']['first']``, paths
like ``v.u['addressbook']['_edit']['_int']['age']`` may be used
to identify type, although currently there's no difference in
the edit widget.

- In the future the plugin may allow other plugins to register
to provide attribute path information, instead of just
scanning for ['_edit'] entries in v.u.

- Currently there's no sorting of the attributes in "v.u mode", which is
a problem for some applications. It's unclear where the
desired order would be stored, without even more repetition
in v.u. When other plugins can register to manipulate the
attribute list each plugin could address this, with unordered
presentation in the absence of the client plugin.

Edward K. Ream

unread,
Sep 23, 2017, 11:34:52 AM9/23/17
to leo-editor
On Thu, Sep 21, 2017 at 1:11 PM, Terry Brown <terry...@gmail.com> wrote:
On Thu, 21 Sep 2017 09:17:37 -0700 (PDT)
"Edward K. Ream" <edre...@gmail.com> wrote:

> When I return I'll resume intense work on Leo.  Support for
> org-mode-like drawers has high priority.

Not familiar with org-mode drawers, but wondering if the attrib-edit
plugin is relevant.

​It's relevant.  I'll be studying it when I turn my attention to #414.

Edward
Reply all
Reply to author
Forward
0 new messages