From: Stefan Monnier <monnier@iro.umontreal.ca>
To: herring@lanl.gov
Cc: "Glenn Morris" <rgm@gnu.org>,
"Andreas Röhler" <andreas.roehler@online.de>,
emacs-devel@gnu.org
Subject: Re: Abbrev should preserve case
Date: Thu, 21 Jun 2007 00:14:03 -0400 [thread overview]
Message-ID: <jwvtzt2hs4u.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <29696.128.165.0.81.1182397659.squirrel@webmail.lanl.gov> (Davis Herring's message of "Wed\, 20 Jun 2007 20\:47\:39 -0700 \(PDT\)")
>> 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
next prev parent reply other threads:[~2007-06-21 4:14 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-20 17:48 Abbrev should preserve case Andreas Röhler
2007-06-20 22:18 ` Glenn Morris
2007-06-21 3:47 ` Davis Herring
2007-06-21 4:14 ` Stefan Monnier [this message]
2007-06-21 7:10 ` Andreas Röhler
2007-06-21 8:01 ` Stefan Monnier
2007-06-21 9:00 ` Andreas Röhler
2007-06-21 7:00 ` Glenn Morris
2007-06-21 17:32 ` Richard Stallman
2007-06-21 19:02 ` Stefan Monnier
2007-06-22 16:25 ` Richard Stallman
2007-06-22 17:51 ` Stefan Monnier
2007-06-22 21:53 ` Richard Stallman
2007-10-10 21:14 ` Abbrev tables in elisp with some extra stuff (was: Abbrev should preserve case) Stefan Monnier
2007-10-11 19:57 ` Andreas Röhler
2007-10-12 15:59 ` Richard Stallman
2007-10-12 21:26 ` Abbrev tables in elisp with some extra stuff Stefan Monnier
2007-10-13 6:41 ` Richard Stallman
2007-10-14 17:45 ` Andreas Röhler
2007-10-15 16:04 ` Richard Stallman
2007-10-15 18:04 ` Andreas Röhler
2007-10-16 4:10 ` Richard Stallman
2007-10-16 20:26 ` Stefan Monnier
2007-10-17 5:03 ` Richard Stallman
2007-10-17 14:10 ` Richard Stallman
2007-10-17 20:48 ` Richard Stallman
2007-10-24 2:21 ` Stefan Monnier
2007-10-25 2:10 ` Richard Stallman
2007-10-26 5:44 ` Testing new abbrev tables in elisp Stefan Monnier
2007-10-26 19:13 ` Andreas Röhler
2007-10-26 21:38 ` Stefan Monnier
2007-10-28 14:13 ` Andreas Röhler
2007-10-28 21:03 ` Stefan Monnier
2007-10-30 15:10 ` Andreas Röhler
2007-10-31 7:47 ` Richard Stallman
2007-11-03 20:29 ` Stephen J. Turnbull
2007-11-04 0:11 ` Richard Stallman
2007-11-04 2:42 ` Stephen J. Turnbull
2007-11-04 21:06 ` Andreas Röhler
2007-11-05 8:47 ` Richard Stallman
2007-10-31 16:09 ` Juri Linkov
2007-10-31 17:44 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvtzt2hs4u.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=andreas.roehler@online.de \
--cc=emacs-devel@gnu.org \
--cc=herring@lanl.gov \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.