Re: Abbrev should preserve case

[Andreas Röhler]

...
>
> We could very easily make some abbrev-table case sensitive. 


That's great. 

Might it not be the best solution to drop the down-case
commands in abbrev.c?

DEFUN ("define-global-abbrev",

for example calls it

,----
| Fdefine_abbrev (Vglobal_abbrev_table, Fdowncase (abbrev),
`----
line 181

Case handling should be done at a higher level AFAIU.


> I have 
> reimplemented abbrevs in Elisp and have added some features such as
> case-fold properties on abbrev-tables as well as inheritance between
> abbrev-tables (those two properties are useful together to make it possible
> to mix case-sensitive and case-insensitive abbrevs).  The port from C to
> Elisp is clean and should be pretty reliable (the new features OTOH are
> only partly implemented for now, the missing parts being mostly on the
> front of displaying/reading/saving those elements of abbrev tables).
>
> Recently someone brought to my attention that it is difficult to
> enable/disable abbreviations depending on the context (e.g. enable/disable
> abbrevs providing skeletons depending on whether point is in string/comment
> or not).  So maybe a `predicate' would be a useful addition.
>
>
>         Stefan

As it seems the right time to consider several things,
let me ask some more questions around abbrevs:

Imaging the use of machine written abbrevs for NLP,
context analyses etc., speed will matter. Therefore I
suggest to do the work in C as far as possible, avoid
re-implementations. (I intend to take part here as far
as it's welcome and I'm able to.)

Given all that would be done, another point arises:
the volume of the abbrev_defs-file.

Please consider if a derived mode must copy all the
abbrevs. I'd say a derived mode should rather note the
differences, but read the major-mode first. Then the
abbrev-file, which already counts 500K here, would
shrink a lot.

Thanks all

Andreas Roehler