[Top][All Lists]

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

Re: [Nano-devel] [PATCH] Window resize handling

From: Mahyar Abbaspour
Subject: Re: [Nano-devel] [PATCH] Window resize handling
Date: Tue, 5 May 2015 13:32:29 +0430

On Tue, May 5, 2015 at 12:34 PM, Benno Schulenberg <address@hidden> wrote:

On Tue, May 5, 2015, at 08:53, Mahyar Abbaspour wrote:
> On Tue, May 5, 2015 at 12:37 AM, Benno Schulenberg <address@hidden>
> wrote:
> > I have removed the section of code, and cannot notice any adverse
> > effects.  And how could there be?  Whenever we are resizing the window,
> > we are already in blocking mode: [...]
> It's not true. You can test it by putting a fprintf(stderr, "foo"); in the
> sigpending() if. It sometimes gets executed especially in heavy loops like
> the file browser provided that you are dragging the mouse to the left and
> right very fast.

Sure it will get executed sometimes.  But if that section isn't there,
the very same SIGWINCH will be handled by the second section instead.
It will not be missed.

Ok, no objection :)
> However as I said, in the normal use, we are almost always
> in the blocking mode.

With "blocking mode" we mean blocking-on-input, waiting for a
keystroke, right?  Not signal-blocking-mode.

Yes, blocking-on-input I meant.
What I don't get is: when wgetch() is patiently waiting for input,
waiting and waiting, and we don't type anything, how then can the
screen ever be regenerated?  Apparently wgetch() returns with an
ERR as soon as a SIGWINCH occurs (or any other signal, probably)?

Exactly. wgetch() returns ERR as soon as a SIGWINCH occurs. Then we
return a KEY_WINCH to the caller to inform it about the changes in the
window dimensions. The caller then redraws the necessary elements
on the screen.
Anyway, when we are now handling a SIGWINCH in a single place,
there is no longer any need to be blocking SIGWINCH.  Let it occur
whenever it likes (well, not during spell checking and linting and
such stuff; but during normal nano operations, fine).  As many
SIGWINCHes can occur as they like, they will only get noticed
and handled when nano is again looking for input.  So I think
any allow_pending_sigwinch() can be removed from src/winio.c.

Good idea! I did a quick test and I didn't see any problem :)
Ah, there is one situation where nano will fail to handle SIGWINCHes:
when it is searching through a giant file (that is: when nodelay_mode
is TRUE).  But leave that case for now; we will correct it later.




reply via email to

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