From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: auto-detecting encoding for XML Date: Tue, 21 May 2002 15:43:27 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200205211943.g4LJhRV03014@rum.cs.yale.edu> References: <1021775271.29752.2282.camel@space-ghost> <200205192313.g4JNDmk24770@rum.cs.yale.edu> <1021878296.16796.2926.camel@space-ghost> <200205201423.g4KENCL27469@rum.cs.yale.edu> <1021933969.24344.3490.camel@space-ghost> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1022010310 6214 127.0.0.1 (21 May 2002 19:45:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 21 May 2002 19:45:10 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17AFZG-0001c7-00 for ; Tue, 21 May 2002 21:45:10 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17AFnp-0006CY-00 for ; Tue, 21 May 2002 22:00:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17AFZR-00065H-00; Tue, 21 May 2002 15:45:21 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17AFXc-0005VP-00; Tue, 21 May 2002 15:43:28 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g4LJhRV03014; Tue, 21 May 2002 15:43:27 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Colin Walters Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4250 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4250 > > No, it could just use the match-data directly. > Ugh. Relying on `match-data' doesn't appeal to me at all. Why? font-lock-keywords uses that all the time: the function is called only if the regexp matches and it clearly is called right after matching it, so you can use the match-data directly without having to re-match. > > I was thinking of it the other way: the function will most likely need > > to do a regexp search anyway, so why not include it with > > the auto-coding-regexp-alist. > > The main point of allowing arbitrary elisp functions is that you're > *not* limited to just doing a regexp search. With your method, if > someone wanted to write a function which did some sort of minimal "real" > parsing, then they would have to add a null regexp or something to > `auto-coding-regexp-alist' just so their function would be called. That's a nice philosophical argument. I don't think you (or I) can win this argument based on technicalities. The difference is really just a matter of aesthetics. All the actual cases I know of use a regexp-search to start with (these are: sgml-mode, po-mode, latex-mode, babyl). > > Yes, I know it's tricky. But maybe we can come up with something clever. > > In the mean time, I agree that extending auto-coding-regexp-alist is maybe > > the best approach. > > Errr...I never said that extending `auto-coding-regexp-alist' was the > best solution; I think it's not as clean as having a separate > `auto-coding-functions'. I just find extending auto-coding-regexp-alist more Emacs-like, with no loss of generality. If nobody else on this list cares either way, your way is obviously the best way (cause it has a patch, while mine doesn't and I don't care enough to write it). Stefan