From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3832 invoked by alias); 3 Oct 2016 15:49:30 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39547 Received: (qmail 6232 invoked from network); 3 Oct 2016 15:49:30 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f194.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.194):SA:0(0.0/5.0):. Processed in 0.76784 secs); 03 Oct 2016 15:49:30 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:in-reply-to :comments:to:subject:mime-version; bh=2eHHL7CEkZb7gZleZc8MRJKig4VvMf4D9nZTu9LMk4o=; b=MsbZ8XNrPuF7V0jLIdCWyLZ2iC8MJQK2KzoJaMuMO4GXdKUOOAkAvezOx9yfS5/Uxo yi0e9787hT6Ea0XtwMZeNigBYgmNw3SmVZfd68wwHIupbP73f7/+rUA+LX0bj9S2+hG4 2bQZuH2mOMOqGftyMEZ9dyTrK/3SUjKLIDhRGgEqqUZAYKSU+qEaRhvmUuofd73zY+7o Lnt0nxjUXE83iW/caA0TOCUn5ZitFsjKjrjm0Uh77vocuJ19eCveBGxQb5aQZhbIGQW1 20God3i221VZ9dIEw0C/Qi8EstqQvCSMYLQWx43tPQ7yuQ+stvbhYZNXifmv7yEywGoz rlzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:in-reply-to:comments:to:subject:mime-version; bh=2eHHL7CEkZb7gZleZc8MRJKig4VvMf4D9nZTu9LMk4o=; b=HH2M9tVTkN3mQD3MRX4sK9hBTaujn/AvNaJyIZUjnL+jwE+8JFad0tOZBb6MUlinOP N/ge/ItxPr2yCksIlOgaclda0qPsAbmNfI73satczM18Bd4V6UsGjzq60v7v/pqz86R7 g36ocjoUlTFlTUAt/LbpBHIZAFUdvLUqTeTUAoXFd02zBG8y9DUWxD0GKYtQLrSCQ7EQ 0nBEAbR9J/pWydjvVaX9trJYu023EEjdBikRU+5S4DH269mF6vlnhKZ2POA3Irr0+0rb tDSA2puF8x+kXjd/vMG3tk0g6JHcYLMKH/XLXZzHvE0Y1YK2wO0UyX0YMupZygbo5uWq gjfg== X-Gm-Message-State: AA6/9RlQuyh+rIfvXlOTMZvdUVT788Pp6mxfCXNl+x8gQqgBPHqqin52SnUWL/eyQ5lESQ== X-Received: by 10.98.8.76 with SMTP id c73mr8473266pfd.133.1475509762745; Mon, 03 Oct 2016 08:49:22 -0700 (PDT) From: Bart Schaefer Message-Id: <161003084947.ZM7346@torch.brasslantern.com> Date: Mon, 3 Oct 2016 08:49:47 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit" (Oct 3, 12:00pm) References: <161002162145.ZM22574@torch.brasslantern.com> <20161003111840.3e5081f0@pwslap01u.europe.root.pri> In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit" (Oct 3, 1:55pm) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh hackers list Subject: Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 3, 12:00pm, Sebastian Gniazdowski wrote: } } On 3 October 2016 at 01:21, Bart Schaefer wrote: } > } > The first is that recursiveedit() calls zlecore() which calls } > getkeycmd() which cascades into raw_getbyte() with do_keytmout = 0 } > which in some circumstances means that raw_getbyte() effectively } > does a blocking read on its first call and only runs the sched } > after a key is pressed. } } It could be either way, if this is to be resolved. I mean, stopping } sched when in .recursive-edit has some, if not total sense. It's like } if user would be in an application. I think that's probably best left up to the person implementing the scheduled function. Also minimally complicated if the code below zlecore() doesn't have too many special cases for recursive-edit. On Oct 3, 1:55pm, Sebastian Gniazdowski wrote: } } raw_getbyte() can return with ZTM_NONE while there are scheduled } functions, often after Ctrl-C in .recursive-edit. } [...] } } It looks like calc_timeout handles diff < 0 and diff > 0 but not diff } == 0? Indeed, try this: diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c index 0b3b1fc..04b9357 100644 --- a/Src/Zle/zle_main.c +++ b/Src/Zle/zle_main.c @@ -471,7 +471,7 @@ calc_timeout(struct ztmout *tmoutp, long do_keytmout) tfdat = (Timedfn)getdata(tfnode); diff = tfdat->when - time(NULL); - if (diff < 0) { + if (diff <= 0) { /* Already due; call it and rescan. */ tfdat->func(); continue;