I've been playing around with keymaps. Apparently they can be used to create menus that give the user a visual list of options. The canonical way to make them is aparently with make-sparse-keymap to create the menu and define-key to add options to it, but this causes some confusing behaviour.
Take the following example:
(let ((menu (make-sparse-keymap "My menu")))
(define-key menu "a"
'(menu-item "Foo" foo))
(define-key menu "b"
'(menu-item "Bar" bar))
menu)Yields the following:
(keymap (98 menu-item "Bar" bar) (97 menu-item "Foo" foo) "My menu")Each new entry is added to the top of the list, so when the menu is displayed, they're listed in reverse order. This is very counter intuitive.
Now, I understand that the nature of lists in lisp make inserting an element at the top of the list less computationally expensive, but when you've already got to walk the whole list anyway to ensure the key binding isn't already present, this no longer feels like an adequate excuse.
Am I missing something?
like this
reshared this
Define key is my least favorite way to make a keymap.
I like defvar-keymap, bind-keys, if you've got a map create already. Like a sparce map.
General is nice too. But then you have to have that installed.
Jonathan Lamothe likes this.
@Zenie That's an option, but my concern is that the reason they might be vague in the docs is because the specific error might change in future versions.
Perhaps I'm just being overly paranoid.
Usually errors are obvious and for very specific reasons. You can just catch them and print the message so if anything does change you will know.
I don't think it's worth worrying about.
reshared this
Just spent a good half hour pulling my hair out trying to figure out why one of the #elisp functions I had just written was always returning nil when I tested it. Turns out, my test was mistakenly passing its inputs to the wrong (but similarly named) function (pivot-table-get-columns instead of pivot-table-get-body).
#Haskell's type system would've caught this. π
C's type system would also have caught it, and it isn't worth a hill of beans.
By caught it what do we mean? This is not a case of some undetected error escaping your attention due to dynamic typing. You know you got a nil which is unexpected and wrong. It's in a test case which catches it.
The only thing a type system would change is that you would instead waste a half hour not understanding how your obviously correct function call can possibly have the wrong return type.
nil is about the least useful failure state there is.
@Alessio Vanni Yeah, it's just very magic number-ey.
Ah well, such is the way it is with legacy code sometimes. No way to change it without breaking about a billion other things.
donaldh
in reply to Jonathan Lamothe • • •Ctrl, Alt, Meta, Super and Hyper are all distinct modifier keys in Emacs.
gnu.org/software/emacs/manual/β¦
gnu.org
www.gnu.orgJonathan Lamothe
in reply to donaldh • •Holger
in reply to Jonathan Lamothe • • •Jonathan Lamothe likes this.
Jonathan Lamothe
in reply to Holger • •Howitzer105mm
in reply to Jonathan Lamothe • • •The original keyboards used long ago had Ctrl, Super, Hyper, Meta, and ALT keys. We now map Meta (i.e. ESC) to the Alt key on our keyboards as a convenience. I do not believe there is a way, on modern keyboards, to have both META and ALT mapped to a key. We can have Super, and Meta. I can't recall if I was able to map Hyper on a modern keyboard.
Jonathan Lamothe likes this.
Greg A. Woods
in reply to Jonathan Lamothe • • •