GNU bug report logs - #22096
25.0.50; reading from fifo breaks display

Previous Next

Package: emacs;

Reported by: Mark Oteiza <mvoteiza <at> udel.edu>

Date: Sat, 5 Dec 2015 05:41:02 UTC

Severity: normal

Found in version 25.0.50

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 22096 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22096 <at> debbugs.gnu.org
Subject: Re: bug#22096: 25.0.50; reading from fifo breaks display
Date: Sat, 05 Dec 2015 10:19:32 +0200
> From: Mark Oteiza <mvoteiza <at> 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.




This bug report was last modified 4 years and 262 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.