Per-mode obarray for M-x

Per-mode obarray for M-x

[Scott Frazer]

How hard would it be to make a per-mode obarray for M-x?  Sort of like
the per-mode keymap and abbrev tables, I'd like to do "M-x command"
and have it act differently depending on the mode; e.g. "M-x html" in
a org-mode buffer would run org-export-as-html, but the 'default'
action in other buffers would be to run, say, htmlize-buffer.

Here's why I'd like this.  There are some commands I run somewhat
often, but they have long and/or difficult to remember names.  For
example auto-revert-tail-mode.  I am thinking as I type "Is it
auto-revert-tail-mode or auto-tail-revert-mode?"  I don't do it often
enough to take up a valuable short key binding like "C-c t", and long
key bindings can be just as difficult to remember.  Even with
minibuffer completion it interrupts my workflow, so I do "(defalias
'auto-revert-tail-mode 'tail)" and it becomes just "M-x tail".  That's
fine in this case, but you can see how I'm going to quickly run into
problems since there is only one namespace.

I understand this would be a huge undertaking if I wanted this to work
in general elisp code, which is why prefixes are used in function
names to create namespaces.  But I just want it to work with M-x.

I am willing to dig around and make a patch myself, but I'd like
someone familiar with the internals to (a) tell me if it's extremely
difficult and/or a bad idea, and if not (b) point me in the right
direction.

Regards,
Scott

Re: Per-mode obarray for M-x

[Eli Zaretskii]

> Date: Sun, 6 Mar 2011 08:04:42 -0500
> From: Scott Frazer <frazer.scott@gmail.com>
> 
> Here's why I'd like this.  There are some commands I run somewhat
> often, but they have long and/or difficult to remember names.  For
> example auto-revert-tail-mode.  I am thinking as I type "Is it
> auto-revert-tail-mode or auto-tail-revert-mode?"

Does the problem still exist in the latest Emacs versions?  E.g., in
Emacs 23.3, "M-x auto-tail TAB" completes to auto-revert-tail-mode
without anything special you'd need to do.  The secret is that
completion was lately extended, and is now much smarter.  In fact,
there are a few non-default completion styles which will be even more
aggressive than the above miracle.

IOW, maybe your problem was already solved?

Re: Per-mode obarray for M-x

[David Engster]

Scott Frazer writes:
> How hard would it be to make a per-mode obarray for M-x?  Sort of like
> the per-mode keymap and abbrev tables, I'd like to do "M-x command"
> and have it act differently depending on the mode; e.g. "M-x html" in
> a org-mode buffer would run org-export-as-html, but the 'default'
> action in other buffers would be to run, say, htmlize-buffer.

This is not exactly what you're looking for, but take a look at the
mode-local package which now ships with Emacs. It's in the lisp/cedet
directory and lets you define variables and functions dependent on the
major-mode.

In a nutshell:

(define-overloadable-function somefunc (params)
 "doc-string")

(defun somefunc-default (params)
 "doc-string"
 ... default behavior ...)

(define-mode-local-override somefunc org-mode (params)
 "doc-string"
 ... behavior for org-mode ...)


-David

Re: Per-mode obarray for M-x

[Scott Frazer]

On Sun, Mar 6, 2011 at 8:29 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 6 Mar 2011 08:04:42 -0500
>> From: Scott Frazer <frazer.scott@gmail.com>
>>
>> Here's why I'd like this.  There are some commands I run somewhat
>> often, but they have long and/or difficult to remember names.  For
>> example auto-revert-tail-mode.  I am thinking as I type "Is it
>> auto-revert-tail-mode or auto-tail-revert-mode?"
>
> Does the problem still exist in the latest Emacs versions?  E.g., in
> Emacs 23.3, "M-x auto-tail TAB" completes to auto-revert-tail-mode
> without anything special you'd need to do.  The secret is that
> completion was lately extended, and is now much smarter.  In fact,
> there are a few non-default completion styles which will be even more
> aggressive than the above miracle.
>
> IOW, maybe your problem was already solved?
>

While the new completion modes are cool and would help in that
particular instance, in my other example of "html" there would be many
hits to sort through.  Those were just some illustrative examples
anyway, I'd still like the general mechanism.

It (naively) seems not too difficult.  There would be a buffer-local
obarray variable that gets populated during major-mode setup, a macro
that wraps creating a defun with a mode-specific prefix and interns
the defun (and the shortened version?  Should the prefixed one go in
the 'main' obarray?) in the buffer-local obarray, then when you M-x it
looks in the buffer-local obarray first.  Or something like that.

Scott

Re: Per-mode obarray for M-x

[Thierry Volpiatto]

Scott Frazer <frazer.scott@gmail.com> writes:

> On Sun, Mar 6, 2011 at 8:29 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Sun, 6 Mar 2011 08:04:42 -0500
>>> From: Scott Frazer <frazer.scott@gmail.com>
>>>
>>> Here's why I'd like this.  There are some commands I run somewhat
>>> often, but they have long and/or difficult to remember names.  For
>>> example auto-revert-tail-mode.  I am thinking as I type "Is it
>>> auto-revert-tail-mode or auto-tail-revert-mode?"
>>
>> Does the problem still exist in the latest Emacs versions?  E.g., in
>> Emacs 23.3, "M-x auto-tail TAB" completes to auto-revert-tail-mode
>> without anything special you'd need to do.  The secret is that
>> completion was lately extended, and is now much smarter.  In fact,
>> there are a few non-default completion styles which will be even more
>> aggressive than the above miracle.
>>
>> IOW, maybe your problem was already solved?
>>
>
> While the new completion modes are cool and would help in that
> particular instance, in my other example of "html" there would be many
> hits to sort through.  Those were just some illustrative examples
> anyway, I'd still like the general mechanism.
>
> It (naively) seems not too difficult.  There would be a buffer-local
> obarray variable that gets populated during major-mode setup, a macro
> that wraps creating a defun with a mode-specific prefix and interns
> the defun (and the shortened version?  Should the prefixed one go in
> the 'main' obarray?) in the buffer-local obarray, then when you M-x it
> looks in the buffer-local obarray first.  Or something like that.
>
> Scott
>
>
FYI anything have a nice M-x interface with much better completion than
the vanilla M-x, a visible history, toggle help on commands, and most of
the keybindings are shown.
It have also the ability to use prefix-arg (C-u) at anytime,(i.e after
hitting M-x)

http://repo.or.cz/w/anything-config.git
 
-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Per-mode obarray for M-x

[Stefan Monnier]

> How hard would it be to make a per-mode obarray for M-x?  Sort of like
> the per-mode keymap and abbrev tables, I'd like to do "M-x command"
> and have it act differently depending on the mode; e.g. "M-x html" in
> a org-mode buffer would run org-export-as-html, but the 'default'
> action in other buffers would be to run, say, htmlize-buffer.

I don't think you really want separate obarrays for this, you can just
use lists of symbols.  But you'd want mode-local abbreviations, maybe,
or mode-local preferred commands, so TAB first tries one of those and
only if those fail does it fallback to the full set of commands.
There was also a suggestion to give easier access to commands from "the
same mode/package", so M-x context->unified RET in a diff-mode buffer
would run diff-context->unified.

That would not be too difficult to do on the M-x side: the main
2 difficulties are:
- how to populate this list/set of mode-local commands.
- add the corresponding functionality to execute-extended-command, which
  would better be done by first re-writing it in Elisp.
Rewriting execute-extended-command in Elisp would make it a lot easier
to play around with such things.
  

        Stefan

Re: Per-mode obarray for M-x

[Richard Stallman]

The idea of M-x is to run a command by name.
It is undesirable for modes to be able to interfere with that.
We have plenty of ways to invoke commands  that depend
on the major mode, so this one should remain mode-independent.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Per-mode obarray for M-x

[Stefan Monnier]

> The idea of M-x is to run a command by name.

Agreed.

> It is undesirable for modes to be able to interfere with that.

Depends what is meant by "interfere".

> We have plenty of ways to invoke commands that depend on the major
> mode, so this one should remain mode-independent.

I don't see why we shouldn't make it easier to find names that are more
likely to be used in particular major modes.


        Stefan

Re: Per-mode obarray for M-x

[Richard Stallman]

    > It is undesirable for modes to be able to interfere with that.

    Depends what is meant by "interfere".

No mode should ever do anything that would prevent M-x FOO from
running the command whose name is FOO.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Per-mode obarray for M-x

[Stefan Monnier]

>> It is undesirable for modes to be able to interfere with that.
>     Depends what is meant by "interfere".
> No mode should ever do anything that would prevent M-x FOO from
> running the command whose name is FOO.

Noone suggested otherwise.  What we're discussing here is to let the
user type M-x foo RET and have it do something useful rather than signal
that `foo' is not a command (e.g. run `bar-foo', or run `bar' if it
is listed as a mode-local alias).


        Stefan

Re: Per-mode obarray for M-x

[Scott Frazer]

On Mon, Mar 7, 2011 at 7:39 PM, Richard Stallman <rms@gnu.org> wrote:
> The idea of M-x is to run a command by name.
> It is undesirable for modes to be able to interfere with that.
> We have plenty of ways to invoke commands  that depend
> on the major mode, so this one should remain mode-independent.
>

I know of two ways to invoke commands that are mode-specific: keymaps
and menus.  Are there more?

What I want could theoretically be done with menus, but would require
a common menu with items that could be dynamically added/removed or
their function calls changed when changing major modes (or buffers).
I don't think this would be worth the effort.

Keymaps act the way I like: the same key binding in different modes
calls a mode-specific version of some function.  'C-M-a' calls
'beginning-of-defun' in emacs-lisp mode, and calls
'c-beginning-of-defun' in c-mode.  The idea is that I could do "M-x
bod" and it would call the right version.  Of course it would make no
sense for this particular case, but in general instead of making long,
hard to remember key bindings for less frequently used commands you
could use M-x with an easier to remember mnemonic.

There doesn't seem to be much enthusiasm for the idea, so instead of
something integrated I'll just make a package to scratch my own itch.
A couple good suggestions have been made that I can build off of.
Some sort of alist mapping modes to functions with a macro to
define/add things, then add a common function to be called.

