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

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

[Drew Adams]

Suppose I want to check a set of files for one or more occurrences of a given
string.  I want the files to be code-converted, but not put in any mode other
than fundamental mode, not fontified, not handled by a file handler, and not
using any file-local variables.  Just a simple search of the file text (after
code conversion).

I thought there would be a simple, straightforward way to do this, but I didn't
find it.  A RAW-FILE arg to `find-file-noselect' is out, for instance, since
that bypasses code conversion.

I tried a few things and finally ended up using `find-buffer-visiting' or
`create-file-buffer', followed by `with-current-buffer' with a call to
`mm-insert-file-contents'.

That seems to work, but is there a simpler approach?  Am I missing something
obvious?

I finally found `mm-insert-file-contents' because I was little-by-little ending
up with code that looked like what it in fact does.  It seems to turn off quite
a lot of (unrelated?) things individually, just to get a simple file read-in
plus code conversion.

Is there some other function or macro that acts similarly and that is normally
used for the kind of thing described?

I'm kind of wondering why there is not some parameter combination for
`find-file-noselect' that does the job.  The available choices seem to be
completely raw or completely cooked.

I would think that just checking the content of files, with code conversion but
without also enabling hooks, handlers, modes, file-local variables..., would be
something not too uncommon.

And if `mm-insert-file-contents' is indeed the right approach, it seems a bit
odd that this functionality should be buried in a file that is specific to a
particular area ("utility functions for Mule and low level things") rather than
being in, say, `files.el'.

Anyway, please let me know if there is something better than
`mm-insert-file-contents' for this.  Thx.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 20 Dec 2012 10:57:19 -0800
> 
> Suppose I want to check a set of files for one or more occurrences of a given
> string.  I want the files to be code-converted, but not put in any mode other
> than fundamental mode, not fontified, not handled by a file handler, and not
> using any file-local variables.  Just a simple search of the file text (after
> code conversion).
> 
> I thought there would be a simple, straightforward way to do this, but I didn't
> find it.  A RAW-FILE arg to `find-file-noselect' is out, for instance, since
> that bypasses code conversion.
> 
> I tried a few things and finally ended up using `find-buffer-visiting' or
> `create-file-buffer', followed by `with-current-buffer' with a call to
> `mm-insert-file-contents'.
> 
> That seems to work, but is there a simpler approach?  Am I missing something
> obvious?

What's wrong with insert-file-contents?

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

[Drew Adams]

> What's wrong with insert-file-contents?

I'm not sure, now that I try it again!  Thanks for asking.

I tried it earlier, but I was no doubt seeing problems from something else that
I was doing at the same time.

When I finally came across `mm-insert-file-contents' its code looked like TRT
and its doc string seemed to indicate that it was different from
`insert-file-contents' precisely in preventing some of the things I think I want
to prevent.

Brief testing with `insert-file-contents' now seems not to show some of the
problems I encountered before.  But I have not tried cases where file handlers
might kick in etc.  At least I can see that fundamental mode is used, which is
good (one of the main things).

What is the use case for `mm-insert-file-contents'?  I can see that it is
intended only for "low-level" use etc., but it still seems to skip some stuff
that I do not need/want to be done.

Here is the doc string:

"Like `insert-file-contents', but only reads in the file.
A buffer may be modified in several ways after reading into the buffer due
to advanced Emacs features, such as file-name-handlers, format decoding,
`find-file-hooks', etc.
If INHIBIT is non-nil, inhibit `mm-inhibit-file-name-handlers'.
  This function ensures that none of these modifications will take place."

I don't have the C code defining `insert-file-contents', to compare.  but that
doc string does seem to suggest that, _unlike_ `insert-file-contents', it
inhibits the use of "`file-name-handlers,..., `find-file-hooks', etc."  I do not
need/want handlers, hooks, etc. to kick in here.

Here are the bindings made in the function, to inhibit such stuff:

(letf* ((format-alist nil)
         (auto-mode-alist (if inhibit nil (mm-auto-mode-alist)))
         ((default-value 'major-mode) 'fundamental-mode)
         (enable-local-variables nil)
         (after-insert-file-functions nil)
         (enable-local-eval nil)
         (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))
         (ffh (if (boundp 'find-file-hook)
                  'find-file-hook
                'find-file-hooks))
         (val (symbol-value ffh)))
    (set ffh nil)
    (unwind-protect
	(insert-file-contents filename visit beg end replace)
      (set ffh val))))

So `mm-insert-file-contents' still seems, from looking at the code, to be my
best option.

