bug#68213: 30.0.50; completion-preview-tests failure in --without-x build

[Eli Zaretskii <eliz@gnu.org>]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: jm@pub.pink,  68213@debbugs.gnu.org
> Date: Fri, 05 Jan 2024 08:17:32 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Eshel Yaron <me@eshelyaron.com>
> >>
> >> Eli Zaretskii <eliz@gnu.org> 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.

I think the fact that we didn't hear about such problems means the
answer is NO.  This problem happens only on TTY frames.

> > 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`.

Adding Stefan to the discussion in case he has any suggestions.