"scripts" - when should they go in the core?
Terry Brown
closes any xml element open at the insert point in the body text.
I've made and effort to make it friendly, it repositions the scroll
position politely, and it can be run on just the selected text (useful
if there's leading text which is invalid xml in the node) in which case
it maintains and extends the selection, allowing it to be run again
without re-selecting (to close multiple elements).
I think it's very useful, but it seems too small a thing to go into a
plug in. Should it go in to the core? If not, where can such things
go where they can be found by people that may benefit from them?
Cheers -Terry
Terry Brown
Terry Brown <terry_...@yahoo.com> wrote:
> I've made and effort to make it friendly
Although I didn't make it undoable, maybe that should be required for
things going in to the core too.
Edward K. Ream
> So I have this @button / @command / script "xml-close-element". It
> closes any xml element open at the insert point in the body text.
...
> I think it's very useful, but it seems too small a thing to go into a
> plug in. Should it go in to the core? If not, where can such things
> go where they can be found by people that may benefit from them?
I suggest changing @button to @@button and putting it in scripts.leo,
in the node:
Scripts-->@file leoScripts.txt-->Contributed @button nodes
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > I think it's very useful, but it seems too small a thing to go into
> > a plug in. Should it go in to the core? If not, where can such
> > things go where they can be found by people that may benefit from
> > them?
>
> I suggest changing @button to @@button and putting it in scripts.leo,
> in the node:
>
> Scripts-->@file leoScripts.txt-->Contributed @button nodes
I can do that, although I'm not sure it meets the "where they can be
found" criteria. I know I've never looked in there. On the other hand
I'm sure there are innumerable commands in the core I don't know about
either, so that's not really a difference. Likewise there are plugins
I've probably never looked at - sounds like a challenging indexing
problem :-)
Cheers -Terry
Edward K. Ream
> sounds like a challenging indexing problem :-)
Interesting way to think of it.
As Leo gets more scripts, plugins, buttons and commands, it might be
good to create a way of describing such things without actually
importing or otherwise enabling them. Iirc, Eclipse has a way of
registering plugins without going through the expense of loading them.
This is good, considering how many Eclipse plugins there are. Again,
iirc, Eclipse uses an xml template to describe plugins. Perhaps it's
time to consider something similar for Leo.
And maybe it's time for rewriting Leo's presently defunct plugins
manager plugin.
Edward
Ed Blake
Ed Blake
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> Again,
> iirc, Eclipse uses an xml template to describe plugins. Perhaps it's
> time to consider something similar for Leo.
Thinking aloud, ways of doing this.
We could have a Leo file in the trunk which catalogs all these things,
and people could update it when they add things. Not sure if that
would actually get done though.
Another option would be a default docstring template something like
this:
"""Close any open XML elements at the cursor position in the
body text.
:author: Terry Brown
:author-email: terry_...@yahoo.com
:updated: 2008-08-27
:leo-components: command button script
:tags: xml editing
:title: Close XML elements
"""
There could be other fields of course.
Then at some point(*) all the .py files in the distro could be scanned,
the first 100 lines of each anyway, looking for the magic
'^:leo-components: '. Seeing that tells the scanner that it's seeing a
leo component cataloging docstring, and that leads to the fields being
extracted, including the text before the first field, into a
'description' field. Then you just need an interface to search /
sort / display this database, which doesn't have to be anything fancy.
It should also extract file location etc.
And, to make it easy, the core should include an
insert-component-docstring command to insert a template for the above.
(*) at some point ... well, I was going to say that the answer to the
scan could be stored, and that people should generate it before
updating the trunk, but a quick test suggests the scan could be done on
demand, it takes so little time.
But... I guess you'd have to scan the whole file, rather than the first
100 lines, and handle multiple docstrings per file, for scripts, for
example.
And having determined that the script you want exists, how do you make
the link to the place where you enable it. Still some thinking to do.
Cheers -Terry
Terry Brown
"Ed Blake" <kits...@gmail.com> wrote:
> How about a node with a special
> header that contains all relevant information?
Ha, crossing emails. I think we're leaning the same way here, it's not
clear to me yet whether this template / header thing will always be
in .py files, or .leo files, or both. Things that we might want to
catalog and make searchable include:
plug ins
commands in the core
contributed scripts
... what am I missing?
There's some support already, like help-for-command, although the
output, in the log window, would be more helpful if it wrapped :-)
And it would be nice to be able to search the description texts without
knowing the command's name.
Cheers -Terry
Ed Blake
As for core commands - a command browser plugin would probably be good enough, just make sure the doc strings are in a good format.
Ed Blake
Edward K. Ream
> An xml template seems like overkill
I like Terry's and your idea: put the info in a .leo file. All we
need is some designated node, say @registered-plugins, and then, say,
one child node per plugin, say @plugin, with the description in the
body text. Details don't matter much.
Such nodes could be put in the usual settings files, but it would
probably be better to put them in a separate .leo file.
Anyway, the essential idea, as I see it, is that .leo files are
already xml files, so there is no reason to force people to use "raw"
xml.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> I like Terry's and your idea: put the info in a .leo file. All we
> need is some designated node, say @registered-plugins, and then, say,
> one child node per plugin, say @plugin, with the description in the
> body text.
@registered-components / @component I think - we want to cover scripts
as well.
As Ed (Blake) mentioned it's nice to have the docs as close as possible
to the source, I think my templated docstring approach works better
from that point of view.
> Details don't matter much.
I think the search function could be more useful if there's some
structure beyond a piece of narrative of text. Tags are nice, and a
last updated field could warn you when things are old and possibly
rust, and also let you browse what's new.
Cheers -Terry