From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#32864: 26.1; menus don't work correctly in Mac OS Mojave Date: Tue, 4 Jun 2019 17:44:46 +0100 Message-ID: <20190604164446.GB23349@breton.holly.idiocy.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="236625"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.12.0 (2019-05-25) Cc: 32864@debbugs.gnu.org, Robert Pluim , omari@smileystation.com, artemiog@mac.com, simon@simonscientific.com To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 04 18:45:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hYCYl-000zNc-1p for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Jun 2019 18:45:15 +0200 Original-Received: from localhost ([127.0.0.1]:55362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYCYk-0006ZL-2b for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Jun 2019 12:45:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYCYd-0006Yo-01 for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2019 12:45:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hYCYa-00020h-U9 for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2019 12:45:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60390) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hYCYZ-0001yJ-15 for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2019 12:45:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hYCYY-0005Jq-Kd for bug-gnu-emacs@gnu.org; Tue, 04 Jun 2019 12:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jun 2019 16:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32864 X-GNU-PR-Package: emacs Original-Received: via spool by 32864-submit@debbugs.gnu.org id=B32864.155966669820423 (code B ref 32864); Tue, 04 Jun 2019 16:45:02 +0000 Original-Received: (at 32864) by debbugs.gnu.org; 4 Jun 2019 16:44:58 +0000 Original-Received: from localhost ([127.0.0.1]:45701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYCYU-0005JL-F9 for submit@debbugs.gnu.org; Tue, 04 Jun 2019 12:44:58 -0400 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:37983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYCYS-0005J3-8t for 32864@debbugs.gnu.org; Tue, 04 Jun 2019 12:44:56 -0400 Original-Received: by mail-wr1-f45.google.com with SMTP id d18so16566175wrs.5 for <32864@debbugs.gnu.org>; Tue, 04 Jun 2019 09:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=9AyaXPL6whjEVa1shO0kAkeP/O7EfOhm2+iTg7waT08=; b=RE+nZnGaAPJgjOS4qZE+JzqlqK92N764dyjfPApAISszymWQnqt9s9QtW/M6AaXp+v FGLi/Ryx177o6MrkxOWrwx8vAgn3XSCeksqN0C+IamZ5TAoLYYIYQiVKpdNAyDW99wVx foAEmkla3EqHDwW4cARWRjBNyVbrST3svY9piqia7ByU7Z0N8NFUjHblk9niVdVqtdSd F5aYy1jQ0Q7wsJLJn41xG+wja+nZtkT7PNxqTa2VKYFmROb6MBmN/Wfr/eVxG2MWtii4 CsXMNSNFzUDMNnDmYJ1U8Qp45bbIDDP/HiWsoGx7DF1ZtZ0Px85iCWtwQwSQn0XhdV18 Vhlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9AyaXPL6whjEVa1shO0kAkeP/O7EfOhm2+iTg7waT08=; b=F/MdAWqulqxbZCnsH8mkGgRfTGLNDKtvglBElDfV/RnPLHgC5rK6q1MoZDWsYnZBLs 5BsGrFbQsjxHUCuh3jgHXhgpQtm3I1u3AdqveNEU3hPtJmZTJaeP6XejXaOjwqUbaFK7 BEWrgohm+17Wrm0IEopdA42pHibWRjlJnIZb8BZW0YE1YWHzm2AqkP9ZTvhF2YOJ79QB Eucp9VlRawsmKvPosBwbe2HlBjk3byx9IbbV76P/5SzRW/6NJPHp0Dc/pxIAI/oJt/Mn xxS6Y3lAoXxkRcsGbJYoYrDS0Zk9ZBYJDodHvFxm5gj0t2ycdfDyaAjH2+26jgdcnOIE rf+Q== X-Gm-Message-State: APjAAAVAyU972DYlAp5CLIOpCWn1ZzSkUOj1y8rnL37x8g4JNKCmcvde uyM3t/EL1YoAZodW/J8/2LM= X-Google-Smtp-Source: APXvYqx53RPXSXCCqSF8GsHgbwEqiOCeo9PG1C16/iosZDowYj/ZdGYBrH5G+gM3idSBi+0/dvkD3Q== X-Received: by 2002:a5d:5702:: with SMTP id a2mr5571356wrv.89.1559666689841; Tue, 04 Jun 2019 09:44:49 -0700 (PDT) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-9466-ad51-3729-a6b8.holly.idiocy.org. [2001:8b0:3f8:8129:9466:ad51:3729:a6b8]) by smtp.gmail.com with ESMTPSA id j123sm27151847wmb.32.2019.06.04.09.44.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 09:44:48 -0700 (PDT) Content-Disposition: inline In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:160119 Archived-At: On Mon, Jun 03, 2019 at 07:25:27PM +0200, Mattias Engdegård wrote: > > So why does Emacs do this to begin with? Because the menu contents > are generated dynamically from elisp code each time. The standard > way to do this in Cocoa is to implement menuNeedsUpdate:, but this > requires running arbitrary elisp code inside the event loop, which > is undesirable for some reason. > > The workarounds mentioned involved adding Emacs to some sort of > whitelist for legacy applications, but this cannot be a solution. > The synthetic mouse click hack must go away. > > Could someone explain why, exactly, elisp code cannot be run inside > the event loop? An alternative would be to run elisp code in a > different thread, and let menuNeedsUpdate: block until the menu has > been updated. I'm not sure what the difference would be. Elisp code doesn’t guarantee it will return, it can longjmp when you hit C-g, for example. This means you can end up with the application attempting to run the event loop while it is still INSIDE the previous event loop, and the toolkit really doesn’t like that. It will, in fact, kill Emacs on the spot. It may also be the case that Emacs can try to run the event loop from within elisp code as a matter of course. Quite simply we’re, as you said, not able to handle running elisp from within the NS event loop. I’m not sure why it was written this way originally, I believe the NS port is some twenty five years old now and I’ve only been working on Emacs for three. The best solution is, as you said, to separate the lisp and toolkit calls into separate threads, but unfortunately it’s not a straight forward job. I want to do it anyway as there are other benefits, but it won’t be happening soon unless someone else wants to pick it up. The other solution I found is to rebuild the menu completely whenever lisp updates it. This is simple enough to do but rebuilding the menus takes something like 40‐70ms every time, as opposed to 1‐2ms to just rebuild the top level, and it can do it up to three times per keypress. I think it may also do it sometimes while scrolling. It didn’t seem like a good idea to me. On the other hand I don’t remember actually having much trouble with it. If anyone has any other ideas I’d be happy to hear them. -- Alan Third