Re: Abbrev should preserve case

[Stefan Monnier]

>> How would you tell the difference between `FOO' meaning "expand to the
>> upper-case expansion of `foo'" (as it works now), and `FOO' a totally
>> separate abbreviation? I guess you could try a case-insensitive match
>> first, then a case-sensitive one if it fails. This would mean that
>> `FOO' could expand to something different than `foo' only if `foo'
>> were not defined as an abbrev. Seems a bit complex though.

> Surely you mean do a case-sensitive search first and then insensitive? 
> Obviously the sensitive one can't work if the insensitive one fails.  Then
> you go on to say that "FOO" could only be -different- if there is nothing
> than which to be different; instead we want to say "`FOO' can only expand
> as upcased `foo' if `FOO' is not its own abbrev", right?

> I'm not trying to be needlessly pedantic; rather I think what you probably
> meant to say made significantly more sense as a path forward than what you
> did say and so deserves consideration.

We could very easily make some abbrev-table case sensitive.  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