Re: Emacsy: Context Sensitive Commands Design Question

[Noah Lavine <noah.b.lavine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5203 bytes --]

Hello,

This is a really interesting question.

2 seems like the best combination of elegant and simple to me, but really
it's your preference. I wonder what other Guilers think.

Best,
Noah



On Thu, Aug 29, 2013 at 4:57 PM, Shane Celis <shane.celis@gmail.com> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 6021 bytes --]