Re: Emacs24 coding system problems

[Uday Reddy <usr.vm.rocks@gmail.com>]

Eli Zaretskii writes:

> I'm confused: is this problem specific to MS-Windows?  I don't think
> you ever mentioned Windows in this thread before; did I miss
> something?

I didn't know it was specific to Windows either.  But, given that Kazuhiro's
workaround fixed the problem, it must be.

It appears that Emacs24 is not treating `buffer-file-type' as buffer-local
variable, at least in some places inside its guts.  The Bug Report #12989
demonstrated that.

> So let's revisit your last finding.  You said:
> 
> > Tracing through find-file-noselect-1, I found that `rawfile' was set to
> > nil.  Then there is call to `insert-file-contents'.  When it returns,
> > enable-multibyte-characters has been set to nil.
> 
> The logical next step is to find out what happened during the call to
> insert-file-contents.  The most probable suspect is the call to the
> function after-insert-file-set-coding.  insert-file-contents calls it
> after reading the file into a buffer, in order to find the appropriate
> coding-system to set the buffer's buffer-file-coding-system.  Can you
> see what happens inside after-insert-file-set-coding?

insert-file-contents calls find-buffer-file-type-coding-system, which
returns (no-conversion . no-conversion).  enable-multibyte-characters has
been set to nil already.  after-insert-file-set-coding doesn't make any
difference to this.

If I set buffer-file-type to nil and try again:

- find-buffer-file-type-coding-system returns (undecided . undecided).
enable-multibyte-characters is still nil.

- By the time after-insert-file-set-coding gets called,
enable-multibyte-characters has already been set to t.  All is well after
that.

Cheers,
Uday