From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68914: Windows makes Emacs choke on and swallow the WIN keys Date: Sun, 04 Feb 2024 16:14:57 +0200 Message-ID: <865xz42u5a.fsf@gnu.org> References: <86mssg3fm4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68914@debbugs.gnu.org To: Raffael Stocker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 04 15:16:10 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rWdI2-0003c0-D9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Feb 2024 15:16:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWdHm-0002X5-Dg; Sun, 04 Feb 2024 09:15:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWdHj-0002Un-Jk for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 09:15:52 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rWdHi-0008Vv-AH for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 09:15:50 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rWdHu-00013z-0G for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2024 09:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2024 14:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68914 X-GNU-PR-Package: emacs Original-Received: via spool by 68914-submit@debbugs.gnu.org id=B68914.17070561224036 (code B ref 68914); Sun, 04 Feb 2024 14:16:01 +0000 Original-Received: (at 68914) by debbugs.gnu.org; 4 Feb 2024 14:15:22 +0000 Original-Received: from localhost ([127.0.0.1]:48474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWdHF-000132-M5 for submit@debbugs.gnu.org; Sun, 04 Feb 2024 09:15:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rWdHA-00012k-Su for 68914@debbugs.gnu.org; Sun, 04 Feb 2024 09:15:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWdGt-0008HH-4q; Sun, 04 Feb 2024 09:14:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=rod+OXEUTV87sntcaBsbsTVyJ8WxnkigrEf2CpcW4/Q=; b=IiGgAVxSuM3wipVO6FIu aUfvUFxveIpjEiAFSn3eVmLRnk7ahWR1heIHV/61DJr+TRQB20TLQ256LV6Q0UVSdnaVejNgGUL9Y Z6RyLCQ6G/+cqVEf5v8EJiSQ9zBtBkku4Tv7/OWdQYiPCd3udOMTBOUpUG/UdZvdwJkg6rWCpCy51 Tez3pa8atPFQcJi0v7zVucE+WPC1ePFhII0PxjOIvmK1ktVkDPsN7ysOnpWgpKiW7uqhx9KYVodVk ogylaV/ZX8ZqbccTQGRmdXzdLpot5Y26IQWpJNqBUz8cMW+YukXI/r9ycExYQMx8aZ3SWS/00QKCL kEVVt0xC8T51tA==; In-Reply-To: (message from Raffael Stocker on Sun, 04 Feb 2024 14:02:02 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279414 Archived-At: > From: Raffael Stocker > Cc: 68914@debbugs.gnu.org > Date: Sun, 04 Feb 2024 14:02:02 +0100 > > > It would be better to have some independent verification that this is > > what happens. Is there any way to find out whether the hook was > > removed, even from outside of Emacs? > > MS say there is no direct way. But for debugging it might be possible > to produce some output whenever the hook is called, if that is missing, > we would know. That could be a good solution, yes. > > I find it hard to believe that > > we could miss the 200-ms deadline on modern systems. Are your systems > > heavily loaded at times? What kind of CPU do you have on those > > systems? Emacs can hog CPU with only a single thread, so if your > > systems have a reasonably modern CPU, Windows should have plenty of > > execution units to spread any additional load without preempting > > Emacs. > > It (also) happens when the systems are basically idle, with only some > keyboard input. The systems are also relatively new (Intel i7 or i5 > from a few years ago). That's even weirder. > > Another idea is to add code to Emacs that measures the time it takes > > Emacs to produce the WM_KEYUP event, and log some message if that > > takes more than some threshold. > > I have managed to set up a build environment on one of the machines and > I will try to experiment with this in the coming weeks. Perhaps I can > find out more. Thanks. > >> - If Emacs being too slow somewhere is indeed the problem, can it be > >> sped up, maybe by putting the slow stuff in a different thread than > >> the low level keyboard handling? > > > > According to the MS documentation, the hook is called by sending a > > message to the thread that installed the hook, which in our case is > > already a separate thread, not the main Lisp thread (which is likely > > to be busy at times). The thread which handles the hook callbacks is > > the input thread, which is relatively light-weight and shouldn't be > > too busy. > > We saw the correlation with working on a network share and IIUC Windows > Defender blocks a process/thread while writing (or only closing?) a > file. Therefore my suspicion. But if saving files is not done in the > same thread as input, that can't be it... Our input thread doesn't write to any files, not in our code anyway. It just runs the message pump and little else. > >> - Can we put the workaround described above (with the LowLevelHooksTimeout > >> value) into the Emacs documentation so it is findable? > > > > Please suggest the text to put in the manual to document this. > > I attached a patch that adds a paragraph to the “Windows Keyboard” section. On second thought, I think this kind of problems are better described in etc/PROBLEMS, so I have now added something there with the description of the problem and the workaround/