Emacsy: Context Sensitive Commands Design Question

[Shane Celis]

Hello guilers,

I'm developing Emacsy[1], and I'm trying to design a good way of grouping and 
exposing interactive commands.  My interest is specifically related to Emacsy, 
but for guilers in general the question is, How should one provide exports of a 
different flavor?  We have only "public" exports.  In my case I want a 
"command" flavor of export.  But I might want to export "customizable" 
variables, or "minor-mode"s.  I'm not trying to tackle the general task here.

In Emacs all commands are in the same namespace.  Hit M-x TAB, and you'll 
probably see thousands of them (I've got ~6k).  A lot of the commands may only 
be appropriate in certain modes, so I'm playing around with how best we can go 
about grouping and exposing commands.  My idea is that M-x only shows commands 
that are in the current COMMAND_PATH, somewhat like a bash PATH.  To show all 
commands, one can type C-u M-x.

A command in Emacsy is a procedure that requires no arguments.  It's written 
for the user to invoke on command M-x or from a key binding.  When called 
interactively, it'll ask the user for information.  When called with all 
arguments provided, it will run non-interactively.

Suppose I have the following code which creates a command called 'echo':

(define-module (my-great-mode)
  #:use-module (ice-9 optargs)
  #:use-module (emacsy)
  #:export (some-other-proc))

(define (some-other-proc)
  "I am not a command."
  #f)

(define* (echo #:optional (text (read-from-minibuffer "Echo what: ")))
  (message text))

(export-command echo)

This module exports the procedure "some-other-proc" and I want it to _somehow_ 
export a command called "echo".  The question is how to export this other 
thing, this command?  I have a couple of ideas, most based off grouping some 
subset of procedures as commands inside a module, and using modules to group 
the commands. 

1. Create a command-interface module similar to the public-interface that 
modules have. So instead of 'resolve-interface' and 'export', I'd have 
'resolve-command-interface' and 'export-command'.  

A (resolve-command-interface '(my-great-mode)) would return a module 
(%module-command-interface) that contained bindings for all that module's 
commands.  This is the module that COMMAND_PATH would use for commands.

PRO: One could export commands and procedures entirely independently.  Also, 
one can use the module mechanisms of selecting a subset, algorithmic renaming, 
etc. on these command modules.
CON: It seems like a lot of magic, but it's using the same mechanisms that 
public interfaces use.

2. Have (export-command) just keep a list of commands, but just export a custom 
public interface.  So it might look like this internally:

(define (export-command-proc names)
  (set! %command-set (append! %command-set names)))

(define (resolve-command-interface module-name)
  (resolve-interface module-name #:select %command-set))

PRO: Less magic-y.  
CON: One must export a command to both the public interface and the command; 
maybe that's ok even preferable that they're not independent.

3. Have (export-command) create a new sub-module (my-great-mode %command).

PRO: Not too tricky.
CON: Pollutes the module namespace a little bit.

4. Still use modules, but make the user segregate their procedures and commands 
into separate modules manually. So the user would have to define modules 
(my-great-mode) and (my-great-mode commands).

PRO: No magic. Programmer does everything.
CON: Everything is managed by convention. Separating the commands and 
procedures might be an awkward boundary.  Consider an internal procedure in 
(my-great-mode) that a command wants to use in (my-great-mode commands).  Do 
you expose it as public?  Move it around? Use @@ to get to it?  

5. Don't use modules at all.  Make the user collect and manage <command-set>s 
the same way they manage keymaps, for instance.  

PRO: Nothing tricky, doesn't use modules at all.  No magic.
CON: It has to work with the command being redefined; we can't just keep the 
command procedure; we have to keep the variable which points to modules 
possibly being a better solution.

6. Tag commands as special procedures perhaps by adding something to their 
procedure properties.  Implement a "command?" procedure.  Export commands and 
procedures to the same module. Then just pluck the commands out of all the 
procedures by using command?.

PRO: No new modules. No new exports.
CON: Adding something to the procedure makes wrapping commands in other lambdas 
awkward.  Might necessitate a define-command, lambda-command, method-command, 
which I'd prefer to avoid.

* * *

Thanks for indulging my scheme design question.  What's the right thing to do?  
What would you do? 

-Shane

[1]: https://github.com/shanecelis/emacsy