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

[Eshel Yaron]

Hi,

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.

> 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