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 <stefankangas@gmail.com> wrote:
>
> Morgan Willcock <morgan@ice9.digital> 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.