From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.devel Subject: Re: input-pending-p after make-frame-visible Date: Thu, 21 Oct 2021 07:25:44 -0400 Message-ID: References: <6c69780538e1957d1002@heytings.org> <322f50be-0de1-c818-819d-6ecb400de928@gmx.at> <03ab7a19-6616-445c-cdcf-588fb30a514a@gmx.at> <3205a073-a6ca-b9a5-3834-929025b70b7b@gmx.at> <83wnm7absp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31223"; mail-complaints-to="usenet@ciao.gmane.io" Cc: martin rudalics , Eli Zaretskii , Gregory Heytings , Alan Third , emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 21 13:26:56 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mdWDo-0007xR-HP for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Oct 2021 13:26:56 +0200 Original-Received: from localhost ([::1]:40008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mdWDm-0002nk-T8 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Oct 2021 07:26:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45686) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mdWCw-000257-V7 for emacs-devel@gnu.org; Thu, 21 Oct 2021 07:26:03 -0400 Original-Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]:42657) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mdWCu-0004Xm-6S; Thu, 21 Oct 2021 07:26:02 -0400 Original-Received: by mail-pg1-x52a.google.com with SMTP id t7so10854931pgl.9; Thu, 21 Oct 2021 04:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C9JYziFx4sWogU8ei3nr+MUWRdP2z8mIhelX90aRXKo=; b=pQkJwiKcaFMnLyUTu7+JI+HSd7juyxKKrRBI+WxUcXrL6AxOAosdh6hkbx6tXQ5oRi kOiqy+xPeUojSd1ND+V+N3A0KNtI2GC3yAAmifvToO0Kj95dvkcRWWZe2sCFIm7M3U2C uUMFk9+OKwYfXcyzKYkNDHAZp8y0yVODxjAsbM7zJ8hwVws4seVBeNlB3H9pEGqweLZ9 ww3fSO+3KcamMZxYLE0t8nGqYyriT75BPtjCV5cmdetNPQrUC9ZDrdku50gYLh6uc+T1 VgFUeOpfEe4dv7pWVLl5lSMRoZWcqgVbwMAdHd/4bRm8OEWK7aH9/vjReD50YFuYCEIT I6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C9JYziFx4sWogU8ei3nr+MUWRdP2z8mIhelX90aRXKo=; b=VqMtDwZ+3CXKD7VomFTpyqEwa2L0G9AqRWPXY/LTZLO/L3ckP25oe7YLVeGA6s7t1Q RD9iTe+i6B+N87cxFD5lNlsylZVUHQQteeuIamijtTU4yl+Rue6xs+60PXE3NUh5WV5p nhXgMCN8hrqv8Ew/DBUxzPQgqjgiW0i607tN7xV+2NfJGedEAOXZasz5bC11NpjGSItF mPjMFC6bs2UwiNiq7WYVU9YmtWzpxbyAFDHWvOaZ/C4BNAHlqE2ulE5FEo1xvZ1KHIEP SbZxdxEzLKEK+ZFT1KAvF3ZyhyUxJmFcKyckW1vZrr7vlc0g9VGeJElQZygnxUeoqaCc hP+A== X-Gm-Message-State: AOAM5303vlRtihpzs10SPjW/j8EEpAWudQB7pj1ZW9pRxtAMSoVTNzYV SMrmsS5m3tW74W+qW6GYZoMHf4KhWCoNTU1S/5Q= X-Google-Smtp-Source: ABdhPJxzRAFTJnYevOrg54Lj12FbyaA7H59TdmSWvodIQyUtHaQknMYiukicdcjDY1jRBzWs6EjzGqKPIDs/HpoazeI= X-Received: by 2002:a05:6a00:1a4c:b0:44b:1fa6:532c with SMTP id h12-20020a056a001a4c00b0044b1fa6532cmr5302970pfv.64.1634815556511; Thu, 21 Oct 2021 04:25:56 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::52a; envelope-from=aaronjensen@gmail.com; helo=mail-pg1-x52a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:277505 Archived-At: On Thu, Oct 21, 2021 at 2:58 AM YAMAMOTO Mitsuharu wrote: > > Maybe I've injected some bug with the above change? The original > intention was to coalesce redisplays caused by successive scroll thumb > dragging events because otherwise we only see partly updated screen > when redisplay-dont-pause is nil, which used to be the default. I understand the change better now and why the `#ifdef USE_TOOLKIT_SCROLL_BARS` was added around the `flags & READABLE_EVENTS_FILTER_EVENTS` check. It was an optimization to avoid an additional check because there was a previous check already done before entering the loop. So, I don't think that a bug was introduced, it just made the code a little more difficult to decipher. I can add that check back into my patch in whatever its final form is. On Thu, Oct 21, 2021 at 2:01 AM Eli Zaretskii wrote: > Yes, and the problem is, we don't really know the answer. Someone at > some point made it ignore some events, and also made it conditional on > whether toolkit scrollbars are or aren't using. We don't understand > why, and we now want to add more ignored events to the list, which > will change the (partially unknown) behavior even more. It appears that FOCUS_IN_EVENT has been ignored since 2002: a0ba8995e3c579f4c57a674b1b44d60f6a4fb82d That introduced a bug with X focus handling, so the filtering was made to only work for input-pending-p: 20057d5215674d9c83b79fafedf37bf36b2fd0ae The 2nd bug fix thread is here, with key quotes below: https://lists.gnu.org/archive/html/emacs-devel/2002-06/msg00615.html Richard Stallman wrote: > The code in question ignored FOCUS_IN_EVENT when looking for pending > input. > > That was the intention. There was a bug report that input-pending-p > reported that there was input available, even when it was just a focus > change. I made this change to fix that. > > So when a new frame got focus, the modeline face was not > changed immediately to the "active" looking face. > > It is right to fix that bug, but simply removing the change is not > correct. That would reintroduce the other bug. And: > I think that the input-pending-p problem needs a real fix. > These events should be ignored for the sake of input-pending-p > even if they are not ignored for some other purposes. > > Perhaps there should be two different functions for asking > whether there is input, one for low-level Emacs purposes > and one for high-level purposes. Can you try fixing it that way? So, the original impetus for the filtering code was that input-pending-p was reporting t when only a filter change was made. In other words, when there wasn't actually an input pending. This is the same bug that I am reporting now, there's just a different event involved (help-echo). The flag was intended to be used by input-pending-p alone when added. > > Would adding another flag like > > READABLE_EVENTS_FILTER_WHILE_NO_INPUT_IGNORE_EVENTS make it more clear > > exactly what it is doing? > > A new flag might be a good idea, indeed, but (a) I'd need to see a > patch to have a clear idea what you mean, and (b) the application of > that flag should be dependent on that variable exposed to Lisp, so > that if problems happen, we can ask users to flip the variable and see > if the problems go away. I think that the variable would just change how READABLE_EVENTS_FILTER_EVENTS worked, so I would not add a new flag unless you feel that ultimately renaming it would be beneficial. If the new variable was set to t, it would filter all events in while-no-input-ignore-events, nil would use the current focus-in-only filtering. Perhaps the flag should be input-pending-p-ignores-while-no-input-ignore-events? It's a mouthful, but it's temporary hopefully. Any other better names? > > It seems unlikely that a person would start using a flag that has a > > single use without understanding what that flag does > > In general, yes. But isn't that precisely what you suggest we do > here? ;-) Hah, to be fair I understand exactly what the flag does :). I just didn't until now understand why it came to be. Hopefully the above context is helpful and makes everyone more comfortable with my proposed changes (extra variable or no). Please let me know how you would like me to proceed -- I'm happy to add the extra variable and vary the behavior based on it for now. Thanks, Aaron