Re: search files with conversion but fundamental mode, no handlers, no file-local vars

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Cc: <address@hidden>
> Date: Thu, 20 Dec 2012 14:01:05 -0800
> 
> Why does `mm-i-f-c' redefine `default-value' locally?

No clue.  Probably, Stefan is right, and this has nothing to do with
GNU Emacs.

> 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?

It won't, not in GNU Emacs.

> 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'?

I don't think a doc string should say what variables a function does
NOT pay attention to.  It does say that it performs code conversions;
anything else it just does NOT do, period.

> > >          (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.

Neither.  Sorry, I confused this variable with another.  This variable
is nil by default, and not set by any Emacs feature AFAICS, so it
doesn't affect insert-file-contents unless customized.

> > >          (enable-local-eval nil)
> > 
> > See above.
> 
> What/where?  What does `i-f-c' do wrt `enable-local-eval'?

insert-file-contents does nothing with 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?

Yes, and neither should you.

> In my case, I do not really want remote file handlers to kick in.

Why not?  And what about compressed files -- don't you want to support
those?  They are also supported through file handlers.

> What does `i-f-c' do wrt remote files?

It calls the appropriate handler, so that the contents of the remote
file will be inserted into the buffer as result.

> It's still not at all clear to me which I should use, I'm afraid.

Just use insert-file-contents, that's what it's for.  Then, if you see
any problems, raise those problems specifically.  In general, I don't
expect you to have any problems, because insert-file-contents is
_precisely_ for these use cases.

> 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 (?).

That's a question to whoever wrote that function.  As I said, most, if
not all, of what it does is unneeded or incorrect.