GNU bug report logs -
#73568
30.0.91; which-key error in speedbar (wrong-type-argument wholenump -13)
Previous Next
Full log
Message #11 received at 73568 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com> wrote:
>
> 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.
[0001-Fix-which-key-layout-error-when-available-width-is-s.patch (application/octet-stream, attachment)]
This bug report was last modified 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.