It would seem to be the case that `insert-file-contents' does not nullify
`auto-mode-alist' or set the default mode to fundamental or disable local
variables or...  If not, why is all that done explicitly here, in a wrapper for
`insert-file-contents'?

Still a bit confused...

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Thu, 20 Dec 2012 11:42:55 -0800
> 
> > What's wrong with insert-file-contents?
> 
> I'm not sure, now that I try it again!  Thanks for asking.

I think insert-file-contents _is_ the proper way of doing what you
want.  You can see many examples of its usage in Emacs Lisp packages
bundled with Emacs.

> I don't have the C code defining `insert-file-contents', to compare.  but that
> doc string does seem to suggest that, _unlike_ `insert-file-contents', it
> inhibits the use of "`file-name-handlers,..., `find-file-hooks', etc."  I do not
> need/want handlers, hooks, etc. to kick in here.

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?

>          (enable-local-variables nil)

insert-file-contents does not evaluate file-local variables, AFAIK.

>          (after-insert-file-functions nil)

This decodes the file, which you do want.

>          (enable-local-eval nil)

See above.

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

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

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

[Stefan Monnier]

> Brief testing with `insert-file-contents' now seems not to show some
> of the problems I encountered before.  But I have not tried cases
> where file handlers might kick in etc.  At least I can see that
> fundamental mode is used, which is good (one of the main things).

insert-file-contents does not pay attention to the mode at all, it's
really more like `insert'.

But yes, it does obey file-name-handlers, which is probably what you
want for Tramp files, so the only potential trouble it might introduce
is for encrypted or compressed files (tho whether it introduces
problems depends on what you want to do in the case of such files).


        Stefan

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

[Drew Adams]

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

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

[Drew Adams]

> insert-file-contents does not pay attention to the mode at all, it's
> really more like `insert'.
> 
> But yes, it does obey file-name-handlers, which is probably what you
> want for Tramp files, so the only potential trouble it might introduce
> is for encrypted or compressed files (tho whether it introduces
> problems depends on what you want to do in the case of such files).

OK, from what you and Eli are saying, I'm starting to think that `i-f-c' might
be appropriate for my case.  But I would like to see the doc for `i-f-c' spell
out specifically what it does and does not do.  Like the doc for `mm-i-f-c'
does.

And if the doc for `mm-i-f-c' is wrong about it being different in this or that
respect from `i-f-c', then it would be good to fix that doc too.

And if the code for `mm-i-f-c' contains some useless bindings (after all, it
calls `i-f-c'), then let's remove those, since someone looking at the code can
be misled into thinking that they are needed precisely because `i-f-c' does not
DTRT without them.

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

[Stefan Monnier]

> OK, from what you and Eli are saying, I'm starting to think that
> `i-f-c' might be appropriate for my case.  But I would like to see the
> doc for `i-f-c' spell out specifically what it does and does not do.

I find the current docstring pretty clear, so you'll have to give
more guidance.  As for saying what it doesn't do, that's
a slippery slope.

Most of the things that mm-i-f-c disables are things that apply to
find-file-noselect (which creates a new buffer that is "bound" to
a file), whereas insert-file-contents is really just about inserting
into the current-buffer some text which happens to come from a file
rather than from elsewhere.

> And if the code for `mm-i-f-c' contains some useless bindings (after
> all, it calls `i-f-c'), then let's remove those,

Better ask the Gnus guys about that.  Many of the mm-* functions were
introduced to abstract over differences between emacsen, so maybe
XEmacs's insert-file-contents does other things.


        Stefan

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

[Drew Adams]

> > OK, from what you and Eli are saying, I'm starting to think that
> > `i-f-c' might be appropriate for my case.  But I would like 
> > to see the doc for `i-f-c' spell out specifically what it does
> > and does not do.
> 
> I find the current docstring pretty clear, so you'll have to give
> more guidance.  As for saying what it doesn't do, that's
> a slippery slope.

I cannot prescribe what I do not know.  I can see that 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?

> Most of the things that mm-i-f-c disables are things that apply to
> find-file-noselect (which creates a new buffer that is "bound" to
> a file),

Most, but not all?  Which?

> whereas insert-file-contents is really just about inserting
> into the current-buffer some text which happens to come from a file
> rather than from elsewhere.

Maybe say that - say that it does not involve `find-file-hooks' or whatever
might be the case.

Note that it _does_ have a VISIT argument (which I need here), which records the
fact that the buffer is visiting the file.  That, at least, is documented
(good).

> > And if the code for `mm-i-f-c' contains some useless bindings (after
> > all, it calls `i-f-c'), then let's remove those,
> 
> Better ask the Gnus guys about that.  Many of the mm-* functions were
> introduced to abstract over differences between emacsen, so maybe
> XEmacs's insert-file-contents does other things.

Ask them, if you like.  I guess I should use and be concerned mainly with
`i-f-c', so my interest wrt that is to get its doc to better spell out what it
does.

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

[Stefan Monnier]

> I cannot prescribe what I do not know.  I can see that 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.
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.


        Stefan

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.

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

[Stefan Monnier]

> I still think it could also help to make clear more of the things that
> `i-f-c' inhibits,

i-f-c does not inhibit any of those things, because those things apply
to simply fundamentally different operations.

