bug#22096: 25.0.50; reading from fifo breaks display

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]


I suppose this is two issues, really. I am trying to read from a FIFO,
specifically one written to by mpd, configured in mpd.conf with

audio_output {
  type "fifo"
  name "FIFO"
  path "/tmp/mpd.fifo"
  format "44100:16:2"
}

With mpd running I can see that the FIFO is there and I can read from it
with other tools/mpd clients.

(info "(elisp) Reading from Files") suggests I should be able to read
from a FIFO. From emacs -Q, insert the following into the scratch buffer:

(insert-file-contents "/tmp/mpd.fifo" nil 0 10 nil)

First issue: evaluating this yields

(file-error "not a regular file" "/tmp/mpd.fifo")

Second issue: changing the VISIT argument to t and evaluating:

(insert-file-contents "/tmp/mpd.fifo" t 0 10 nil)

breaks the display engine. "nil)" becomes invisible, the last "r" in the
scratch buffer message becomes fontified as a matching paren, and
hitting C-a at the end of the form takes me to the aforementioned "r".
I have attached an image.


[-- Attachment #2: broken display --]
[-- Type: image/png, Size: 7049 bytes --]

[-- Attachment #3: Type: text/plain, Size: 4152 bytes --]





In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2015-12-03
Repository revision: eaa1fd6dbff8346eb38485de5ebf0fbfacf374d9
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --without-gconf --with-modules
 --with-x-toolkit=lucid 'CFLAGS=-march=x86-64 -mtune=generic -O0 -pipe
 -fstack-protector-strong --param=ssp-buffer-size=4 -g
 -fvar-tracking-assignments -g -fvar-tracking-assignments'
 LDFLAGS=-Wl,-O0,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 MODULES

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  paredit-mode: t
  rainbow-delimiters-mode: t
  flycheck-mode: t
  company-mode: t
  display-time-mode: t
  save-place-mode: t
  show-paren-mode: t
  savehist-mode: t
  winner-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /home/mvo/.local/share/emacs/custom.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
delete-backward-char: Text is read-only

Load-path shadows:
/home/mvo/.emacs.d/elpa/company-0.8.12/.dir-locals hides /usr/share/emacs/25.0.50/lisp/gnus/.dir-locals
/home/mvo/.emacs.d/elpa/twitch-0.7/twitch hides /home/mvo/.emacs.d/site-lisp/twitch
/home/mvo/.emacs.d/elpa/kv-0.0.19/kv hides /home/mvo/.emacs.d/site-lisp/emacs-kv/kv
/home/mvo/.emacs.d/elpa/kv-0.0.19/kv-tests hides /home/mvo/.emacs.d/site-lisp/emacs-kv/kv-tests
/home/mvo/.emacs.d/elpa/esxml-0.3.1/esxml hides /home/mvo/.emacs.d/site-lisp/esxml/esxml

Features:
(shadow sort ruler-mode gnus-util mail-extr emacsbug message idna dired
format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils term/xterm xterm
paredit easy-mmode rainbow-delimiters flycheck find-func rx subr-x seq
dash company-files company-oddmuse company-keywords company-etags etags
xref cl-seq project eieio byte-opt bytecomp byte-compile cl-extra
help-mode cconv eieio-core cl-macs company-gtags company-dabbrev-code
company-dabbrev company-capf company-cmake company-ropemacs
company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company
finder-inf info package easymenu geiser-install geiser gv time windmove
edmacro kmacro cl-loaddefs pcase cl-lib saveplace time-date paren
savehist winner ring zenburn-theme mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 161562 101461)
 (symbols 48 24795 25)
 (miscs 40 58 179)
 (strings 32 40408 74230)
 (string-bytes 1 1128413)
 (vectors 16 17014)
 (vector-slots 8 452009 54721)
 (floats 8 269 952)
 (intervals 56 451 59)
 (buffers 976 11)
 (heap 1024 33756 9289))

bug#22096: 25.0.50; reading from fifo breaks display

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 04 Dec 2015 12:40:38 -0500
> 
> I suppose this is two issues, really. I am trying to read from a FIFO,
> specifically one written to by mpd, configured in mpd.conf with
> 
> audio_output {
>   type "fifo"
>   name "FIFO"
>   path "/tmp/mpd.fifo"
>   format "44100:16:2"
> }
> 
> With mpd running I can see that the FIFO is there and I can read from it
> with other tools/mpd clients.
> 
> (info "(elisp) Reading from Files") suggests I should be able to read
> from a FIFO.

I guess you mean this part:

     It is possible to read a special file (such as a FIFO or an I/O
     device) with `insert-file-contents', as long as REPLACE and VISIT
     are `nil'.

It seems this is no longer true, and we have to fix the manual to that
effect.  I hope Paul (CC'ed) will be able to take a look.

> From emacs -Q, insert the following into the scratch buffer:
> 
> (insert-file-contents "/tmp/mpd.fifo" nil 0 10 nil)
> 
> First issue: evaluating this yields
> 
> (file-error "not a regular file" "/tmp/mpd.fifo")
> 
> Second issue: changing the VISIT argument to t and evaluating:
> 
> (insert-file-contents "/tmp/mpd.fifo" t 0 10 nil)
> 
> breaks the display engine. "nil)" becomes invisible, the last "r" in the
> scratch buffer message becomes fontified as a matching paren, and
> hitting C-a at the end of the form takes me to the aforementioned "r".
> I have attached an image.

Can you tell what were the 10 bytes inserted by the above?  Then it
should be possible to reproduce the display issue without having
access to your system.

Anyway, you are reading a binary byte stream from an audio daemon, so
I think you cannot expect it to be displayed in any human-readable
way, let alone hope that the major mode in effect in *scratch will be
able to fontify it in some reasonable way.  You should use
insert-file-contents-literally instead, I think.  (And I very much
doubt that "visiting" a non-regular file makes sense, but maybe I'm
missing something.)

Thanks.

bug#22096: 25.0.50; reading from fifo breaks display

[Eli Zaretskii]

> Date: Sat, 05 Dec 2015 10:19:32 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22096@debbugs.gnu.org
> 
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Fri, 04 Dec 2015 12:40:38 -0500
> > 
> > I suppose this is two issues, really. I am trying to read from a FIFO,
> > specifically one written to by mpd, configured in mpd.conf with
> > 
> > audio_output {
> >   type "fifo"
> >   name "FIFO"
> >   path "/tmp/mpd.fifo"
> >   format "44100:16:2"
> > }
> > 
> > With mpd running I can see that the FIFO is there and I can read from it
> > with other tools/mpd clients.
> > 
> > (info "(elisp) Reading from Files") suggests I should be able to read
> > from a FIFO.
> 
> I guess you mean this part:
> 
>      It is possible to read a special file (such as a FIFO or an I/O
>      device) with `insert-file-contents', as long as REPLACE and VISIT
>      are `nil'.
> 
> It seems this is no longer true, and we have to fix the manual to that
> effect.

Or maybe that text just gets the value of VISIT wrong: the code in
question is very old, and always signaled an error for non-regular
files when VISIT is nil.

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 05 Dec 2015 10:19:32 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 22096@debbugs.gnu.org
>> 
>> > From: Mark Oteiza <mvoteiza@udel.edu>
>> > (info "(elisp) Reading from Files") suggests I should be able to read
>> > from a FIFO.
>> 
>> I guess you mean this part:
>> 
>>      It is possible to read a special file (such as a FIFO or an I/O
>>      device) with `insert-file-contents', as long as REPLACE and VISIT
>>      are `nil'.
>> 
>> It seems this is no longer true, and we have to fix the manual to that
>> effect.
>
> Or maybe that text just gets the value of VISIT wrong: the code in
> question is very old, and always signaled an error for non-regular
> files when VISIT is nil.

Supposedly (according to the docstring) BEG and END have to be nil if
VISIT is t, so I should probably be getting an error about supplying
invalid arguments.

bug#22096: 25.0.50; reading from fifo breaks display

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sat, 05 Dec 2015 11:06:22 -0500
> 
> >>      It is possible to read a special file (such as a FIFO or an I/O
> >>      device) with `insert-file-contents', as long as REPLACE and VISIT
> >>      are `nil'.
> >> 
> >> It seems this is no longer true, and we have to fix the manual to that
> >> effect.
> >
> > Or maybe that text just gets the value of VISIT wrong: the code in
> > question is very old, and always signaled an error for non-regular
> > files when VISIT is nil.
> 
> Supposedly (according to the docstring) BEG and END have to be nil if
> VISIT is t, so I should probably be getting an error about supplying
> invalid arguments.

The code explicitly doesn't:

  if (!S_ISREG (st.st_mode))
    {
      not_regular = 1;

      if (! NILP (visit))
	goto notfound;

      if (! NILP (replace) || ! NILP (beg) || ! NILP (end))
	xsignal2 (Qfile_error,
		  build_string ("not a regular file"), orig_filename);
    }

The test for VISIT non-nil, but also BEG and END non-nil is only after
that.

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Date: Fri, 04 Dec 2015 12:40:38 -0500
>>
>> I suppose this is two issues, really. I am trying to read from a FIFO,
>> specifically one written to by mpd, configured in mpd.conf with
>>
>> audio_output {
>>   type "fifo"
>>   name "FIFO"
>>   path "/tmp/mpd.fifo"
>>   format "44100:16:2"
>> }
>>
>> With mpd running I can see that the FIFO is there and I can read from it
>> with other tools/mpd clients.
>>
>> (info "(elisp) Reading from Files") suggests I should be able to read
>> from a FIFO.
>
> I guess you mean this part:
>
>      It is possible to read a special file (such as a FIFO or an I/O
>      device) with `insert-file-contents', as long as REPLACE and VISIT
>      are `nil'.
>
> It seems this is no longer true, and we have to fix the manual to that
> effect.  I hope Paul (CC'ed) will be able to take a look.

Well, darn.

>> From emacs -Q, insert the following into the scratch buffer:
>>
>> (insert-file-contents "/tmp/mpd.fifo" nil 0 10 nil)
>>
>> First issue: evaluating this yields
>>
>> (file-error "not a regular file" "/tmp/mpd.fifo")
>>
>> Second issue: changing the VISIT argument to t and evaluating:
>>
>> (insert-file-contents "/tmp/mpd.fifo" t 0 10 nil)
>>
>> breaks the display engine. "nil)" becomes invisible, the last "r" in the
>> scratch buffer message becomes fontified as a matching paren, and
>> hitting C-a at the end of the form takes me to the aforementioned "r".
>> I have attached an image.
>
> Can you tell what were the 10 bytes inserted by the above?  Then it
> should be possible to reproduce the display issue without having
> access to your system.

No. I can't tell that anything from the fifo is ever inserted. Sometimes
it seems the multibyte flag of the buffer gets flipped off. Sometimes I
actually get the "not a regular file" error. What consistently seems to
happen is "nil)" is deleted.

If I do insert-file-contents{,-literally} with just FILENAME and no
other arguments, it appears to read the fifo just fine, just that I have
to C-g to make it stop, of course. The buffer will be stuffed with
binary data, but nothing breaks as far as I can tell.

> Anyway, you are reading a binary byte stream from an audio daemon, so
> I think you cannot expect it to be displayed in any human-readable
> way, let alone hope that the major mode in effect in *scratch will be
> able to fontify it in some reasonable way.  You should use
> insert-file-contents-literally instead, I think.  (And I very much
> doubt that "visiting" a non-regular file makes sense, but maybe I'm
> missing something.)

Right, I didn't expect VISIT=t to make sense, but the resulting breakage
is unexpected.

bug#22096: 25.0.50; reading from fifo breaks display

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sat, 05 Dec 2015 10:58:38 -0500
> 
> > Anyway, you are reading a binary byte stream from an audio daemon, so
> > I think you cannot expect it to be displayed in any human-readable
> > way, let alone hope that the major mode in effect in *scratch will be
> > able to fontify it in some reasonable way.  You should use
> > insert-file-contents-literally instead, I think.  (And I very much
> > doubt that "visiting" a non-regular file makes sense, but maybe I'm
> > missing something.)
> 
> Right, I didn't expect VISIT=t to make sense, but the resulting breakage
> is unexpected.

Emacs tries to decode the binary stream (unless you use the -literally
variant), and the result could look (to Emacs) like some text that
fits some font-locking or paren-matching pattern.

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

On 05/12/15 at 06:45pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Sat, 05 Dec 2015 10:58:38 -0500
> > 
> > > Anyway, you are reading a binary byte stream from an audio daemon, so
> > > I think you cannot expect it to be displayed in any human-readable
> > > way, let alone hope that the major mode in effect in *scratch will be
> > > able to fontify it in some reasonable way.  You should use
> > > insert-file-contents-literally instead, I think.  (And I very much
> > > doubt that "visiting" a non-regular file makes sense, but maybe I'm
> > > missing something.)
> > 
> > Right, I didn't expect VISIT=t to make sense, but the resulting breakage
> > is unexpected.
> 
> Emacs tries to decode the binary stream (unless you use the -literally
> variant), and the result could look (to Emacs) like some text that
> fits some font-locking or paren-matching pattern.

The same display oddity does still happen with

(insert-file-contents-literally "/tmp/mpd.fifo" t 0 10 nil)

and nothing appears to be inserted

bug#22096: 25.0.50; reading from fifo breaks display

[Eli Zaretskii]

> Date: Sat, 5 Dec 2015 12:09:08 -0500
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: 22096@debbugs.gnu.org
> 
> On 05/12/15 at 06:45pm, Eli Zaretskii wrote:
> > > From: Mark Oteiza <mvoteiza@udel.edu>
> > > Date: Sat, 05 Dec 2015 10:58:38 -0500
> > > 
> > > > Anyway, you are reading a binary byte stream from an audio daemon, so
> > > > I think you cannot expect it to be displayed in any human-readable
> > > > way, let alone hope that the major mode in effect in *scratch will be
> > > > able to fontify it in some reasonable way.  You should use
> > > > insert-file-contents-literally instead, I think.  (And I very much
> > > > doubt that "visiting" a non-regular file makes sense, but maybe I'm
> > > > missing something.)
> > > 
> > > Right, I didn't expect VISIT=t to make sense, but the resulting breakage
> > > is unexpected.
> > 
> > Emacs tries to decode the binary stream (unless you use the -literally
> > variant), and the result could look (to Emacs) like some text that
> > fits some font-locking or paren-matching pattern.
> 
> The same display oddity does still happen with
> 
> (insert-file-contents-literally "/tmp/mpd.fifo" t 0 10 nil)
> 
> and nothing appears to be inserted

What is the value returned by the function?

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 5 Dec 2015 12:09:08 -0500
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Cc: 22096@debbugs.gnu.org
>> 
>> On 05/12/15 at 06:45pm, Eli Zaretskii wrote:
>> > > From: Mark Oteiza <mvoteiza@udel.edu>
>> > > Date: Sat, 05 Dec 2015 10:58:38 -0500
>> > > 
>> > > > Anyway, you are reading a binary byte stream from an audio daemon, so
>> > > > I think you cannot expect it to be displayed in any human-readable
>> > > > way, let alone hope that the major mode in effect in *scratch will be
>> > > > able to fontify it in some reasonable way.  You should use
>> > > > insert-file-contents-literally instead, I think.  (And I very much
>> > > > doubt that "visiting" a non-regular file makes sense, but maybe I'm
>> > > > missing something.)
>> > > 
>> > > Right, I didn't expect VISIT=t to make sense, but the resulting breakage
>> > > is unexpected.
>> > 
>> > Emacs tries to decode the binary stream (unless you use the -literally
>> > variant), and the result could look (to Emacs) like some text that
>> > fits some font-locking or paren-matching pattern.
>> 
>> The same display oddity does still happen with
>> 
>> (insert-file-contents-literally "/tmp/mpd.fifo" t 0 10 nil)
>> 
>> and nothing appears to be inserted
>
> What is the value returned by the function?

It doesn't return, just errors on "not a regular file". Sorry for not
clarifying that.

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

Mark Oteiza <mvoteiza@udel.edu> writes:

> Second issue: changing the VISIT argument to t and evaluating:
>
> (insert-file-contents "/tmp/mpd.fifo" t 0 10 nil)
>
> breaks the display engine. "nil)" becomes invisible, the last "r" in the
> scratch buffer message becomes fontified as a matching paren, and
> hitting C-a at the end of the form takes me to the aforementioned "r".

Simpler recipe:

1. mkfifo foo
2. echo "bar" > foo

In emacs -Q:

3. Evaluate (insert-file-contents-literally "foo" t)

The buffer display is now broken.

bug#22096: 25.0.50; reading from fifo breaks display

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sat, 05 Dec 2015 13:29:14 -0500
> 
> Simpler recipe:
> 
> 1. mkfifo foo
> 2. echo "bar" > foo
> 
> In emacs -Q:
> 
> 3. Evaluate (insert-file-contents-literally "foo" t)
> 
> The buffer display is now broken.

Thanks.  My Emacs is configured with --enable-checking, so it aborted
due to assertion violation.  The patch below fixes that for me; please
see if it fixes the display problem for you.

Does anyone understand how come we used just
bset_enable_multibyte_characters, bypassing all the rest that is
required to make a non-empty buffer unibyte?  It looks simply
blatantly wrong to me.  Compare, for example, with what
decide_coding_unwind does.  Did we never execute this particular code
since it was written, at least not for non-empty buffers?

I hope Handa-san (CC'ed) could comment on this.

diff --git a/src/fileio.c b/src/fileio.c
index 6cda1e3..8e44eb0 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -4265,7 +4265,7 @@ by calling `format-decode', which see.  */)
	  && NILP (replace))
	/* Visiting a file with these coding system makes the buffer
	   unibyte.  */
-	bset_enable_multibyte_characters (current_buffer, Qnil);
+	Fset_buffer_multibyte (Qnil);
     }

   coding.dst_multibyte = ! NILP (BVAR (current_buffer, enable_multibyte_charac\
ters));

bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza]

On 05/12/15 at 09:38pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Sat, 05 Dec 2015 13:29:14 -0500
> > 
> > Simpler recipe:
> > 
> > 1. mkfifo foo
> > 2. echo "bar" > foo
> > 
> > In emacs -Q:
> > 
> > 3. Evaluate (insert-file-contents-literally "foo" t)
> > 
> > The buffer display is now broken.
> 
> Thanks.  My Emacs is configured with --enable-checking, so it aborted
> due to assertion violation.  The patch below fixes that for me; please
> see if it fixes the display problem for you.
>
> diff --git a/src/fileio.c b/src/fileio.c
> index 6cda1e3..8e44eb0 100644
> --- a/src/fileio.c
> +++ b/src/fileio.c
> @@ -4265,7 +4265,7 @@ by calling `format-decode', which see.  */)
> 	  && NILP (replace))
> 	/* Visiting a file with these coding system makes the buffer
> 	   unibyte.  */
> -	bset_enable_multibyte_characters (current_buffer, Qnil);
> +	Fset_buffer_multibyte (Qnil);
>      }
> 
>    coding.dst_multibyte = ! NILP (BVAR (current_buffer, enable_multibyte_charac\
> ters));
> 

The patch does indeed fix the display problem. Thank you.

bug#22096: 25.0.50; reading from fifo breaks display

[Stefan Kangas]

Mark Oteiza <mvoteiza@udel.edu> writes:

> On 05/12/15 at 09:38pm, Eli Zaretskii wrote:
>> > From: Mark Oteiza <mvoteiza@udel.edu>
>> > Date: Sat, 05 Dec 2015 13:29:14 -0500
>> >
>> > Simpler recipe:
>> >
>> > 1. mkfifo foo
>> > 2. echo "bar" > foo
>> >
>> > In emacs -Q:
>> >
>> > 3. Evaluate (insert-file-contents-literally "foo" t)
>> >
>> > The buffer display is now broken.
>>
>> Thanks.  My Emacs is configured with --enable-checking, so it aborted
>> due to assertion violation.  The patch below fixes that for me; please
>> see if it fixes the display problem for you.
>>
>> diff --git a/src/fileio.c b/src/fileio.c
>> index 6cda1e3..8e44eb0 100644
>> --- a/src/fileio.c
>> +++ b/src/fileio.c
>> @@ -4265,7 +4265,7 @@ by calling `format-decode', which see.  */)
>> 	  && NILP (replace))
>> 	/* Visiting a file with these coding system makes the buffer
>> 	   unibyte.  */
>> -	bset_enable_multibyte_characters (current_buffer, Qnil);
>> +	Fset_buffer_multibyte (Qnil);
>>      }
>>
>>    coding.dst_multibyte = ! NILP (BVAR (current_buffer, enable_multibyte_charac\
>> ters));
>>
>
> The patch does indeed fix the display problem. Thank you.

This was fixed, but the bug was never closed.

I'm therefore closing this bug report now.