Subject: bug#73568: 30.0.91; which-key error in speedbar (wrong-type-argument wholenump -13)

From: Justin Burkett <[email-masked]>
Date: Tue, 1 Oct 2024 22:01:12 -0400

Thanks. Can you try the attached patch for the first problem?

I'm not sure what the best approach is with speedbar. I'm inclined to
disable which-key for that case, but maybe showing which-key in the
original frame is better?

On Mon, Sep 30, 2024 at 5:53 PM Stefan Kangas <[email-masked]> wrote:
>
> Morgan Willcock <[email-masked]> writes:
>
> > An error is signalled when which-key is activated, point is within the
> > speedbar frame, and a portion of a key-sequence has been typed
> > (e.g. C-x).
> >
> > To generate an example backtrace:
> >
> >   emacs -Q \
> >       --eval "(which-key-mode)" \
> >       --eval "(speedbar-get-focus)" \
> >       --eval "(toggle-debug-on-error)" \
> >       --eval "(setq unread-command-events (listify-key-sequence \"\C-x\"))"
>
> Here's the error I get:
>
> Debugger entered--Lisp error: (wrong-type-argument wholenump -14)
>   make-string(-14 32)
>
> The problem occurs is in `which-key--pad-column': the speedbar frame is
> only 14 characters wide, and so can't fit longer strings than that.
>
> I actually see two bugs here:
>
> 1. Create a regular Emacs frame of width 14, enable `which-key-mode' and
>    press some key, e.g. C-h.  You now get a similar backtrace.  Probably
>    `which-key' should simply be smarter in this case, for example by
>    truncating instead of padding.
>
> 2. With a dframe, as in speedbar, I guess `which-key' should try to
>    display it's help window in the original frame?
>
> I'm copying in Justin Burkett.