[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: po file charset via auto-coding-functions
From: |
Richard M. Stallman |
Subject: |
Re: po file charset via auto-coding-functions |
Date: |
Tue, 25 Oct 2005 11:59:18 -0400 |
The current problem is that on extracting vi.po in tar-mode,
a function registered in file-coding-system-alist is called
with a filename "vi.po". So, that function can't check the
contents of that file because it can't read the contents by
insert-file-contents.
I see.
The correct operation in a handler for insert-file-contents
will be to find a buffer pretending to visit the file, and
insert that buffer contents. And, for that, we have to give
buffer-file-name (e.g. /home/handa/x.tgz!vi.po") not the
filename itself (e.g. vi.po) to
find-operation-coding-system. I think such a change is safe
because, at least, all current entries in
file-coding-system-alist checks only the tail of a filename.
If this means passing "/home/handa/x.tgz!vi.po" as the second argument
to find-operation-coding-system, I think it is not clean. That
argument is documented to be _the same_ in meaning as the argument you
would pass to OPERATION, but this string isn't the same, isn't a valid
argument to insert-file-contents.
If we want to modify the calling convention of
find-operation-coding-system, we should do it in a cleaner way: by
binding a global variable. That variable would be nil, normally.
I think the variable's value should be a buffer name.
If the variable is non-nil, it means "the file's contents
are already in this buffer". And all the functions that handle
find-operation-coding-system for various file types should check
the variable.
I think that is a fairly clean solution.
What do you think?
- Re: po file charset via auto-coding-functions, (continued)
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/20
- Re: po file charset via auto-coding-functions, Kevin Ryde, 2005/10/21
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/21
- Re: po file charset via auto-coding-functions, Kevin Ryde, 2005/10/21
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/21
- Re: po file charset via auto-coding-functions, Stefan Monnier, 2005/10/21
- Re: po file charset via auto-coding-functions, Kevin Ryde, 2005/10/22
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/23
- Re: po file charset via auto-coding-functions, Richard M. Stallman, 2005/10/22
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/23
- Re: po file charset via auto-coding-functions,
Richard M. Stallman <=
- Re: po file charset via auto-coding-functions, Kevin Ryde, 2005/10/22
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/23
- Re: po file charset via auto-coding-functions, Kevin Ryde, 2005/10/23
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/24
- Re: po file charset via auto-coding-functions, Stefan Monnier, 2005/10/24
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/24
- Re: po file charset via auto-coding-functions, Juri Linkov, 2005/10/24
- Re: po file charset via auto-coding-functions, Kenichi Handa, 2005/10/25
- Re: po file charset via auto-coding-functions, Richard M. Stallman, 2005/10/25
Re: po file charset via auto-coding-functions, Richard M. Stallman, 2005/10/21