nodeActions plugin added
TL
FileActions plugin, designed to invoke a script when a node is double
clicked based on a pattern match to the node's headline.
See the documentation in the Plugins section of the Leo Users Guide
(only available by selecting "Open Users Guide" from the Help menu in
a Leo file until the website is updated).
Please send me any questions or problem reports.
TL
Ville M. Vainio
> Revision 1608 contains a new nodeActions plugin, modeled after the old
> FileActions plugin, designed to invoke a script when a node is double
> clicked based on a pattern match to the node's headline.
Have you check act-on-node? Seems like this is a special case of the
very same thing (which mostly proves that it's a good idea ;-).
--
Ville M. Vainio
http://tinyurl.com/vainio
TL
before updating the trunk.
TL
plugins trigger on events such as the double click of the node's
icon. The nodeActions plugin is intended for Leo users to create and
assign scripts to nodes on a Leo file by file basis.
Concerning the overlap between these two plugins, I think you may be
the best one to evaluate that. Review the documentation on the
nodeActions plugin and let me know what you think.
Regards,
TL
Ville M. Vainio
> Concerning the overlap between these two plugins, I think you may be
> the best one to evaluate that. Review the documentation on the
> nodeActions plugin and let me know what you think.
I think nodeActions should be implemented as act-on-node hander. That
is, loading the nodeActions plugin should register one function to
check whether the active node matches one of the sought-after patterns
and dispatch the wanted node.
I can do the work on nodeActions for this. It will serve as a nice example :-)
The whole point of act-on-node is making plugins co-operate on
"default action", so nodeActions can still play nice even if another
active plugin is interested in icon doubleclick activity.
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> > Concerning the overlap between these two plugins, I think you may be
> > the best one to evaluate that. Review the documentation on the
> > nodeActions plugin and let me know what you think.
>
> I think nodeActions should be implemented as act-on-node hander. That
> is, loading the nodeActions plugin should register one function to
> check whether the active node matches one of the sought-after patterns
> and dispatch the wanted node.
>
> I can do the work on nodeActions for this. It will serve as a nice
> example :-)
>
> The whole point of act-on-node is making plugins co-operate on
> "default action", so nodeActions can still play nice even if another
> active plugin is interested in icon doubleclick activity.
TL has been talking to me off list about mods to active_path, and if I
understand correctly he'd would like to see active_path support a
@setting to stop it gobbling double-clicks on *file* nodes, so that
open_with still works.
This is exactly the kind of conflict (between plugins :-) we've been
discussing, and I still don't see how act-on-node would help. How is
active_path supposed to know the user wants active_path to step aside
in favor of open_with?
If active_path and open_with both published commands to do what they
do, TL could bind them to whatever he wanted, open_with on double-click
and active_path on alt-click or ctrl-space, or whatever.
This also sidesteps the problem that TL wants increased granularity in
active_path's view of nodes it understands. I.e. a "do what you do to
this node, *unless* it's a file node" action, as well as it's existing
"do what you do to this node" action.
You can of course get 5 and even 7 button mice...
Cheers -Terry
Ville M. Vainio
> This is exactly the kind of conflict (between plugins :-) we've been
> discussing, and I still don't see how act-on-node would help. How is
> active_path supposed to know the user wants active_path to step aside
> in favor of open_with?
Well, it never should IMO. A context-sensitive action (active_path)
should always take precedence over a plugin applicable to all nodes
(open_with).
> If active_path and open_with both published commands to do what they
> do, TL could bind them to whatever he wanted, open_with on double-click
> and active_path on alt-click or ctrl-space, or whatever.
Nothing is preveting from still doing it. act-on-node won't prevent
anything (unless that's the sole interface a plugin provides).
> This also sidesteps the problem that TL wants increased granularity in
> active_path's view of nodes it understands. I.e. a "do what you do to
> this node, *unless* it's a file node" action, as well as it's existing
> "do what you do to this node" action.
Providing this kind of granularity is what act-on-node easily
provides. I do think act-on-node is a very bad fit for open-with
plugin, event though I still disagree about active_path ;-)
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> A context-sensitive action (active_path)
> should always take precedence over a plugin applicable to all nodes
> (open_with).
But very often active_path's context will be essentially the whole
file. You're working in directory X, you have @path X at the root of
the tree, active_path thinks it has something to offer for every node
in the tree. And TL wants to use open_with specifically withing an
active_path context.
> > If active_path and open_with both published commands to do what they
> > do, TL could bind them to whatever he wanted, open_with on
> > double-click and active_path on alt-click or ctrl-space, or
> > whatever.
>
> Nothing is preveting from still doing it. act-on-node won't prevent
> anything (unless that's the sole interface a plugin provides).
True, of course.
> > This also sidesteps the problem that TL wants increased granularity
> > in active_path's view of nodes it understands. I.e. a "do what you
> > do to this node, *unless* it's a file node" action, as well as it's
> > existing "do what you do to this node" action.
>
> Providing this kind of granularity is what act-on-node easily
> provides. I do think act-on-node is a very bad fit for open-with
> plugin, event though I still disagree about active_path ;-)
I don't see how act-on-node helps with the granularity. Normal use of
active_path is to act on both directory and file nodes. TL wants to
target directories only. If active_path published a command to do what
it does that could be easily bound at will to whatever the user found
convenient, the granularity comes for free based on which binding the
user activates. I can't see how act-on-node would deal with this, or
with the open_with / active_path conflict in general.
Cheers -Terry
TL
Directives has been added to provide:
- support for Regular Expressions
- support for triggering on multiple patterns
- support for passing the double-click event to other plugins
when a pattern match has occurred.
See the Chapter 12 of the Leo Users Guide for the latest
documentation.
Regards,
TL
Kent Tenney
Speaking of Leo's feature explosion, is there a 'changes' list which
chronologically itemizes new and changed _features_ ?
I think the situation where I have a couple of hours to play
with Leo customization, after a couple weeks of being swamped
with other stuff.
I know there have been lots of commits, discussions of new
features and capabilities. I haven't been able to keep track of these.
I'd like to scan a list of descriptions of changes in Leo's capabilities
over the last couple weeks, quickly review prior ones. Ideally the
description would tell where to find more complete doc.
Case in point, 2 weeks from now I will forget that the name
of this cool feature is 'nodeActions', I will search my mail
guessing at keywords etc, find this email maybe quickly,
maybe slowly, maybe give up.
It seems this list should be somehow created via filtering
commit messages, don't know if that's possible. It probably
won't work if it requires an additional task.
Thanks,
Kent