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

[Drew Adams]

> > the doc for `mm-i-f-c' mentions "file handlers, format decoding, 
> > `find-file-hook', etc", specifically to _distinguish_ itself
> > from `i-f-c'.
> 
> > The `mm-i-f-c' doc says that it differs from `i-f-c' in that
> > `mm-i-f-c' "only reads in the file".  The implication is 
> > that `i-f-c' does more than just read in the file.  What more,
> > for instance?
> 
> That points to a problem in mm-i-f-c's docstring, not in i-f-c.

Great, and good to know - and not obvious.

So whatever is wrong with that doc string (I cannot determine that) should be
fixed, to avoid misleading users.

> You can't realistically expect i-f-c to confirm or deny every implied
> consequence of the docstring of every foo-insert-file-content 
> out there.

No, of course not.  I could not tell that it was a `mm-i-f-c' doc string
problem.  If you believe the `mm-i-f-c' doc string then it points to an `i-f-c'
doc problem.  If the `mm-i-f-c' doc is not accurate then that is the problem to
fix.

I still think it could also help to make clear more of the things that `i-f-c'
inhibits, whether it is file handlers or hooks or file-local variables or
respect of `auto-mode-alist' or whatever.

In particular, it would help users if you make clear how using `i-f-c' (e.g.
with non-nil VISIT) differs from using `find-file-noselect'.

That would make it easier for users to choose & use these functions.  All the
more so since `i-f-c' is coded in C and that code is likely to be absent.