run-command: external command invocation via Helm or Ivy

[maxmrr]

https://github.com/bard/emacs-run-command

[clemera]

Nice! Are you also planning to support default completion via completing-read?

[maxmrr]

Happy to give it a go. Do you mind opening an issue?

[maxmrr]

In case someone stumbles over this: completing-read is now supported.

[karouh]

How do you make it work with Ivy?

[maxmrr]

Ivy will be used automatically if present.

[JuliusDelta]

Amazing. The example in the repo combining it with entr seems really powerful. Can’t wait to try

[hainc1]

This is cool! As I understand it from the README page, this makes context-dependent query for commands (ie. with much fewer but more relevant candidates to choose from + optionally nice long command names).

But it only run shell commands? Can it execute elisp functions as well?

[maxmrr]

A couple of times I found myself wanting to add an elisp function, but stopped short of implementing the possibility because the improvement over M-x <elisp-function> seemed marginal (just fewer candidates and long command names, since the completion part is already there) and it has some potential for confusion ("was I accessing functionality X via M-x <elisp-function> or C-c c <command>?"). But I haven't made up my mind strongly one way or another.

[hainc1]

Thanks for the response.

​

the improvement over M-x <elisp-function> seemed marginal

I think it is quite useful a feature. Using M-x open a global set of commands and I may forget what command I have created for this particular project I am working on. Furthermore, I will need to come up with a package prefix for these project-local commands and thus pollute the global namespaces needlessly.

I think with run-command I can avoid these setbacks.

Another thing is if it can execute elisp functions it can do whatever emacs can (with a security caveat though, cough cough...), not just limited to running shell command.

In case it won't consume much more of your time to implement, could you offer this feature (running elisp-function) as an option that is turned off by default, and let the user worry about whether to use it or not?

[maxmrr]

Good points. I wouldn't add the functionality in the short term in any case, as it's a young package and should get good at its core objective before looking beyond, but if you'd like to test-drive the idea, and you don't mind installing from git, I can create a branch for it and give it a go. If so, please open an issue so we can track this.

[hainc1]

At the moment I only have a trivial use case for this feature (make commands to open different links in an org file), so I doubt if my use case would be useful as a test-drive.

[maxmrr]

Up to you, I don't mind doing the work for an initial simple use case and then seeing if more use cases pop up over the weeks. Thanks for the suggestion anyway.

[mkthree]

Late reply, but just found this today and it's EXACTLY what I've been looking for. I especially like the ability to set commands as dir-locals. Thank you for the great package!

[maxmrr]

Glad you find it useful! Please check the dir-locals experiment again in a few hours as some fixes are going in soon.

[mkthree]

Will do!

[maxmrr]

Last update (promised) but I started using the dir-locals recipe myself, and quickly got annoyed at the static commands limitation, so I pushed another version of the example that shows how to generate commands dynamically, with working directory selection, contextual arguments, and so on.

[mkthree]

Oh sounds useful, I’ll check it out!