Abbrev-mode question

Abbrev-mode question

[Leschinsky Oleg]

Hi, everyone.

Recently I partially moved  to Emacs from XEmacs. What prevents me from
full conversion to Emacs is different behavior of abbrev mode.

In XEmacs abbreviation can consist of several words, so after entering some
phrase that exists in mode specific abbrev-table and whitespace character
it get replaced according to abbrev-table.

In Emacs abbrev mode work just like in XEmacs, but replace occurs only with
one-word abbreviations.

Is there a way to turn on XEmacs-like abbrev mode behavior? Is there
a way to get this functionality in Emacs without abbrev mode?

Re: Abbrev-mode question

[Andreas Röhler]

Am Dienstag, 11. September 2007 11:48 schrieb Leschinsky Oleg:
> Hi, everyone.
>
> Recently I partially moved  to Emacs from XEmacs. What prevents me from
> full conversion to Emacs is different behavior of abbrev mode.
>
> In XEmacs abbreviation can consist of several words, so after entering some
> phrase that exists in mode specific abbrev-table and whitespace character
> it get replaced according to abbrev-table.
>
> In Emacs abbrev mode work just like in XEmacs, but replace occurs only with
> one-word abbreviations.
>
> Is there a way to turn on XEmacs-like abbrev mode behavior? Is there
> a way to get this functionality in Emacs without abbrev mode?
>

Good question: another feature I miss in Gnu Emacs is
the use of upcased abbrevs.

As core functions `expand-abbrev' are written
in C in both Emacsen, that's probably not so easy to
change.

An extended abbrev-mode in Emacs-Lisp checking phrases
all the time may end up slow. Wouldn't undertake that,
rather ask in emacs-devel for an implementation in C.

Andreas Röhler

Re: Abbrev-mode question

[Stefan Monnier]

> As core functions `expand-abbrev' are written
> in C in both Emacsen, that's probably not so easy to
> change.

Actually, AFAIK the only entry point called from C is expand-abbrev and that
is called via the `expand-abbrev' symbol rather than calling the
Fexpand_abbrev C function (a change I installed for Emacs-21.1 IIRC), so you
can redefine all the abbrev functions in elisp and have them work just as
well as before.

> An extended abbrev-mode in Emacs-Lisp checking phrases
> all the time may end up slow.  Wouldn't undertake that,
> rather ask in emacs-devel for an implementation in C.

An abbrev-mode in ELisp with the same behavior as the current one is about
as fast as it is in C.  Extending it to multi-word abbrevs might slow it
down significantly, but that's also true in C.  The main issue is rather how
to avoid the slowdown, which depends on further info:
- how many multi-word abbrevs are we talking about?
- how can we determine the start (so as not to mistake "afool bo" for a case
  where the "ol bo" abbrev should be expanded)?  Should it also necessarily
  start with a word boundary?
- can be put a reasonable upper limit on the number of words in a multi-word
  abbrev (2 or 3, maybe)?


        Stefan "whose abbrev-mode is all written in ELisp"

Re: Abbrev-mode question

[Leschinsky Oleg]

Evening, Stefan Monnier. 

Stefan Monnier 02:13 12/9/2007 wrote:

 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.

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

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

 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.

 SM>         Stefan "whose abbrev-mode is all written in ELisp"

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

Re: Abbrev-mode question

[Leschinsky Oleg]

Evening, Stefan Monnier. 

Stefan Monnier 16:04 12/9/2007 wrote:

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

Somehow XEmacs don't become much slower. Maybe its because multi-language
nature of text (see below).

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

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

>> 5 words is a limit.

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

I have better (I think) constraint: abbrevs consist of english words when
all other words are ukrainian/russian (cyrillic). So only  several words
before point consisting of [a-zA-Z- ] need expanding as abbrevs.

I'm using XEmacs/Emacs to translate text from english to ukrainian/russian,
so abbrev mode plays role of dictionary for terminology.  Is there another
tool for this task (automagic replacing of terms by their translation) that
I don't know about?

Re: Abbrev-mode question

[Andreas Röhler]

...
> I have better (I think) constraint: abbrevs consist of english words when
> all other words are ukrainian/russian (cyrillic). So only  several words
> before point consisting of [a-zA-Z- ] need expanding as abbrevs.
>
> I'm using XEmacs/Emacs to translate text from english to ukrainian/russian,
> so abbrev mode plays role of dictionary for terminology.  Is there another
> tool for this task (automagic replacing of terms by their translation) that
> I don't know about?
>
>

Meaning of words differs considerable according to
context. You will need different expansions for the
same phrase, unless you stay in a restricted, well
known environment. `Gettext' you probably will know. 

Andreas Röhler