On Sep 1, 10:58 am, "Edward K. Ream" <[email protected]> wrote:
> 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
Rev 3310 completes, for now, the work on abbreviations as follows:
1. Added support for @data abbreviations
The body text contain lines of the form::
name=value
The code strips whitespace from around name, but *not* from value, so
the value may contain both leading and trailing whitespace.
Leo will report (in the log pane) any abbreviations discovered from
such nodes.
2. Added support for @bool enable-abbreviations = true/false (default
False).
Leo will report that abbreviations are enabled if they have been
enabled this way.
As usual with settings, these nodes must be children of an @setting
node to have effect.
Using @data abbreviations nodes is *much* more convenient than using
external abbreviation files. The recommended usage is, as always, to
put common abbreviations in myLeoSettings.leo, and to put per-file
settings in individual .leo files.
Kent is about to point out that this is not the optimum: local
abbreviations mask common abbreviations. He's right, but the present
way is about 100 times more flexible and convenient than external
abbreviation files.
My mind boggles when I consider the dynamic abbreviation commands. I
haven't tried them, and won't unless somebody really needs them ;-)
Please report any problems with the new code immediately.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
