obvious abbreviation...

[Terry Brown]

h;;={|{x=c.p.h}|}

inserts the current headline in the body when you type h;;

Cheers -Terry

[john lunzer]

Terry, this is obvious but I've found one letter abbreviations to be a nuisance. For example Edwards recent example of e;; is not compatible with date;; 

In the same way I would expect h;; to conflict at some point.

hl;; might be a better choice. 

On a side note, is there any way to update abbreviations without restarting Leo?

[Edward K. Ream]

On Mon, Apr 27, 2015 at 2:48 PM, john lunzer <lun...@gmail.com> wrote:

Terry, this is obvious but I've found one letter abbreviations to be a nuisance. For example Edwards recent example of e;; is not compatible with date;; 

​This is a bug which I'll fix asap.  The abbreviation matcher should prefer the longest match.  It's probably one or two lines of code.

EKR

[Terry Brown]

a) what's with this thing where I keep getting replies before seeing
the original - in this case Edward's reply before any sign of John's
response.

b) yes, that would be worth fixing

c) the real content in this email ;-) once you define @data
abbreviations and / or @data abbreviations-subst-env in
myLeoSettings.leo, you're isolated, for better or worse, from updates
to these nodes in LeoSettings.leo. With single node @settings like
@int and @string the answer has always been only define the minimum in
myLeoSettings.leo, so you'll still benefit from updates in
LeoSettings.leo.

But that doesn't help with @data nodes which essentially contain lots
of settings. @data qt-gui-user-style-sheet is a work around for @data
qt-gui-plugin-style-sheet, the former just being appended to the latter.

Also we now have @data nodes built from all their children, although I
don't see any direct application for that.

So what I'm wondering, is how to allow personal extensions to
multi-setting @data settings.

i) just define a @data qt-gui-plugin-style-sheet + @data
qt-gui-user-style-sheet kind of pair in every case, simple but seems a
bit clumsy.

ii) Have an @inherit directive which pulls in the content of
LeoSettings.leo @data abbreviations at the beginning of
myLeoSettings.leo @data abbreviations. Not sure how hard that would be
implement.

iii) Have something even more flexible, like `@include UNL` to pull the
content of any node in any file into a @data node.

I guess the first question is how many cases are there where this is an
issue.

@data qt-gui-plugin-style-sheet - covered already
@data abbreviations
@data abbreviations-subst-env

for nd in p.self_and_subtree():
if nd.h.startswith('@data ') and len(nd.b) > 200:
g.es(nd.get_UNL(with_index=False).split('@settings')[1])

...that finds about 10 nodes, including the three already discussed, but
only about four more that would be candidates:

-->Abbreviations-->@data global-abbreviations
-->Menus-->Qt context menu-->@data contextmenu_commands
-->Plugins-->active_path plugin-->@data active_path_ignore
-->Plugins-->wikiview plugin-->@data wikiview-link-patterns

...so maybe (i) is sufficient. Which would mean adding
@data abbreviations-user and
@data abbreviations-subst-env-user

Comments? Appetite for (ii) or (iii)?

Cheers -Terry

[Edward K. Ream]

​​On Mon, Apr 27, 2015 at 9:23 PM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:

​> > ​

I've found one letter abbreviations to

​ ​

be a nuisance. For example Edwards recent example of e;; is not

​ ​

compatible with date;;

> ​This is a bug which I'll fix asap.  The abbreviation matcher should

​ ​

prefer the longest match.  It's probably one or two lines of code.

​It was, but I got involved in some cool additions.​

 Almost ready to push a fix.

once you define

​​

@data

​ ​

abbreviations and / or @data abbreviations-subst-env in

​ ​

myLeoSettings.leo, you're isolated, for better or worse, from updates

​ ​

to these nodes in LeoSettings.leo. 

​You hint at a partial solution when you mention composing @data nodes from their children.  ​

 

​Both ​@data abbreviations and @data abbreviations-subst-env should be defined that way. The next push will do that.

So you could put all your overrides in a personal node, and merge (by hand) that node into your @data nodes when the global nodes change. Not perfect, but not bad.  Indeed, there is no urgency to staying current if you are satisfied with what you have.

I am not wild about complicating settings even further.  Settings are already too complex for me to understand fully.  Any more features would make life harder for newbie and guru alike.

Imo, a better way would be to improve diffs of Leo outlines.  The --diff option is a fairly feeble start.  Improved diffing of outlines would highlight the new stuff so you could merge it.  Improving diff is on the list for 5.2.

Edward