Scott

Re: Per-mode obarray for M-x

[Davis Herring]

> Keymaps act the way I like: the same key binding in different modes
> calls a mode-specific version of some function.  'C-M-a' calls
> 'beginning-of-defun' in emacs-lisp mode, and calls
> 'c-beginning-of-defun' in c-mode.  The idea is that I could do "M-x
> bod" and it would call the right version.

This is very similar to what was proposed as "actions" (though those were
considered to be pseudocommands that could be bound to keys).  I can't
find exactly the right message, but this is close:

http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01382.html

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Per-mode obarray for M-x

[Richard Stallman]

    Noone suggested otherwise.  What we're discussing here is to let the
    user type M-x foo RET and have it do something useful rather than signal
    that `foo' is not a command (e.g. run `bar-foo', or run `bar' if it
    is listed as a mode-local alias).

So this would be a secondary method of lookup, used only if there is
no such symbol?  I wouldn't object to that.  (I didn't see that stated
explicitly).

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Per-mode obarray for M-x

[Richard Stallman]

      The idea is that I could do "M-x
    bod" and it would call the right version.

If you want `bod' to do something mode-specific, it is easy enough to
define a command `bod' that uses a variable to decide what to do.

					       Of course it would make no
    sense for this particular case, but in general instead of making long,
    hard to remember key bindings for less frequently used commands you
    could use M-x with an easier to remember mnemonic.

You could define them as aliases yourself, too.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: Per-mode obarray for M-x

[Scott Frazer]

On Wed, Mar 9, 2011 at 9:33 AM, Scott Frazer <frazer.scott@gmail.com> wrote:
> There doesn't seem to be much enthusiasm for the idea, so instead of
> something integrated I'll just make a package to scratch my own itch.
> A couple good suggestions have been made that I can build off of.
> Some sort of alist mapping modes to functions with a macro to
> define/add things, then add a common function to be called.

For anyone who stumbles upon this thread looking for something
similar, here's how I ended up solving it:

http://article.gmane.org/gmane.emacs.sources/3546

Scott

Re: Per-mode obarray for M-x

[Ted Zlatanov]

On Thu, 10 Mar 2011 21:18:12 -0500 Scott Frazer <frazer.scott@gmail.com> wrote: 

SF> On Wed, Mar 9, 2011 at 9:33 AM, Scott Frazer <frazer.scott@gmail.com> wrote:
>> There doesn't seem to be much enthusiasm for the idea, so instead of
>> something integrated I'll just make a package to scratch my own itch.
>> A couple good suggestions have been made that I can build off of.
>> Some sort of alist mapping modes to functions with a macro to
>> define/add things, then add a common function to be called.

SF> For anyone who stumbles upon this thread looking for something
SF> similar, here's how I ended up solving it:

SF> http://article.gmane.org/gmane.emacs.sources/3546

I think that package is a nice idea and generally very useful.  Are you
interested in putting mode-fn.el in the GNU ELPA so it can be easily
installed in Emacs?

Thanks
Ted

Re: Per-mode obarray for M-x

[Scott Frazer]

On 3/11/11 9:57 AM, Ted Zlatanov wrote:
> On Thu, 10 Mar 2011 21:18:12 -0500 Scott Frazer<frazer.scott@gmail.com>  wrote:
>
> SF>  On Wed, Mar 9, 2011 at 9:33 AM, Scott Frazer<frazer.scott@gmail.com>  wrote:
>>> There doesn't seem to be much enthusiasm for the idea, so instead of
>>> something integrated I'll just make a package to scratch my own itch.
>>> A couple good suggestions have been made that I can build off of.
>>> Some sort of alist mapping modes to functions with a macro to
>>> define/add things, then add a common function to be called.
>
> SF>  For anyone who stumbles upon this thread looking for something
> SF>  similar, here's how I ended up solving it:
>
> SF>  http://article.gmane.org/gmane.emacs.sources/3546
>
> I think that package is a nice idea and generally very useful.  Are you
> interested in putting mode-fn.el in the GNU ELPA so it can be easily
> installed in Emacs?
>

Sure, I have a bunch of (what I consider) useful packages that I was going
to submit to ELPA when it goes "live."  Has it already?  Regardless, I can
add this one to the list.

Scott

Re: Per-mode obarray for M-x

[Ted Zlatanov]

On Fri, 11 Mar 2011 13:21:07 -0500 Scott Frazer <frazer.scott@gmail.com> wrote: 

SF> On 3/11/11 9:57 AM, Ted Zlatanov wrote:
>> I think [mode-fn.el] is a nice idea and generally very useful.  Are
>> you interested in putting mode-fn.el in the GNU ELPA so it can be
>> easily installed in Emacs?

SF> Sure, I have a bunch of (what I consider) useful packages that I was going
SF> to submit to ELPA when it goes "live."  Has it already?  Regardless, I can
SF> add this one to the list.

It's live in that you can use it with 24.x builds from trunk.  Look at
the earlier thread for information about it from me and Chong:
http://thread.gmane.org/gmane.emacs.devel/136708/focus=136914

Ted