Re: Scanning for coding declarations in all files (not just source)

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> I just discovered that Guile is scanning for coding declarations in
> *all* files opened with 'open-file', not just source files.

Yeah, I don’t really like it either.

> For source files, we are scanning for coding declarations twice: once
> when when the file is opened, and a second time when 'compile-file' or
> 'primitive-load' explicitly scans for it.

Yes, I think I’m used to writing things like:

  (call-with-input-file file
    (lambda (p)
      (set-port-encoding! p (file-encoding p))
      ...))
      
when I really want that behavior.

One thing I noticed lately is that ‘call-with-input-file’ & co. never
use the “b” flag, so if what you want is really an binary input file,
you have to resort to hacks like:

  (define (call-with-latin1-input-file file proc)
    "Open FILE as an latin1 or binary file, and pass the resulting port to
  PROC.  FILE is closed when PROC's dynamic extent is left.  Return the
  return values of applying PROC to the port."
    (let ((port (with-fluids ((%default-port-encoding #f))
                  ;; Use "b" so that `open-file' ignores `coding:' cookies.
                  (open-file file "rb"))))
      (dynamic-wind
        (lambda ()
          #t)
        (lambda ()
          (proc port))
        (lambda ()
          (close-input-port port)))))

Also, guessing for all files may cause problems with non-seekable files,
or pseudo files.

> I don't like this.  I don't want 'open-file' to second-guess the
> encoding I have asked for in my program, based on data in the file.
> Also, the manual is misleading.  Section 6.17.8 gives the impression
> that the scanning is only done for source files.

That may reflect what I’ve been thinking for some time.  ;-)

Mike Gran <spk121@yahoo.com> skribis:

> Opening a file that contains a coding declaration using an encoding other
> than binary or the coding declared in the file seems like it would be
> something of a corner case.  So, IMHO it makes sense that opening a file
> using its self-declared encoding should be the simple case, and that
> opening a text file in a different (non-binary) text encoding should
> be the more complicated case, in a API sense.

That’s also true.  In Emacs, we want files to be opened with the right
encoding, whatever happens; so in some cases we could have the same
expectations here.

As usual, backward-compatibility gives us an incentive not to change
anything in 2.0.  But perhaps we should change that in 2.2.

Thoughts?

Ludo’.