From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: Patch for sql.el Date: Fri, 07 May 2004 10:48:19 -0600 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <409BBDD3.40803@yahoo.com> References: <20040507152703.46444.qmail@web60306.mail.yahoo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1083948927 24586 80.91.224.253 (7 May 2004 16:55:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 May 2004 16:55:27 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 07 18:55:20 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BM8d6-00079d-00 for ; Fri, 07 May 2004 18:55:20 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BM8d5-0003sR-00 for ; Fri, 07 May 2004 18:55:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BM8XJ-0005eJ-8D for emacs-devel@quimby.gnus.org; Fri, 07 May 2004 12:49:21 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BM8Wl-0005d5-41 for emacs-devel@gnu.org; Fri, 07 May 2004 12:48:47 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BM8WE-0005Tj-AZ for emacs-devel@gnu.org; Fri, 07 May 2004 12:48:46 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BM8WD-0005TP-MA for emacs-devel@gnu.org; Fri, 07 May 2004 12:48:13 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BM8WA-0007Or-00 for ; Fri, 07 May 2004 18:48:13 +0200 Original-Received: from 170.207.51.80 ([170.207.51.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 May 2004 18:48:10 +0200 Original-Received: from ihs_4664 by 170.207.51.80 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 May 2004 18:48:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 31 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 170.207.51.80 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22908 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22908 Michael Mauger wrote: > --- Stefan Monnier wrote: >>Is there any particular reason why you don't merge all those submodes >>and simply handle a language that's a superset of all? Basically >>accept @ # $ as symbol components, and accept all the keywords of all >>the known servers... That should simplify your code. > > The problem with SQL is that there is no real standard. The core is > standard, but the functions and procedural extensions vary significantly > from one product to another. > > One of the reasons I originally started using sql-mode was that I was > using two database products at the same time (oracle and ms). The > product specific features helped keep me sane. For example, Oracle calls > its sub-string function `substr' whereas MS (and ANSI) call it > `substring'. I go back 20+ years with Oracle so my instinct is the > abbreviated form. When I used the abbreviated form in MS scripts I had > immediate feedback that I had used the wrong form. > > I have one more patch coming for sql.el that removes, at compile time, > keywords in product specific lists that are also in the ANSI list. This > slows the compile time, but seems to speed up the fontification. It also > allows me to keep the entire product specific keyword lists in the source > without manually filtering out the keywords duplicated in ANSI. Why not define the vendor-specific modes as derived modes? Would that simplify things? -- Kevin Rodgers