From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68213: 30.0.50; completion-preview-tests failure in --without-x build Date: Fri, 05 Jan 2024 08:17:32 +0100 Message-ID: References: <87ttnvr7x7.fsf@pub.pink> <83plyjzmlv.fsf@gnu.org> <87bka3r4sg.fsf@pub.pink> <83plyixr73.fsf@gnu.org> <83le96xm2y.fsf@gnu.org> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="827"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: jm@pub.pink, 68213@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 05 08:18:21 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 1rLeTF-000Ab0-E4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jan 2024 08:18:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLeSu-0005s3-It; Fri, 05 Jan 2024 02:18:00 -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 1rLeSs-0005rB-Lc for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 02:17:58 -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 1rLeSs-0002jd-Bf for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 02:17:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLeSw-00027U-Fg for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 02:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jan 2024 07:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68213 X-GNU-PR-Package: emacs Original-Received: via spool by 68213-submit@debbugs.gnu.org id=B68213.17044390648102 (code B ref 68213); Fri, 05 Jan 2024 07:18:02 +0000 Original-Received: (at 68213) by debbugs.gnu.org; 5 Jan 2024 07:17:44 +0000 Original-Received: from localhost ([127.0.0.1]:56224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLeSd-00026b-QZ for submit@debbugs.gnu.org; Fri, 05 Jan 2024 02:17:44 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:60866 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLeSb-00026P-8y for 68213@debbugs.gnu.org; Fri, 05 Jan 2024 02:17:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1704439055; bh=h04R6f2j/IEi2pGmdbXJVrcqopw4t/2RDCHU56yFU2c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mQKDdxi/RLyRZs2YTK0lhJL6qP7kZ9jCKCXyfA05dzANNUF2NMgBfjnUoQWU1lL2+ K7X25/KT5wxSW31OBzAmm/kplpLPE9kwFk1IsEAASF2fNfwS8JcCN4Cev/X+8lg/Ow xAkVVdFPWdJROQfMQWX9yspnOv3NqlHm4r8yhp+mNEXfJQ/te0patMBqrkwi06Rbsp VQqYRQj3f4WUfkY3TFjfH6CwfYag1XuXXwzD7zky7BfuAEKIzu/cPBDaoTCVr3XtzM moq7N0MJeeU9Q9OzrwCXV05ypDlZWZx3F2C9I1BeQvzL8kqK8Pi/r4vXyuKJjgpAVt Lobmd4SFYTE2A== In-Reply-To: <83le96xm2y.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Jan 2024 21:18:13 +0200") 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:277360 Archived-At: Hi, Eli Zaretskii writes: >> From: Eshel Yaron >> >> Eli Zaretskii writes: >> >> > . does the problem happen only in a --without-x build? >> > . what "duplicate" definitions do we have there and why? >> >> The definition of `completion-preview--mouse-map` binds the events >> specified by both `mouse-wheel-up-event` and >> `mouse-wheel-up-alternate-event` to `completion-preview-prev-candidate` >> (using `defvar-keymap`). When these two variables have the same value, >> as apparently happens in John's `--without-x` build but could probably >> also occur in other setups, `defvar-keymap` complains (signals an error) >> about a duplicate definition. The duplication itself is harmless in >> this case, but there doesn't seem to be a way to tell `defvar-keymap` >> not to worry about it. > > We should try not to produce duplicate bindings here. I'm not sure how to do that without giving up on using `defvar-keymap` to define this keymap, which seems less elegant. That's why I asked for other ideas a couple of messages ago :) > Is there a real possibility that these will be the same events in GUI > builds? I don't know. It's certainly possible, but I can't tell how common it is for it to happen in practice. > If so, the definition of bindings should detect that and avoid > duplicate bindings. But if this can only happen in a --without-x > build, then a solution can be much simpler: avoid binding any mwheel > events at all. That's why I asked that first question. Either way, `defvar-keymap` doesn't let us make this kind of choices. Should we drop it and instead use good old `defvar` along with `make-sparse-keymap` and `define-key` in this case? > In any case, I don't think this issue is significant enough to justify > any infrastructure changes in defvar-keymap. IIUC, `defvar-keymap` is not flexible enough to support this use case, or any case in which the programmer cannot guarantee in advance that all keys are distinct, which they can mostly do only if all keys are static. It's fairly easy to lift this limitation and make `defvar-keymap` useful in more situations, including this one, but if you prefer to keep `defvar-keymap` intact, I can propose a patch for this specific instance that'll make use of lower level interfaces instead of `defvar-keymap`. Cheers, Eshel