emacs-oob-reboot
emacs-oob-reboot copied to clipboard
josteink
Enhanced M-x with counsel-M-x (ivy), fallback with C-c M-x
Is counsel-M-x a function supposed to be a core function, or does it come with an external package?
I can't find it.
So do I need to (require) something first or what? Doesn't work for me.
Edit: You need to install ivy and then (require 'counsel) for this to work.
Out of the box this patch does not work.
ah, sorry, I didn't test in a fresh emacs home. The current oob-reboot test setup re-uses one's current installed packages.
Hello ! Would you try again ?
I added
(when (not (package-installed-p 'ivy))
(package-initialize)
(package-install 'ivy))
(require 'counsel)
this should get you going.
Cool ! That was quick :)
I built emacs (can't make it use a x-toolkit but no big deal for now), but finding where to require those packages and what to do with the occurences of execute-extended-command is another story.
@vindarel Oh, ugh, I didn't notice that command. Usually, I just map the M-x to the new version and that's it.
I think it's an important addition. M-x is basically unusable for people extremely new to Emacs.
Yes, suggestions will be really helpful.
On Dec 15, 2017 2:10 PM, "Sarah Sunday" [email protected] wrote:
Regardless, I think it's an important addition. M-x is basically unusable for people extremely new to Emacs.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/josteink/emacs-oob-reboot/pull/48#issuecomment-352087451, or mute the thread https://github.com/notifications/unsubscribe-auth/AMUYOwwIubA4Oph3FJfeawrnBic0T294ks5tAsQvgaJpZM4PBamm .
I suppose ivy has to be included into Emacs. It is already on Elpa (ivy on Elpa bundles ivy, swiper and counsel, they are separate on Melpa (https://github.com/abo-abo/swiper/issues/915)). I'm gonna ask.
Hello @abo-abo, have you already thought or tried to merge Ivy into Emacs ? Is it doable as of today ? (licences-wise I suppose it is, as it is on Elpa already). I suppose you are the one expected to start this process, aren't you ? do you want to ? (and any more thought to bring this issue to completion ?) Thank you !
Hello @abo-abo, have you already thought or tried to merge Ivy into Emacs ? Is it doable as of today ? (licences-wise I suppose it is, as it is on Elpa already). I suppose you are the one expected to start this process, aren't you ? do you want to ? (and any more thought to bring this issue to completion ?) Thank you !
Ivy is already part of Emacs, just like any package on GNU ELPA.
If you're asking if ivy.el will ever be moved in together with Emacs sources, it probably won't happen, for many good reasons: looser coupling, no outdated version in the core to worry about, own bug tracker etc.
There was a thread on emacs-devel 1-2 years ago about having a version of Emacs tarball that also includes some/all GNU ELPA packages. The idea was that you could easily install these packages without connecting to the Internet. This idea hasn't yet been realized. Maybe you could lend your help, if you're interested.
@abo-abo I started to hack the Emacs build so that it could use package.el as part of the main build. This would make ELPA incorporation trivial, as well as meaning that packages currently in core could be moved to package.el management. It didn't go down that well. The branch is still there though http://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/integrated-elpa.
I started to hack the Emacs build so that it could use package.el as part of the main build. This would make ELPA incorporation trivial, as well as meaning that packages currently in core could be moved to package.el management.
Thanks for the effort.
It didn't go down that well
What happened? I thought many people liked the idea, including @jwiegley.
@abo-abo Possibly partly the implementation. I had to change the build significantly (and package.el hacking would have to have happened). The simpler solution is just for the Emacs build to know where ELPA has been checked out, then copy the files across. I dislike this because then the same files are being packaged in two different ways. Also, I think, moving all emacs packages over to being packages in the package.el sense is a good thing.
https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00030.html
The simpler approach (copying stuff during build) would probably get accepted.
I think recent changes to Emacs (eglot, tree-sitter, etc) has helped make Emacs much more usable OOB. Considering repo-purpose obsolete.
Closing all issues and archiving repo. Thanks to all contributors!