GNU bug report logs - #73568
30.0.91; which-key error in speedbar (wrong-type-argument wholenump -13)

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Morgan Willcock <morgan <at> ice9.digital>, 73568 <at> debbugs.gnu.org
Cc: Justin Burkett <justin <at> burkett.cc>
Subject: bug#73568: 30.0.91; which-key error in speedbar (wrong-type-argument wholenump -13)
Date: Mon, 30 Sep 2024 14:53:43 -0700

Morgan Willcock <morgan <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.