Re: po file charset via auto-coding-functions

[Richard Stallman]

[I sent this message twice but did not get a response.
Could we get the discussion moving again?]

    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?