From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Abbrev should preserve case Date: Thu, 21 Jun 2007 00:14:03 -0400 Message-ID: References: <200706201948.06271.andreas.roehler@online.de> <4nvedib77v.fsf@fencepost.gnu.org> <29696.128.165.0.81.1182397659.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1182399264 8698 80.91.229.12 (21 Jun 2007 04:14:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Jun 2007 04:14:24 +0000 (UTC) Cc: Glenn Morris , Andreas =?iso-8859-1?Q?R=F6hler?= , emacs-devel@gnu.org To: herring@lanl.gov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 21 06:14:22 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I1E3m-0006N0-Bw for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 06:14:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1E3l-0001Nl-JJ for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 00:14:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I1E3b-0001Kk-Hp for emacs-devel@gnu.org; Thu, 21 Jun 2007 00:14:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I1E3b-0001KL-3P for emacs-devel@gnu.org; Thu, 21 Jun 2007 00:14:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1E3a-0001KE-Pb for emacs-devel@gnu.org; Thu, 21 Jun 2007 00:14:06 -0400 Original-Received: from tomts13.bellnexxia.net ([209.226.175.34] helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I1E3Z-0008JP-FJ; Thu, 21 Jun 2007 00:14:05 -0400 Original-Received: from pastel.home ([70.53.192.71]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070621041404.KGNK13954.tomts13-srv.bellnexxia.net@pastel.home>; Thu, 21 Jun 2007 00:14:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D83CE836C; Thu, 21 Jun 2007 00:14:03 -0400 (EDT) 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\)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73493 Archived-At: >> 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