* Should `auto-coding-functions' be mode-specific?
@ 2007-01-02 20:43 Romain Francoise
2007-01-02 22:14 ` Lennart Borgman (gmail)
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Romain Francoise @ 2007-01-02 20:43 UTC (permalink / raw)
Cc: Vincent Lefevre
I received a bug report from a Debian user (CC'd) who was surprised
to see that Emacs 22 opens one of his utf-8-encoded files as ASCII,
because it contains the following HTML snippet near the top:
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
| <HTML><HEAD>
| <META http-equiv=Content-Type content="text/html; charset=us-ascii">
| </HEAD>
| <BODY>
| </BODY></HTML>
The file itself is not an HTML file, but Emacs still uses the
encoding specified in the HTML code to set the encoding. (This is
caused by `sgml-html-meta-auto-coding-function', which is present by
default in the list of `auto-coding-functions' -- the functions are
tried in the first 1K or last 3K bytes of the buffer.)
I replied that the encoding can be forced using a -*- coding: .. -*-
cookie, but the submitter argues that the functions to get the
encoding from the file's contents should only be enabled in modes
where the content of the buffer is supposed to match -- i.e. don't
use the META header function in buffers that aren't in html-mode (or
equivalent).
What do people think?
(See http://bugs.debian.org/404236 for the discussion.)
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-02 20:43 Should `auto-coding-functions' be mode-specific? Romain Francoise
@ 2007-01-02 22:14 ` Lennart Borgman (gmail)
2007-01-03 0:54 ` Kevin Ryde
` (2 subsequent siblings)
3 siblings, 0 replies; 17+ messages in thread
From: Lennart Borgman (gmail) @ 2007-01-02 22:14 UTC (permalink / raw)
Cc: Vincent Lefevre, emacs-devel
Romain Francoise wrote:
> I received a bug report from a Debian user (CC'd) who was surprised
> to see that Emacs 22 opens one of his utf-8-encoded files as ASCII,
> because it contains the following HTML snippet near the top:
>
> | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> | <HTML><HEAD>
> | <META http-equiv=Content-Type content="text/html; charset=us-ascii">
> | </HEAD>
> | <BODY>
> | </BODY></HTML>
>
> The file itself is not an HTML file, but Emacs still uses the
> encoding specified in the HTML code to set the encoding. (This is
> caused by `sgml-html-meta-auto-coding-function', which is present by
> default in the list of `auto-coding-functions' -- the functions are
> tried in the first 1K or last 3K bytes of the buffer.)
>
> I replied that the encoding can be forced using a -*- coding: .. -*-
> cookie, but the submitter argues that the functions to get the
> encoding from the file's contents should only be enabled in modes
> where the content of the buffer is supposed to match -- i.e. don't
> use the META header function in buffers that aren't in html-mode (or
> equivalent).
>
> What do people think?
>
> (See http://bugs.debian.org/404236 for the discussion.)
>
>
IIt seems clear to me that this must be mode specific. Just a silly
example: Suppose someone saves something like the html-snippet above in
a customization.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-02 20:43 Should `auto-coding-functions' be mode-specific? Romain Francoise
2007-01-02 22:14 ` Lennart Borgman (gmail)
@ 2007-01-03 0:54 ` Kevin Ryde
2007-01-03 3:34 ` Richard Stallman
2007-01-03 5:26 ` Kevin Rodgers
3 siblings, 0 replies; 17+ messages in thread
From: Kevin Ryde @ 2007-01-03 0:54 UTC (permalink / raw)
Romain Francoise <romain@orebokech.com> writes:
>
> i.e. don't use the META header function in buffers that aren't in
> html-mode (or equivalent).
When this came up a while ago about .po and gutenberg .txt, I thought
a filename could be bound/offered to the auto-coding-functions funcs,
so they could limit themselves if they felt the need. Maybe the html
one could just check the text starts with "<html>" (perhaps after a
<!-- comment).
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-02 20:43 Should `auto-coding-functions' be mode-specific? Romain Francoise
2007-01-02 22:14 ` Lennart Borgman (gmail)
2007-01-03 0:54 ` Kevin Ryde
@ 2007-01-03 3:34 ` Richard Stallman
2007-01-03 12:09 ` Vincent Lefevre
2007-01-03 5:26 ` Kevin Rodgers
3 siblings, 1 reply; 17+ messages in thread
From: Richard Stallman @ 2007-01-03 3:34 UTC (permalink / raw)
Cc: vincent, emacs-devel
The file itself is not an HTML file, but Emacs still uses the
encoding specified in the HTML code to set the encoding. (This is
caused by `sgml-html-meta-auto-coding-function', which is present by
default in the list of `auto-coding-functions' -- the functions are
tried in the first 1K or last 3K bytes of the buffer.)
Emacs examines these parts of the file to determine the coding system
before it reads the whole file, so it can use the chosen coding system
to do the reading. Choosing the major mode comes later, after reading
the whole file.
but the submitter argues that the functions to get the
encoding from the file's contents should only be enabled in modes
where the content of the buffer is supposed to match -- i.e. don't
use the META header function in buffers that aren't in html-mode (or
equivalent).
It does sound more correct, but given the order in which things
are done, it would be very difficult.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-02 20:43 Should `auto-coding-functions' be mode-specific? Romain Francoise
` (2 preceding siblings ...)
2007-01-03 3:34 ` Richard Stallman
@ 2007-01-03 5:26 ` Kevin Rodgers
2007-01-03 14:18 ` Ralf Mattes
2007-01-04 8:44 ` Romain Francoise
3 siblings, 2 replies; 17+ messages in thread
From: Kevin Rodgers @ 2007-01-03 5:26 UTC (permalink / raw)
Romain Francoise wrote:
> I received a bug report from a Debian user (CC'd) who was surprised
> to see that Emacs 22 opens one of his utf-8-encoded files as ASCII,
> because it contains the following HTML snippet near the top:
>
> | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> | <HTML><HEAD>
> | <META http-equiv=Content-Type content="text/html; charset=us-ascii">
> | </HEAD>
> | <BODY>
> | </BODY></HTML>
>
> The file itself is not an HTML file, but Emacs still uses the
> encoding specified in the HTML code to set the encoding. (This is
> caused by `sgml-html-meta-auto-coding-function', which is present by
> default in the list of `auto-coding-functions' -- the functions are
> tried in the first 1K or last 3K bytes of the buffer.)
>
> I replied that the encoding can be forced using a -*- coding: .. -*-
> cookie, but the submitter argues that the functions to get the
> encoding from the file's contents should only be enabled in modes
> where the content of the buffer is supposed to match -- i.e. don't
> use the META header function in buffers that aren't in html-mode (or
> equivalent).
The other default element of auto-coding-functions is
sgml-xml-auto-coding-function, which looks for the encoding specified in
the XML declaration but is careful to ensure that the declaration occurs
at the beginning of the buffer (optionally preceded by whitespace, as
allowed by the XML spec). Shouldn't sgml-html-meta-auto-coding-function
ensure that the <meta> tag occurs within an HTML document, by also
matching an appropriate pattern at the beginning buffer?
I know there is more variation in what is allowed at the beginning of an
HTML document compared to an XML document, but I think it would be an
improvement to require either an HTML document type declaration or an
<html> tag (optionally preceded by whitespace):
(when (re-search-forward
"\\`[[:space:]\n]*\\(<!doctype[[:space:]\n]+html\\|<html\\)"
size t)
...)
Finally, note the following ChangeLog entry, which describes the patch
proposed by Juri in
<URL:http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00916.html>
to handle invalid HTML (such as Mozilla Firefox bookmark files):
2006-06-02 Juri Linkov <juri@jurta.org>
* international/mule.el (sgml-html-meta-auto-coding-function):
Remove the condition `(search-forward "<html" size t)'.
Replace `\"' with `[\"']?' in `re-search-forward'.
I agree that Emacs should not be too pedantic about HTML, but I don't
think it's too much to require an <html> tag before the <meta> tag. The
bug reported by the Debian user concerns a file which is clearly not an
HTML file even though it contains a valid HTML document, because of the
text that precedes the markup.
> What do people think?
>
> (See http://bugs.debian.org/404236 for the discussion.)
--
Kevin Rodgers
Denver, Colorado, USA
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-03 3:34 ` Richard Stallman
@ 2007-01-03 12:09 ` Vincent Lefevre
2007-01-04 2:31 ` Richard Stallman
0 siblings, 1 reply; 17+ messages in thread
From: Vincent Lefevre @ 2007-01-03 12:09 UTC (permalink / raw)
Cc: Romain Francoise, emacs-devel
On 2007-01-02 22:34:55 -0500, Richard Stallman wrote:
> Emacs examines these parts of the file to determine the coding system
> before it reads the whole file, so it can use the chosen coding system
> to do the reading. Choosing the major mode comes later, after reading
> the whole file.
This explains the problem. But anyway, there was some text before
the HTML code, meaning that the HTML code was included in some text
file. So, in this case, I don't think taking the charset from the
META header is a correct behavior.
> but the submitter argues that the functions to get the
> encoding from the file's contents should only be enabled in modes
> where the content of the buffer is supposed to match -- i.e. don't
> use the META header function in buffers that aren't in html-mode (or
> equivalent).
>
> It does sound more correct, but given the order in which things
> are done, it would be very difficult.
Couldn't a second pass be performed?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-03 5:26 ` Kevin Rodgers
@ 2007-01-03 14:18 ` Ralf Mattes
2007-01-04 8:44 ` Romain Francoise
1 sibling, 0 replies; 17+ messages in thread
From: Ralf Mattes @ 2007-01-03 14:18 UTC (permalink / raw)
On Tue, 02 Jan 2007 22:26:22 -0700, Kevin Rodgers wrote:
> The other default element of auto-coding-functions is
> sgml-xml-auto-coding-function, which looks for the encoding specified in
> the XML declaration but is careful to ensure that the declaration occurs
> at the beginning of the buffer (optionally preceded by whitespace, as
> allowed by the XML spec).
Oh, thank's for looking at this: this is a bug :-)
The XML spec _doesn't allow whitespace in front of the XML declaration -
the only thing explicitly allowed is the BOM (byte order mark), and that
_isn't_ whitespace.
Cheers Ralf Mattes
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-03 12:09 ` Vincent Lefevre
@ 2007-01-04 2:31 ` Richard Stallman
2007-01-04 4:14 ` Kenichi Handa
0 siblings, 1 reply; 17+ messages in thread
From: Richard Stallman @ 2007-01-04 2:31 UTC (permalink / raw)
Cc: vincent, romain, handa, emacs-devel
This explains the problem. But anyway, there was some text before
the HTML code, meaning that the HTML code was included in some text
file. So, in this case, I don't think taking the charset from the
META header is a correct behavior.
That criterion is perhaps feasible to implement.
Handa, what do you think?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-04 2:31 ` Richard Stallman
@ 2007-01-04 4:14 ` Kenichi Handa
2007-01-04 19:02 ` Romain Francoise
2007-01-04 22:33 ` Richard Stallman
0 siblings, 2 replies; 17+ messages in thread
From: Kenichi Handa @ 2007-01-04 4:14 UTC (permalink / raw)
Cc: vincent, romain, walters, emacs-devel
In article <E1H2IOA-0002Wy-NM@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> This explains the problem. But anyway, there was some text before
> the HTML code, meaning that the HTML code was included in some text
> file. So, in this case, I don't think taking the charset from the
> META header is a correct behavior.
> That criterion is perhaps feasible to implement.
> Handa, what do you think?
Perhaps. Currently sgml-xml-auto-coding-function and
sgml-html-meta-auto-coding-function are registred in
auto-coding-functions.
And sgml-xml-auto-coding-function checks whether the buffer
is XML or not. So, sgml-html-meta-auto-coding-function
should do the similar check too. Someone who knows the
syntax of HTML well, please fix the function.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-03 5:26 ` Kevin Rodgers
2007-01-03 14:18 ` Ralf Mattes
@ 2007-01-04 8:44 ` Romain Francoise
2007-01-06 23:33 ` Juri Linkov
1 sibling, 1 reply; 17+ messages in thread
From: Romain Francoise @ 2007-01-04 8:44 UTC (permalink / raw)
Cc: Juri Linkov
Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> 2006-06-02 Juri Linkov <juri@jurta.org>
> * international/mule.el (sgml-html-meta-auto-coding-function):
> Remove the condition `(search-forward "<html" size t)'.
Thanks for noticing this Kevin, I had missed it. I think this
change should be reverted, it's okay to make Emacs handle Mozilla's
broken HTML, but only as long as it doesn't get in the way of valid
use cases!
And your proposed change to also recognize a doctype at the
beginning of the buffer looks good to me.
So unless someone objects, I'll revert Juri's change and extend the
function as Kevin suggests. Perhaps I'll also make it recognize
Mozilla's specific doctype ('<!DOCTYPE NETSCAPE-Bookmark-file-1>').
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-04 4:14 ` Kenichi Handa
@ 2007-01-04 19:02 ` Romain Francoise
2007-01-04 22:33 ` Richard Stallman
1 sibling, 0 replies; 17+ messages in thread
From: Romain Francoise @ 2007-01-04 19:02 UTC (permalink / raw)
Cc: vincent, rms, walters, emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> So, sgml-html-meta-auto-coding-function should do the similar
> check too. Someone who knows the syntax of HTML well, please fix
> the function.
I'll do that (tomorrow).
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-04 4:14 ` Kenichi Handa
2007-01-04 19:02 ` Romain Francoise
@ 2007-01-04 22:33 ` Richard Stallman
2007-01-05 18:04 ` Romain Francoise
1 sibling, 1 reply; 17+ messages in thread
From: Richard Stallman @ 2007-01-04 22:33 UTC (permalink / raw)
Cc: vincent, romain, walters, emacs-devel
And sgml-xml-auto-coding-function checks whether the buffer
is XML or not. So, sgml-html-meta-auto-coding-function
should do the similar check too. Someone who knows the
syntax of HTML well, please fix the function.
Would someone please do this, then ack?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-04 22:33 ` Richard Stallman
@ 2007-01-05 18:04 ` Romain Francoise
0 siblings, 0 replies; 17+ messages in thread
From: Romain Francoise @ 2007-01-05 18:04 UTC (permalink / raw)
Cc: vincent, emacs-devel, walters, Kenichi Handa
Richard Stallman <rms@gnu.org> writes:
> Would someone please do this, then ack?
Done.
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-04 8:44 ` Romain Francoise
@ 2007-01-06 23:33 ` Juri Linkov
2007-01-07 13:47 ` Romain Francoise
0 siblings, 1 reply; 17+ messages in thread
From: Juri Linkov @ 2007-01-06 23:33 UTC (permalink / raw)
>> 2006-06-02 Juri Linkov <juri@jurta.org>
>
>> * international/mule.el (sgml-html-meta-auto-coding-function):
>> Remove the condition `(search-forward "<html" size t)'.
>
> Thanks for noticing this Kevin, I had missed it. I think this
> change should be reverted, it's okay to make Emacs handle Mozilla's
> broken HTML, but only as long as it doesn't get in the way of valid
> use cases!
>
> And your proposed change to also recognize a doctype at the
> beginning of the buffer looks good to me.
>
> So unless someone objects, I'll revert Juri's change and extend the
> function as Kevin suggests. Perhaps I'll also make it recognize
> Mozilla's specific doctype ('<!DOCTYPE NETSCAPE-Bookmark-file-1>').
The reported bug can occur even without my change because "<html" was
not anchored at the beginning of the buffer and can match "<html" in
the presented HTML snippet near the top.
Your change is an improvement since it reduces the false positive
rate while not significantly increasing the false negative rate.
But then why not to go further and use the same regexp as used for
detecting HTML files in `magic-mode-alist'? It seems reasonable
to detect the HTML encoding exactly in the same files that later
recognized as HTML according to the file contents.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-06 23:33 ` Juri Linkov
@ 2007-01-07 13:47 ` Romain Francoise
2007-01-07 16:22 ` Juri Linkov
0 siblings, 1 reply; 17+ messages in thread
From: Romain Francoise @ 2007-01-07 13:47 UTC (permalink / raw)
Juri Linkov <juri@jurta.org> writes:
> The reported bug can occur even without my change because "<html"
> was not anchored at the beginning of the buffer and can match
> "<html" in the presented HTML snippet near the top.
Right.
> But then why not to go further and use the same regexp as used for
> detecting HTML files in `magic-mode-alist'? It seems reasonable
> to detect the HTML encoding exactly in the same files that later
> recognized as HTML according to the file contents.
I think it's a good idea, and it is easy to do (see below).
But it would reopen your original issue: that encoding detection
doesn't work in Mozilla bookmark files.
Index: lisp/international/mule.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/international/mule.el,v
retrieving revision 1.250
diff -c -r1.250 mule.el
*** lisp/international/mule.el 5 Jan 2007 17:58:02 -0000 1.250
--- lisp/international/mule.el 7 Jan 2007 13:43:29 -0000
***************
*** 2292,2309 ****
;; In case of no header, search only 10 lines.
(forward-line 10))
(point))))
! ;; Make sure that the buffer really contains an HTML document, by
! ;; checking that it starts with a doctype or a <HTML> start tag
! ;; (allowing for whitespace at bob). Note: 'DOCTYPE NETSCAPE' is
! ;; useful for Mozilla bookmark files.
! (when (and (re-search-forward "\\`[[:space:]\n]*\\(<!doctype[[:space:]\n]+\\(html\\|netscape\\)\\|<html\\)" size t)
! (re-search-forward "<meta\\s-+http-equiv=[\"']?content-type[\"']?\\s-+content=[\"']text/\\sw+;\\s-*charset=\\(.+?\\)[\"']" size t))
! (let* ((match (match-string 1))
! (sym (intern (downcase match))))
! (if (coding-system-p sym)
! sym
! (message "Warning: unknown coding system \"%s\"" match)
! nil))))
;;;
(provide 'mule)
--- 2292,2311 ----
;; In case of no header, search only 10 lines.
(forward-line 10))
(point))))
! ;; Make sure that the buffer really contains an HTML document. We
! ;; assume that the first entry that associates itself to html-mode in
! ;; `magic-mode-alist' is good enough to detect HTML documents
! ;; reliably.
! (let ((html-re (car (rassoc 'html-mode magic-mode-alist))))
! (when (and html-re
! (re-search-forward (concat "\\`" html-re) size t)
! (re-search-forward "<meta\\s-+http-equiv=[\"']?content-type[\"']?\\s-+content=[\"']text/\\sw+;\\s-*charset=\\(.+?\\)[\"']" size t))
! (let* ((match (match-string 1))
! (sym (intern (downcase match))))
! (if (coding-system-p sym)
! sym
! (message "Warning: unknown coding system \"%s\"" match)
! nil)))))
;;;
(provide 'mule)
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-07 13:47 ` Romain Francoise
@ 2007-01-07 16:22 ` Juri Linkov
2007-01-08 19:46 ` Romain Francoise
0 siblings, 1 reply; 17+ messages in thread
From: Juri Linkov @ 2007-01-07 16:22 UTC (permalink / raw)
>> But then why not to go further and use the same regexp as used for
>> detecting HTML files in `magic-mode-alist'? It seems reasonable
>> to detect the HTML encoding exactly in the same files that later
>> recognized as HTML according to the file contents.
>
> I think it's a good idea, and it is easy to do (see below).
> But it would reopen your original issue: that encoding detection
> doesn't work in Mozilla bookmark files.
Mozilla bookmark files get detected as SGML according to the sgml-mode
rule in magic-mode-alist. This is ok to visit Mozilla bookmark files
in SGML mode, since these are not quite HTML files, but nonetheless
we should try to detect their encoding.
We either could create a new function sgml-meta-auto-coding-function
(like sgml-html-meta-auto-coding-function), or add encoding detection
of HTML-like SGML files to sgml-html-meta-auto-coding-function by
fetching and applying the sgml-mode rule as well as html-mode rule
from magic-mode-alist.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should `auto-coding-functions' be mode-specific?
2007-01-07 16:22 ` Juri Linkov
@ 2007-01-08 19:46 ` Romain Francoise
0 siblings, 0 replies; 17+ messages in thread
From: Romain Francoise @ 2007-01-08 19:46 UTC (permalink / raw)
Juri Linkov <juri@jurta.org> writes:
> We either could create a new function sgml-meta-auto-coding-function
> (like sgml-html-meta-auto-coding-function), or add encoding detection
> of HTML-like SGML files to sgml-html-meta-auto-coding-function by
> fetching and applying the sgml-mode rule as well as html-mode rule
> from magic-mode-alist.
I guess.
On the other hand, this hook runs every single time you save a file,
doing this would use resources for the benefit of a rather obscure
special case.
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2007-01-08 19:46 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-02 20:43 Should `auto-coding-functions' be mode-specific? Romain Francoise
2007-01-02 22:14 ` Lennart Borgman (gmail)
2007-01-03 0:54 ` Kevin Ryde
2007-01-03 3:34 ` Richard Stallman
2007-01-03 12:09 ` Vincent Lefevre
2007-01-04 2:31 ` Richard Stallman
2007-01-04 4:14 ` Kenichi Handa
2007-01-04 19:02 ` Romain Francoise
2007-01-04 22:33 ` Richard Stallman
2007-01-05 18:04 ` Romain Francoise
2007-01-03 5:26 ` Kevin Rodgers
2007-01-03 14:18 ` Ralf Mattes
2007-01-04 8:44 ` Romain Francoise
2007-01-06 23:33 ` Juri Linkov
2007-01-07 13:47 ` Romain Francoise
2007-01-07 16:22 ` Juri Linkov
2007-01-08 19:46 ` Romain Francoise
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).