From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#46990: 28.0.50; popup menu not navigable via arrow keys on lucid build Date: Mon, 20 Jun 2022 12:40:16 +0200 Message-ID: <87r13j39f3.fsf@gnus.org> References: <87pn0alx4d.fsf@yandex.com> <87ft15dici.fsf@tcd.ie> <87wnuhlnwd.fsf@yandex.com> <83im5yonpn.fsf@gnu.org> <87zgzassr8.fsf@yandex.com> <83czw6ojyd.fsf@gnu.org> <9914d67ab1e37ee22af8@heytings.org> <87k0qdsvbs.fsf@yandex.com> <87o7ynpwn7.fsf@gnus.org> <87bkunpss9.fsf@yahoo.com> <875ykv4q53.fsf@gnus.org> <87wndbodkd.fsf@yahoo.com> <871qvj4pgc.fsf@gnus.org> <87ilovocz8.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7481"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Colin Baxter , Gregory Heytings , 46990@debbugs.gnu.org, Eli Zaretskii To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 20 12:41:09 2022 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 1o3EqD-0001jT-Ha for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Jun 2022 12:41:09 +0200 Original-Received: from localhost ([::1]:57098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3EqC-0001OR-7w for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Jun 2022 06:41:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3Eq6-0001Ng-FE for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2022 06:41:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60593) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o3Eq6-00034S-6T for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2022 06:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o3Eq6-0004QA-2J for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2022 06:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2022 10:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 46990-submit@debbugs.gnu.org id=B46990.165572162816947 (code B ref 46990); Mon, 20 Jun 2022 10:41:02 +0000 Original-Received: (at 46990) by debbugs.gnu.org; 20 Jun 2022 10:40:28 +0000 Original-Received: from localhost ([127.0.0.1]:54490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o3EpX-0004PH-Ot for submit@debbugs.gnu.org; Mon, 20 Jun 2022 06:40:27 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:33036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o3EpW-0004Os-EK for 46990@debbugs.gnu.org; Mon, 20 Jun 2022 06:40:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=n+VaFn1TI99N9NRmWtw17I3hymxif4yYa9GY7oyu2HE=; b=tJbsGtMa9B/ZMQFKa0eouuM2oD yfS/CnirYxdE4j9zWCE/WkLMA6CtE3jmeg3d1dkzeg/tjHFQgSrmmVIimOVDMSnlgeXRV3J+UHdUL kVVN78LKCYv60z4Wg9gYmApprivi2ZHery0aw6UaeAPkvkxjB6g7lQVRd7colwVBEEBU=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o3EpM-0000Xu-Pu; Mon, 20 Jun 2022 12:40:19 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEWZmFdZNRefJBvT FQ3///9v0t8eAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YGFAoGM7jvJBEAAAGbSURBVDjLZZSJkcMw CEXBaQBwAwY1kJX67205JF9xMuOYZwJ8QACAXJeYzV9MENcytzFOFPZysFGX6Qke9jH6Ivi0L0Lp IO0GRsVJ8LCPoQvI0z76AuVgTxe4OZjcXOBKqV/BNMHtSe6gHvoYvKsLk8H6CUx3YyvNvKoEfmv5 N1mwhwwvLWApg5SwGkELKKemu07NWwQBdywgstokrSVglfgf8cxpNocD9MqG2DuQXRAtMHiqCUCr PToUdk9KWAniU8A2awotgR3RYzc7sAXUzFG8DYRUYzQCeDTXIdqMEPVJMy/Bg/sLrfdMDWH78/pC kwTti8YkUcbWLdsQwC9wtZA8BgP1O/jI180crJUHF2iu5pEu2GabITtrfGSqKC/w5c1jox3+UElN sFlnIvGk/WtbAQ/ieqjX5zdBV+BzDgOGdoghCiLSHIao1Ewp2y0ulLU5cDmJPYfjtiLw3o61IfC7 HnPa8del10K/VnAuYXX5dwdp7rO1lwPNE0Deew7nmbF8TK+zpIbMSw4FrqPkOk7Y1rgDvMj9UPoH E0GBZX9haN4AAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDYtMjBUMTA6MDY6NTErMDA6MDAVqqBH AAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTA2LTIwVDEwOjA2OjUxKzAwOjAwZPcY+wAAAABJRU5E rkJggg== X-Now-Playing: Felix Da Housecat's _Kittenz and The Glitz_: "Happy Hour" In-Reply-To: <87ilovocz8.fsf@yahoo.com> (Po Lu's message of "Mon, 20 Jun 2022 18:17:47 +0800") 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" Xref: news.gmane.io gmane.emacs.bugs:234866 Archived-At: Po Lu writes: > Lars Ingebrigtsen writes: > >> I guess that makes sense on some level -- -Q doesn't control what Gtk >> does with the toolbar, for instance. It's still somewhat odd-looking >> for Lucid -- is there any way we can stop it from consulting the X >> resources, or is that completely out of our hands? > > It can, but I'd rather not go down the rabbit hole of modifying the > behavior of xrdb.c based on the value of `inhibit-x-resources'. xrdb.c already uses that: const char * x_get_string_resource (void *v_rdb, const char *name, const char *class) { [...] if (inhibit_x_resources) /* --quick was passed, so this is a no-op. */ return NULL; But I guess the Lucid calls are via a different path? (I'm having issues with trying to follow the call sequence here...) I'm not sure whether the Lucid stuff goes through xrdb.c at all? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no