On Wed, Sep 1, 2010 at 7:36 AM, Edward K. Ream <edream...@gmail.com> wrote:

> Your timing is perfect.  I've been thinking of taking a few hours off
> to add another kind of abbreviation.  Before doing so, it would seem
> prudent to see if the present code can be made to work.

Rev 3305 gets the basics to work.  See the new apropos-abbreviations
command for details.

I've only really tested the add-global-abbrev command and the actual
substitution logic, which is now undoable much more smoothly than
before.

But this is only the start.  The present abbreviation commands are
geared toward the pathetically feeble emacs environment :-)  We can do
*much* better in Leo, in at least two ways:

1. It's clumsy to define and reuse abbreviations.

Sure, it *possible* to define abbreviations by a) selecting some text
and b) invoking add-global-abbrev (presumably with a keystroke) and c)
specifying the abbreviation name.

It's just as clumsy to type the name of an external file that holds
abbreviations.

The Leonine way would be to define an @settings node, say @data
abbrev, whose body text contain the desired abbreviations.  We could
go further, and add a tag, something like this::

    @data abbrev project-x-abbrevs

We could then define @button scripts to search for such nodes and load
some or all of their abbreviations.  Etc, etc, etc.  To make this
work, the abbreviation code needs ways of adding and deleting groups
of abbreviations.

2. It would be possible to define abbreviations whose expansions
result in the insertion of entire trees.

This would be easy to do.  Did you know that you can paste any outline
into any body text?  Just select the outline, do copy-node, and then
do a plain paste into the body text.

A simple convention would use this trick to define outline
abbreviations.  In the body of an @data abbrev node we could have::

    name =!! <pasted tree>.

For example:

    Tree1 =!!\
    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet ekr_test?>
    <leo_file>
    [snip]
    </leo_file>

There definition would continue until the closing </leo_file>.  This
works because of the xml escape conventions.  There won't be a "false"
closing tag before the "real" one.

I'm not likely to do all this today, but I think all this should be
done sooner rather than later.

Your comments, please.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to 
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Reply via email to