[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: auto-detecting encoding for XML

From: Stefan Monnier
Subject: Re: auto-detecting encoding for XML
Date: Tue, 21 May 2002 15:43:27 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]