From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: search files with conversion but fundamental mode, no handlers, no file-local vars Date: Thu, 20 Dec 2012 14:01:05 -0800 Message-ID: References: <3D2A507FA3EE44909DF7CA025897BFC3@us.oracle.com> <83txrgmtof.fsf@gnu.org> <83sj70mmoz.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1356040878 16792 80.91.229.3 (20 Dec 2012 22:01:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Dec 2012 22:01:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 20 23:01:33 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TloBI-0004uL-LX for ged-emacs-devel@m.gmane.org; Thu, 20 Dec 2012 23:01:32 +0100 Original-Received: from localhost ([::1]:47036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TloB4-0008Qp-Tj for ged-emacs-devel@m.gmane.org; Thu, 20 Dec 2012 17:01:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TloB1-0008LT-7j for emacs-devel@gnu.org; Thu, 20 Dec 2012 17:01:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TloAz-0005iR-Pw for emacs-devel@gnu.org; Thu, 20 Dec 2012 17:01:15 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:49665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TloAv-0005hf-JN; Thu, 20 Dec 2012 17:01:09 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBKM17Jv002374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Dec 2012 22:01:08 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBKM16n7025900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 22:01:07 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBKM16PE023778; Thu, 20 Dec 2012 16:01:06 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Dec 2012 14:01:06 -0800 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83sj70mmoz.fsf@gnu.org> Thread-Index: Ac3e+e7nxK+RoTvjSG2nlrZYc9KxRQAAG2+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155703 Archived-At: > FWIW, I think most, if not all, things inhibited by > mm-insert-file-contents are either not needed or incorrect. > > > (letf* ((format-alist nil) > > (auto-mode-alist (if inhibit nil (mm-auto-mode-alist))) > > auto-mode-alist is not consulted by insert-file-contents, AFAIK. > > > ((default-value 'major-mode) 'fundamental-mode) > > Why? to protect from someone who overrides the default? As I said, I don't have the source code for `insert-file-contents', so I don't know what it does. Why does `mm-i-f-c' redefine `default-value' locally? If `auto-mode-alist' is not used by `i-f-c', and file-local variables are not used, then how would a mode other than fundamental be used by it? I was gathering, from the `mm-i-f-c' code and doc, that `i-f-c' did _not_ protect these things. And unfortunately the doc for `i-f-c' says nothing about any of these things specifically - unlike the doc of `mm-i-f-c'. Who knows what `i-f-c' does or does not do, and how it is really different from `mm-i-f-c'? > > (enable-local-variables nil) > > insert-file-contents does not evaluate file-local variables, AFAIK. So why does `mm-i-f-c' make sure to bind it to ()? > > (after-insert-file-functions nil) > > This decodes the file, which you do want. What is "this"? `after-insert-file-functions'? Or binding that to ()? If the latter, then I guess I need such a binding. The doc for `mm-i-f-c' says that it does code conversion, which I understood to include decoding. Doesn't that mean that this is not done via `after-insert-file-functions', since that is bound to ()? > > (enable-local-eval nil) > > See above. What/where? What does `i-f-c' do wrt `enable-local-eval'? > > (inhibit-file-name-operation (if inhibit > > 'insert-file-contents > > > > inhibit-file-name-operation)) > > (inhibit-file-name-handlers > > (if inhibit > > (append mm-inhibit-file-name-handlers > > inhibit-file-name-handlers) > > inhibit-file-name-handlers)) > > This is a bug, IMO, at least in the general case: why should any code > like what you wanted to write be prevented from working on remote > files? What is the bug? Are you saying that `mm-i-f-c' should not include such a binding? In my case, I do not really want remote file handlers to kick in. What does `i-f-c' do wrt remote files? For a workhorse function, its doc seems quite paltry. About the only thing it is specific about is code conversion. > > (ffh (if (boundp 'find-file-hook) > > 'find-file-hook > > 'find-file-hooks)) > > (val (symbol-value ffh))) > > (set ffh nil) > > I don't think find-file-hook/hooks is relevant, as you don't invoke > find-file here. OK. It's still not at all clear to me which I should use, I'm afraid. Starting with the obvious question: Why, if `i-f-c' does all of what you say, are those bindings needed in `mm-i-f-c'? And why does the `mm-i-f-c' doc make a point of saying that it acts differently in regard to these particular things than does `i-f-c'? You seem to be saying that they act the same (?). Let me be clear: I am not arguing about what the case is or isn't - I'm not arguing at all. I'm just asking, to learn, and (still) wondering what I should use.