From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?iso-8859-1?q?R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Abbrev should preserve case Date: Thu, 21 Jun 2007 09:10:47 +0200 Message-ID: <200706210910.48499.andreas.roehler@online.de> References: <200706201948.06271.andreas.roehler@online.de> <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="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182409553 2384 80.91.229.12 (21 Jun 2007 07:05:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Jun 2007 07:05:53 +0000 (UTC) Cc: Glenn Morris , Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 21 09:05:50 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 1I1GjV-00057N-K2 for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 09:05:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1GjU-0000PS-W7 for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 03:05:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I1GjQ-0000MP-HW for emacs-devel@gnu.org; Thu, 21 Jun 2007 03:05:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I1GjO-0000JU-6C for emacs-devel@gnu.org; Thu, 21 Jun 2007 03:05:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1GjN-0000JO-UD for emacs-devel@gnu.org; Thu, 21 Jun 2007 03:05:25 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.174]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I1GjK-0006nf-0T; Thu, 21 Jun 2007 03:05:22 -0400 Original-Received: from [84.190.193.34] (helo=karton) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1I1GjF1gYk-0004M7; Thu, 21 Jun 2007 09:05:19 +0200 User-Agent: KMail/1.8.2 In-Reply-To: Content-Disposition: inline X-Provags-ID: V01U2FsdGVkX1+fdhP6YlLUL/RK6tIFmAzv2ULSWTMhy+gzGKs FW3OEMt5dK4JaMZD5PAVp50vheOdj956SIi/zEhl1hxJzbILn5 ssxHvm5zET8CnwBYvo/LA== X-detected-kernel: Linux 2.6? (barebone, rare!) 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:73496 Archived-At: ... > > 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