Re: Patch for sql.el

[Michael Mauger <mmaug@yahoo.com>]

--- Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > (defun font-lock-add-syntax (syntax-alist)
> > (defun font-lock-remove-syntax (syntax-alist)
> [..]
> > Or are we pushing the feature freeze...?
> 
> Not only that, but I feel it's just adding ad-hoc cruft above ad-hoc
> cruft.
> 

Understood.  I figured it was worth exploring.

> 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.  

I will keep the font-lock reset code as it is for now.  

Thanks for your assistance and recommendations.

Michael


=====

-- 
Michael Mauger 
http://www.geocities.com/mmaug/ 

As my friends know all too well, 
'Mike' is a four-letter word.