comint-mode adds a misleading Signals menu

[greghendershott]

Although this may have worked back when there was only one REPL possible, and it was an "inferior process" for the one-and-only REPL buffer, it's N/A now.

Although I had rebound C-c C-c and C-c C-\ keybindings to racket-repl-break and racket-repl-exit, I neglected to think about the Signals menu.

Either the menu items that can be supported, should be remapped. Or, perhaps simply remove the entire Signals menu, and just double-check that these two commands are on the racket-repl-mode menu, so discoverable.

[maueroats]

Greg probably knows this, but if anybody else has the great idea like me that removing the signals menu is the way to go - it doesn't seem easy. I'll write what I tried. I'm not an emacs hacker, there should be a better way. (I just couldn't find it.)

In Emacs, menus are created by making keymaps. In a keymap you can bind a key to have an action, and if your keymap does not provide a binding for that action then the code looks at the keymap's parent to see if there's anything there.

That makes a lot of sense when you are talking about inheriting keybindings like "C-c C-c" from comint-mode. Getting rid of a binding that you don't want is not something that fits well into this way of doing things. If you wanted to "get rid of" that keybinding, I think you would have to alter the parent keymap.

Adding this code to racket-repl-mode would get rid of the unwanted menu, at the price of disabling the signals menu everywhere:

(define-key comint-mode-map [menu-bar signals] nil) ;;ick?

Users could also put that code in their Emacs init file, or in a racket-mode-hook function. Then racket-mode wouldn't get cursed later for breaking something.

I'm happy to submit a PR but this doesn't seem 100% ok.

[greghendershott]

I think the approach in commit c55fd70 will work? It does, for me: It remove the menu for racket-repl-mode --- and without removing it for e.g. shell-mode.

Assuming I get all green from Travis CI, I plan to merge that.