[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [PATCH 3/3] files: check for an empty FIFO before block

From: Benno Schulenberg
Subject: Re: [Nano-devel] [PATCH 3/3] files: check for an empty FIFO before blocking on it
Date: Thu, 16 May 2019 15:48:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Op 16-05-19 om 03:36 schreef Brand Huntsman:
> What about this new patch? It allows nano to be started before the FIFO has
> data without hanging nano when someone accidentally opens a FIFO.

I don't like that either.  The question will annoy people who open an empty
FIFO on purpose.  What is needed is a way to abort the reading process, as
requested in  Martin van Zijl posted
a patch there that achieves that for reading a normal file, but it duplicates
the code that is used for terminating reading from standard input.  I was
looking at how to unify this, but then noticed another buglet [1] which I
cannot get to work right: always one of the cases messes up the state of
the terminal.


> Also, after reading a FIFO into a new buffer, the cursor remains at top of
> buffer. But the cursor moves to bottom of data when inserting a FIFO into an
> existing buffer. I assume it treats the FIFO as a file and opening normal
> files set cursor to top. Normal files save the cursor position when closing,
> but FIFOs don't.

This works fine for me: nano stores the cursor position also for a fifo.
But this could be considered a mistake: if the data that comes through the
the fifo is something entirely different from last time, putting the cursor
somewhere in the middle will be confusing.  But... when the user knows that
the data can differ from one run to the next, they could use +1 before the
fifo's name to force a reliable cursor position.

When inserting a file or pasting from the cutbuffer, the cursor is always
placed at the end of the "paste".  This should be so: the cursor is placed
as if the text had been typed.  Inserting from a fifo is no different.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]