Re: Abbrev-mode question

[Stefan Monnier]

SM> An abbrev-mode in ELisp with the same behavior as the current one is
SM> about as fast as it is in C.  Extending it to multi-word abbrevs might
SM> slow it down significantly, but that's also true in C.  The main issue
SM> is rather how to avoid the slowdown, which depends on further info:
SM> - how many multi-word abbrevs are we talking about?

> Several hundreds. No more than thousand.

OK, that's "many" for me ;-)
Means it's not desirable to loop through each one of your abbrevs and look
if the text before point is identical.

Currently, abbrevs work by extracting the word before point and looking it
up in a hash-table, so it does not get noticeably slower in the presence of
many abbrevs.

SM> - how can we determine the start (so as not to mistake "afool bo" for
SM> a case where the "ol bo" abbrev should be expanded)?  Should it also
SM> necessarily start with a word boundary?

> As this is for text in natual language, abbrevs start and end on
> word boundaries.

I did understand that your abbrev expansions are natural language, but it
wasn't obvious that you chose to name your abbrevs in a similar way.

SM> - can be put a reasonable upper limit on
SM> the number of words in a multi-word abbrev (2 or 3, maybe)?

> 5 words is a limit.

Would it be OK to add a constraint such as that words in an abbrev need to
be connected with hyphens?  And if you have an abbrev "foo-bar", would it be
OK for it *not* to be expanded in a case like "toto-foo-bar"?


        Stefan