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

David Reitter david.reitter at gmail.com
Mon Mar 4 16:18:13 EST 2019


On Mar 4, 2019, at 4:03 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> That sounds reasonable. But wouldn't it be equally reasonable to add a readable-p optional argument to the existing function? "Readable" isn't quite the right term, but the notion is that one can round-trip through kbd, and I call it "readable" by analogy to Common Lisp's print-readably flag.

The definition of that function is "Return a pretty description of key-sequence KEYS”.

“Pretty” implies human-readable.  Pretty means: not meant for automatic parsing.

Second, if you do that, how are you going to check if you can call this function that way?  It’s not easy to check for additional parameters, and even if you do, how do you know their semantics?

You’d still want to call `aquamacs-p’?  Then you’re coding up logic or knowledge about the platform in the client program, and that’s somewhere between inelegant and tacky.

> I'm open to correction, though -- you know far more about the internals of Emacs than I do! For example, I have no idea if one can effectively use optional arguments in C functions.
> 
Yes, that bit is no problem at all.

> Any idea why this function is written in C? It doesn't seem obviously like an inner-loop function.
> 
Not sure what you mean, but that wouldn’t be the (one) defined criterion.  I haven’t looked at the function.  I think it’s used a lot where the menus are drawn, and that is certainly platform-specific, and used a lot during redisplay.  Calling Lisp functions from there can be problematic.

What is SLIME trying to achieve here?
That’s the first question we need to ask.


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


More information about the MacOSX-Emacs mailing list