On Sep 10, 2005, at 9:47 AM, Helmut Eller wrote:
I don't quite understand why a menu has to evaluate arbitrary ELisp code. Shouldn't Emacs just tell Lisp which menu item was selected? Or is needed for the kind of stuff people do with javascript in web-browsers?
Where the menu is to take an action in emacs you need to tell emacs somehow what to do. It seemed easier to simply do that in one place rather than having to create both the menu action in lisp and a separate function in emacs. However, it would be equivalent to simply send the menu choice back to lisp and have lisp call swank:eval-in-emacs when appropriate.
I suppose this is a matter of nostalgia as well - I am used to the situation where the debugging/editing environment and the runtime are running together. Having the emacs code sitting in the same place made it feel less like I always had to worry about the mechanics of the connection.
BTW, are presentations of any use to people who don't use a mouse with Emacs?
You can copy them and reuse them as input. I can look in to providing a mechanism for accessing the menu choices via the keyboard.
The "security" switch sounds a bit academic/useless to me, but I don't mind if you add one.
I'm trying to understand where this would be a legitimate concern. The only situation I can imagine, given that you are in the repl already (and hence have full access to the lisp and emacs) is that you want to use slime to debug a potentially compromised lisp. In that case one could imagine whoever compromised the lisp waiting for you to connect with slime and then pounce on your emacs. Is that the situation you were thinking about Matthias?
The reason that I suggested that security be off by default is that this seemed to be a rather uncommon case and so why not put the burden on the uncommon case. However maybe there is a more common situation...
-Alan