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 11:00:23 +0200 Message-ID: <200706211100.24533.andreas.roehler@online.de> References: <200706201948.06271.andreas.roehler@online.de> <200706210910.48499.andreas.roehler@online.de> 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 1182416197 24465 80.91.229.12 (21 Jun 2007 08:56:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Jun 2007 08:56:37 +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 10:56:35 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 1I1ISr-0000n7-G9 for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 10:56:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1ISq-00032h-Rn for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2007 04:56:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I1IRm-0002Yn-6h for emacs-devel@gnu.org; Thu, 21 Jun 2007 04:55:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I1IRl-0002YW-HR for emacs-devel@gnu.org; Thu, 21 Jun 2007 04:55:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1IRl-0002YQ-0l for emacs-devel@gnu.org; Thu, 21 Jun 2007 04:55:21 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I1IRh-00034O-P2; Thu, 21 Jun 2007 04:55:18 -0400 Original-Received: from [84.190.167.249] (helo=karton) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1I1IRH3dzi-0006LG; Thu, 21 Jun 2007 10:54:53 +0200 User-Agent: KMail/1.8.2 In-Reply-To: Content-Disposition: inline X-Provags-ID: V01U2FsdGVkX189fQuFiWWGLueqhbF9mE1qUnaYF9dgAIcr4aq st6tjU6UnqrXTQZ/zEyloAWWmIO6xj67OzNCpYNXCkXHAkAdNP mjOKXQXYbX9Up0Z7gPEOA== 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:73508 Archived-At: Am Donnerstag, 21. Juni 2007 10:01 schrieb Stefan Monnier: > > Might it not be the best solution to drop the down-case > > commands in abbrev.c? > > The case-insensitivity (and magical treatment of case in general) is > a feature, as evidenced by the amount of extra code in abbrev.c to > implement it. So we do not want to just throw it all out. Hmm. To preserve the status quo quite often is a wise decision. Will see... > > 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.) > > The expand-abbrev code has no loop. So there is no issue > w.r.t performance (at least as long as we stick to the current constraint > that abbreviations can only contain chars of word-syntax"): the code of > expand-abbrev basically extracts the word before point, looks it up in > a hash-table (actually, an obarray) and then uses the result to do the > expansion (if any). The only part that will get slower with larger > abbrev-tables is the hash-lookup which is coded in C anyway. > > > 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. > > This may be solved by the use of inheritance. I'm looking forward for that. > Although given the rather > limited amount of derived major modes in use, I'm not sure your 500KB would > really shrink that much. > You mentioned abbreviations depending on the context. That could explode the size with the current copying.