bug#22096: 25.0.50; reading from fifo breaks display

[Mark Oteiza <mvoteiza@udel.edu>]

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.