From: Eli Zaretskii <eliz@gnu.org>
To: Kenichi Handa <handa@m17n.org>
Cc: emacs-devel@gnu.org
Subject: Re: EOL conversion of files in .tar archives
Date: Thu, 24 May 2007 11:32:56 +0300 [thread overview]
Message-ID: <uy7jeiptz.fsf@gnu.org> (raw)
In-Reply-To: <E1Hr8Tj-0003Nf-FD@etlken.m17n.org> (message from Kenichi Handa on Thu, 24 May 2007 17:15:23 +0900)
> From: Kenichi Handa <handa@m17n.org>
> CC: emacs-devel@gnu.org
> Date: Thu, 24 May 2007 17:15:23 +0900
>
> > I'm uneasy with that change, because there are other places that use a
> > cons cell as the second argument to find-operation-coding-system, and
> > I'm not sure what you propose is good for them. For example, mule.el
> > defines a utility function decode-coding-inserted-region that also
> > uses a cons cell. (This utility function is currently used in
> > jka-compr.el, pcvs.el and url-handlers.el.) Both it and its users are
> > sufficiently complex that I couldn't easily decide whether the change
> > you suggest will DTRT for them. Can you help me understand that?
>
> The docstring of find-operation-coding-system has this
> paragraph.
>
> If operation is `insert-file-contents', the argument corresponding to
> TARGET may be a cons (FILENAME . BUFFER). In that case, FILENAME is a
> file name to look up, and BUFFER is a buffer that contains the file's
> contents (not yet decoded). If `file-coding-system-alist' specifies a
> function to call for FILENAME, that function should examine the
> contents of BUFFER instead of reading the file.
>
> So, find-buffer-file-type-coding-system should handle
> (FILENAME . BUFFER) as described above.
Well, but it doesn't: it does NOT examine the contents of BUFFER at
all; it relies on that to be done when it returns undecided. And that
is the reason I asked the question about decode-coding-inserted-region:
I'm not sure it will look at the region's contents to find the encoding,
and neither am I sure what should be done in that context, since we
are inserting only a portion of the buffer.
So I'd still be happy to know whether your suggestion is not going to
break decode-coding-inserted-region and its users.
> That function has this code:
>
> ;; For any other existing file, decide based on contents.
> ((file-exists-p target)
> (setq undecided t))
>
> If file-exists-p is used to check whether or not there
> exists contents that can decide EOL type, isn't it TRT to
> return undecided in (FILENAME . BUFFER) case.
It's probably so, but I'm still not sure. Also, please note that
returning undecided will cause the text encoding to be detected, not
only the EOL type.
next prev parent reply other threads:[~2007-05-24 8:32 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 19:28 EOL conversion of files in .tar archives Eli Zaretskii
2007-05-21 4:48 ` Kenichi Handa
2007-05-21 5:15 ` David Kastrup
2007-05-21 19:54 ` Eli Zaretskii
2007-05-22 8:30 ` Richard Stallman
2007-05-23 18:43 ` Eli Zaretskii
2007-05-21 20:45 ` Eli Zaretskii
2007-05-21 22:58 ` Chong Yidong
2007-05-22 6:39 ` Eli Zaretskii
2007-05-22 6:53 ` David Kastrup
2007-05-22 7:01 ` Eli Zaretskii
2007-05-22 15:49 ` Richard Stallman
2007-05-22 16:25 ` Eli Zaretskii
2007-05-22 14:52 ` Richard Stallman
2007-05-22 21:20 ` David Kastrup
2007-05-22 14:52 ` Richard Stallman
2007-05-22 16:20 ` Eli Zaretskii
2007-05-22 11:19 ` Eli Zaretskii
2007-05-22 12:21 ` Eli Zaretskii
2007-05-22 21:10 ` Chong Yidong
2007-05-22 21:18 ` Lennart Borgman (gmail)
2007-05-22 21:19 ` Chong Yidong
2007-05-23 6:56 ` Eli Zaretskii
2007-05-23 3:18 ` Chong Yidong
2007-05-23 5:58 ` Kenichi Handa
2007-05-23 7:15 ` Eli Zaretskii
2007-05-23 12:34 ` Eli Zaretskii
2007-05-23 13:01 ` Kenichi Handa
2007-05-23 17:33 ` Eli Zaretskii
2007-05-23 18:02 ` David Kastrup
2007-05-23 18:32 ` Eli Zaretskii
2007-05-23 18:43 ` David Kastrup
2007-05-24 1:01 ` Kenichi Handa
2007-05-24 7:48 ` Eli Zaretskii
2007-05-24 8:15 ` Kenichi Handa
2007-05-24 8:32 ` Eli Zaretskii [this message]
2007-05-27 5:45 ` Kenichi Handa
2007-05-27 23:21 ` Richard Stallman
2007-05-28 3:12 ` Eli Zaretskii
2007-05-29 0:02 ` Richard Stallman
2007-05-23 13:31 ` Chong Yidong
2007-05-23 17:32 ` Eli Zaretskii
2007-05-22 23:09 ` Richard Stallman
2007-05-23 7:03 ` Eli Zaretskii
2007-05-23 18:56 ` Richard Stallman
2007-05-23 0:59 ` Chong Yidong
2007-05-23 18:45 ` Chong Yidong
2007-05-23 19:31 ` Eli Zaretskii
2007-05-23 1:22 ` Kenichi Handa
2007-05-23 7:10 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=uy7jeiptz.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=handa@m17n.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).