[OS X Emacs] Problem with key-description in Aquamacs 3.4

David Reitter david.reitter at gmail.com
Mon Mar 4 15:48:42 EST 2019

On Mar 4, 2019, at 3:42 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> (The documentation says "For an approximate inverse of this, see ‘kbd’.”. Your conclusion that key-description guarantees a certain format doesn’t follow, I would say, especially given that `kbd’ doesn’t nail down a representation either.)
> That's true, but I think it's forgivable that the SLIME folks didn't expect this:
> (kbd (key-description (kbd "a")))
> "A"
Well, they’re abusing the API.
> And there is no alternative function that they can use as the inverse of kbd (which is arguably a fault of Emacs itself).
So, why don’t we write an alternative function, get that added to GNU Emacs, and then SLIME can use that function when available (and fall back to key-description if not)?

> key-description is defined in C, and doesn't have any obvious conditioning context (like a dynamically-scoped variable) that would change its interpretation of lower case characters.
> This could be added, and then one would patch SLIME if they were to accept such a patch.
> Would it be possible to do something like (note -- this is in C, so of course one would have to just write the equivalent of this):
> (defun key-description (key-or-seq &optional readable) ...)
> And fall back to the original emacs code path if readable is true?
I would rather define a new function that implements what they need.

> Then we could patch with something like
> (flet ((key-description (x) (if aquamacs-p (key-description x t) (key-description x)))) 

I’d rather they check for the presence of a function, and we make that function available in Aquamacs as well as in GNU Emacs, if there is such a use case.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://email.esm.psu.edu/pipermail/macosx-emacs/attachments/20190304/6793f362/attachment.html>

More information about the MacOSX-Emacs mailing list