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

[David Reitter]

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.

D

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