Try to think of how i-f-c could set the buffer's mode and the
consequences for the various possible use cases, and you'll see
that it simply would be wrong.


        Stefan

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <emacs-devel@gnu.org>
> Date: Thu, 20 Dec 2012 14:01:07 -0800
> 
> OK, from what you and Eli are saying, I'm starting to think that `i-f-c' might
> be appropriate for my case.  But I would like to see the doc for `i-f-c' spell
> out specifically what it does and does not do.

I don't think documenting the internals to such a degree is a good
idea.  It will make the doc string extremely long and tedious to read,
full of details irrelevant to most Lisp programmers.  Just imagine
that insert-file-contents reads in the file's contents, doing TRT with
what that requires, but nothing more.  IOW, you get a buffer with the
file's text, and that's it.

> Like the doc for `mm-i-f-c' does.

No, it does not.  It says "like insert-file-contents, but only reads
in the file."  That doesn't describe much, because "like
insert-file-contents" is still unexplained.  And "just reads in the
file" fits what insert-file-contents does, too.

> And if the doc for `mm-i-f-c' is wrong about it being different in this or that
> respect from `i-f-c', then it would be good to fix that doc too.

I agree.  The only real difference is that it disables file handlers
(something that is not in its doc string, btw), which means remote
files are not supported, compressed files are not decompressed,
etc. -- which most applications like the one you described will
actually want to have.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> 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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <emacs-devel@gnu.org>
> Date: Thu, 20 Dec 2012 14:47:08 -0800
> 
> I cannot prescribe what I do not know.  I can see that the doc for `mm-i-f-c'
> mentions "file handlers, format decoding, `find-file-hook', etc", specifically
> to _distinguish_ itself from `i-f-c'.

You do want both file handlers and format decoding, because without
that, some files will not be inserted "as the user expects".

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <emacs-devel@gnu.org>
> Date: Thu, 20 Dec 2012 20:02:20 -0800
> 
> 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.

I have now added to the doc string of insert-file-contents a reference
to format-decode.  The only other non-trivial thing that
insert-file-contents does is invoke the file handlers, but that is
done by any file primitive we have, so it doesn't make sense to
mention it only in insert-file-contents.  IOW, the fact that file
handlers are invoked is "trivial".

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

This could be ELisp manual stuff, I don't think it's appropriate for a
doc string (revision 111051 on the emacs-24 branch).

The ELisp manual already says something about it, in the node
"Visiting Functions":

  This section describes the functions normally used to visit files.  For
  historical reasons, these functions have names starting with `find-'
  rather than `visit-'.  *Note Buffer File Name::, for functions and
  variables that access the visited file name of a buffer or that find an
  existing buffer by its visited file name.

     In a Lisp program, if you want to look at the contents of a file but
  not alter it, the fastest way is to use `insert-file-contents' in a
  temporary buffer.  Visiting the file is not necessary and takes longer.
  *Note Reading from Files::.

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

[Stefan Monnier]

> You do want both file handlers and format decoding, because without
> that, some files will not be inserted "as the user expects".

BTW, we should probably have some kind of `inhibit-file-content-hooks'
to prevent format-decode, jka-compr, and gpg-decryption,


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 21 Dec 2012 09:44:17 -0500
> Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> > You do want both file handlers and format decoding, because without
> > that, some files will not be inserted "as the user expects".
> 
> BTW, we should probably have some kind of `inhibit-file-content-hooks'
> to prevent format-decode, jka-compr, and gpg-decryption,

Why?  I don't see how it would make sense to inhibit those, because
then you'd have garbage of various levels in the buffer, instead of
the file's contents.

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

[Drew Adams]

> > You do want both file handlers and format decoding, because without
> > that, some files will not be inserted "as the user expects".
> 
> BTW, we should probably have some kind of `inhibit-file-content-hooks'
> to prevent format-decode, jka-compr, and gpg-decryption,

That would be good, yes.

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

[Drew Adams]

> The ELisp manual already says something about it, in the node
> "Visiting Functions":
> 
>      In a Lisp program, if you want to look at the contents 
>   of a file but
>   not alter it, the fastest way is to use `insert-file-contents' in a
>   temporary buffer.  Visiting the file is not necessary and 
>   takes longer.  *Note Reading from Files::.

That is indeed helpful.  I'm sure I read it and read the cross-referenced node
as well, but I somehow did not see the light immediately.  Perhaps adding a
simple example would be helpful.

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

[Stefan Monnier]

>> BTW, we should probably have some kind of `inhibit-file-content-hooks'
>> to prevent format-decode, jka-compr, and gpg-decryption,
> Why?  I don't see how it would make sense to inhibit those, because
> then you'd have garbage of various levels in the buffer, instead of
> the file's contents.

Hmm... I guess the `raw' option is sufficient, indeed, because you
rarely/never need to disable the above conversions while keeping
the decoding.


        Stefan