Closed justbur closed 8 years ago
In a todo.org
file containing 3 levels of headings, e.g:
* todo.org
** Development
*** Build something
** Project management
*** Something else
SPC s j
only cycles through the 2nd level headings. With helm
, SPC s j
allows me to search through the 2nd and 3rd level headings which is much more useful.
@kostajh Try changing org-imenu-depth
indeed! thanks @justbur. Should this be a default in the org layer?
Would be handy to be able to keep the org header faces with SPC s j
like with helm, I find it more readable.
@kostajh sorry, what default are you suggesting?
@justbur (setq org-imenu-depth 3)
in the org
layer.
@kostajh #4542 I chose 8 to make it consistent with what helm-org
does.
One gripe I have when enabling ivy is that whenever helm is used for completion the vim-keybindings haven't been set leading to a less than ideal user experience. What would be the best way to handle this transitory period, when ivy support is still being worked on?
For now I enable both spacemacs-helm
and spacemacs-ivy
layers for convenience and utiltity. It seems that ivy is enabled last, which changes most of the commands to use ivy and helm is used in cases where there is no ivy equivalent like helm-descbinds
or in cases when spacemacs-helm
has shadowed a prefix, like SPC h SPC
.
It seems that ivy is enabled last
AFAIK, this depends on the order you list them.
The layers are processed in the order of the list but packages are loaded alphabetically so helm comes before ivy. Ivy or helm packages can be forced to load in a pre step with :step pre
. To do so one can use dotspacemacs-additional-packages
to add the :step
keyword to them, the dotfile won't steal ownership (it takes the ownership only if nobody has claimed it).
I think it would be convenient to setup the vim-keybindings to helm even if ivy is loaded by calling spacemacs//hjkl-completion-navigation
defined in https://github.com/syl20bnr/spacemacs/blob/develop/layers/+completion/spacemacs-helm/packages.el#L367-L390. The function would have to be moved out from spacemacs-helm/init-helm
. Is there any simple way to tap into other layer's functions without loading the whole layer? It seems that loading the spacemacs-helm
layer overrides quite much of ivy functionality, so only changing the bindings should be sufficient.
Maybe I'm approaching this from the wrong way. Should we instead strive to a state where helm will never be used when ivy is enabled?
When using spacemacs-ivy
, and enabling the search-engines
layer, trying to use it yields the following error:
spacemacs/search-engine-select: Symbol's function definition is void: helm
@algernon Thanks. I'll add that to the list
I think the code in each layer like
(when (configuration-layer/layer-usedp 'spacemacs-helm) (defun python/init-helm-pydoc ()....)
may can be changed to
(when (configuration-layer/package-usedp 'helm) (defun python/init-helm-pydoc ()....)
so if someone use spacemacs-ivy and install helm by himself can also use the packages related to helm just like helm-pydoc. @justbur
@scloudyy @syl20bnr said he didn't want to do this, but it's his call.
@scloudyy what about enabling both layers then ? Using package-usedp
is the same as no condition at all, helm
is always installed due to the package dependencies.
The package will be added to "configuration-layer--packages" because of the dependencies? I remember it only add the packages that appear in the used layers or "dotspacemacs-additional-packages"
Oh yeah you are right so changing the condition to package-usedp
won't change anything. ;-)
so if someone use spacemacs-ivy and install helm by himself can also use the packages related to helm just like helm-pydoc.
It will work when adding helm in additional-packages indeed, interesting proposition.
I guess we can change them for package-usedp
then.
Adding helm to additional-packages won't use any of the spacemacs helm configuration. It might get confusing
Nice work @justbur. While testing I played around with a few of the options including fuzzy (via flx) (setq ivy-re-builders-plist '((t .ivy--regex-fuzzy)))
and (setq ivy-initial-inputs-alist nil)
which both have their merits and are illustrated here http://oremacs.com/2016/01/06/ivy-flx/.
Not sure what the preferred approach with spacemacs is re defaults and options, but if nothing else these would be useful to highlight in the layer doc. Noting here for reference.
@ghoot I'm not sure I like the fuzzy matching (for a default at least), but I was already removing the initial "^" as I found that annoying.
@justbur yeah. Highlighting it as an option in the docs is prob enough. It's def a taste thing. Not even sure what I prefer myself ...
@justbur Is there any variable set for ivy to fix the size of the ivy frame just like the " dotspacemacs-helm-resize"? Sometimes the frame is high and sometimes it is low, which makes people feel uncomfortable.
@scloudyy As far as I know, no, but try this and if does what you want I'll try to get a variable added to ivy.
(defun set-ivy-window-min-height ()
(set-window-text-height (selected-window) ivy-height))
(advice-add 'ivy--minibuffer-setup :before #'set-ivy-window-min-height)
To add to the list: Ag/Pt results have no occurence highlighting. Not sure if it's high priority but it feels weird.
What do you mean by that @syl20bnr
@justbur
I suggest the following setting in spacemacs-theme/spacemacs-common.el:
`(ivy-current-match ((,class (:background ,highlight :bold t))))
The reason being that ivy-minibuffer-match-face-2
etc. use foreground highlighting in this theme, unlike the background highlighting done in the original ivy faces. Which means that if you assign :foreground
to ivy-current-match
, it will overwrite all highlighted foregrounds.
And the following setting for colir
:
(setq colir-compose-method 'colir-compose-overlay)
This setting works nicely for dark themes, while the default setting work for light themes.
Here's a screenshot:
Each background color is changed in the selection, while the foregrounds remain the same color (but bold).
Thank you @abo-abo. Looks good to me. @nashamri do you want to add this to your theme?
@justbur hey there :smile: I've tweaked the theme and this is the result so far:
and the light version:
So it's kind of looks good on both versions and as for the variable colir-compose-method
I believe the behaviour is changed in spacemacs with this commit https://github.com/syl20bnr/spacemacs/commit/9b7789124b0239485db49cfc943be50ab5e95254
Great work so far on this :). One thing I noticed switching from my config was that the smex-enabled recent commands history didn't seem to be taking effect. Any ideas why this is so?
e: and I just found the answer to my own question. M-x
should be bound to counsel-M-x
. This is also desirable because it also shows keybinding information for commands.
@sooheon I can bind M-x
. I have counsel-M-x
bound to the spacemacs version of M-x
, but I can do it for both.
Anything else you'd like to contribute or change?
May I ask how to enabled spacemacs-ivy and spacemacs-helm at the same time but use the spacemacs-ivy.To enable spacemacs-helm just don't want to lose the packsges related to helm. Is like this?
dotspacemacs-configuration-layers
`(
(spacemacs-ivy :step pre)
spacemacs-helm
... )
@scloudyy Last time I tried, enabling both (maybe with ivy after helm, I don't remember) without additional configuration was enough to have ivy taking the priority over helm.
@scloudyy Try it without the pre option. You also want to disable helm-mode, but you have to take into account that helm is deferred.
@StreakyCobra @justbur Partly, in spacemacs-ivy/packages.el, the keybinding in
(defun spacemacs-ivy/init-swiper ()...)
(defun spacemacs-ivy/init-ivy-spacemacs-help ()...)
(defun spacemacs-ivy/init-ivy ()...)
have overrided helm.Just like 'SPC p l', 'SPC f r ' and 'SPC b b'
But the keybindings in
(defun spacemacs-ivy/init-counsel ()...)
doesn't work. I think maybe it is because the keyinding in spacemacs-ivy/init-counsel are all put in the function spacemacs/describe-mode and this function is overrided by helm.
spacemacs-ivy
and
(spacemacs-ivy :step pre)
is the same.
@scloudyy #4750 should fix any trouble with using both. It's going to be hard to configure on the user side before this is merged.
Great work! Thanks!
Not sure if this is the right place for this, but the only thing I've noticed that I'm missing using ivy instead of helm is the SPC l b binding to list/search buffers limited to the current layout. It's still configured to use the (unavailable) helm-mini.
@mkomitee The layouts stuff is probably the biggest missing item at the moment. I think there's other changes with them coming, so we can maybe add the ivy support at the same time.
That's reasonable. Thanks for all of your hard work on spacemacs.
@justbur, I'm testing Ivy and it doesn't show an indicator that I'm using an Ivy session. I opened an issue suggesting that and other things but it turns out that it actually has one, but Spacemacs is now showing it - see the second point in https://github.com/abo-abo/swiper/issues/376 and abo-abo's answer. Is this intentional? I think it'd be nice to have it.
Thanks for the great work with Ivy btw.
What do you mean by an ivy session? Are you talking about ivy-mode? Or any time ivy-read is used? On Wed, Feb 3, 2016 at 5:17 PM André Peric Tavares notifications@github.com wrote:
@justbur https://github.com/justbur, I'm testing Ivy and it doesn't show an indicator that I'm using an Ivy session. I opened an issue suggesting that and other things but it turns out that it actually has one, but Spacemacs is now showing it - see the second point in abo-abo/swiper#376 https://github.com/abo-abo/swiper/issues/376 and abo-abo's answer. Is this intentional? I think it'd be nice to have it.
Thanks for the great work with Ivy btw.
— Reply to this email directly or view it on GitHub https://github.com/syl20bnr/spacemacs/issues/4540#issuecomment-179500940 .
Yes, Ivy mode. Sorry, I probably used the wrong term.
What I mean is that there's no visual indication that the Ivy buffer is an Ivy buffer - use SPC SPC
or SPC f f
to check this, for example.
Note that there's nothing showing that Ivy
is being used.
But according to @abo-abo , this doesn't happen by default - there should be an indicator, if I understood him correctly (see the link I posted). Please correct me if I'm wrong.
I think what @abo-abo was referring to is the lighter in the mode-line when ivy-mode is active, which is being hidden here. As far as I know there's no built-in way to indicate that the buffer is an ivy one. We could change the prompt perhaps, or put something in the mode-line if you like.
@justbur Ah, right, I understand what he was referring to now. It's this:
So what I had in mind it's an upstream issue then. IMO there should be a way for the user to know that he is using an Ivy buffer, like this in Helm:
@abo-abo :arrow_up:
So... well, I'd like to see this in ivy
instead of modifying Spacemacs, but if more people agree that this feature is useful, we could implement it here.
@TheBB might be able to do something in spaceline without upstream changes.
Yes, good idea :+1:
@justbur, I'm having an issue with SPC h SPC
and the Ivy layer. Some of my layers don't show up. See:
It happens every time I use SPC h SPC
.
(osx spacemacs-ivy andre-spacemacs-ivy emacs-lisp syntax-checking common-lisp git github
(shell :variables shell-default-shell 'eshell)
spacemacs-layouts erc html pdf-tools
(elfeed :variables rmh-elfeed-org-files
(list "/Users/andre0991/Dropbox/backup/emacs/elfeed-feeds.org"))
themes-megapack semantic
(auto-completion :variables auto-completion-private-snippets-directory "/Users/andre0991/Dropbox/backup/emacs/yasnippet-snippets/" auto-completion-return-key-behavior nil auto-completion-tab-key-behavior 'complete auto-completion-enable-help-tooltip t auto-completion-enable-sort-by-usage t auto-completion-enable-snippets-in-popup t :disabled-for latex)
org
(ranger :variables ranger-show-preview t)
markdown latex spell-checking version-control mu4e andre-common-lisp andre-elfeed andre-osx andre-erc andre-eww andre-mu4e)
@Andre0991 SPC h SPC
uses the same functions to gather package information in the helm and ivy versions. Can you confirm that you have the same problem with helm? This is probably a more general problem.
@justbur It works with Helm:
andre-eww
is my only personal layer that owns a package. I don't know if this is relevant.
You can now use ivy instead of helm to perform "completions" in spacemacs on the develop branch (e.g., for finding files, searching text, etc.). Note that the support for ivy is far behind helm, because many packages have been incorporated for helm that currently don't have ivy counterparts. There's also no documentation yet for spacemacs and ivy, because this is all very new.
The purpose of this issue is to provide some basic documentation, but also to solicit suggestions. If you find a ivy/counsel function that's a good replacement for something spacemacs did with helm, please suggest it here. Please do not get into arguments about which is better. That's not the point of this.
As always, PRs are welcome from anyone who can address these things. I don't have time to do this alone.
Installation
spacemacs-helm
indotspacemacs-configuration-layers
withspacemacs-ivy
Known issues
TODO
SPC ?
#4570spacemacs/search-engine-select
#4672ivy-projectile?helm-projectile
just accumulates multiple sources that are available on other bindings. Since ivy doesn't have good support for multiple sources and all of the sources are already available, I'm not going to make aivy-projectile
binding. You can still usehelm-projectile
of course.Ref https://github.com/syl20bnr/spacemacs/issues/4528
UPDATE: I'm collecting ivy PRs in my ivy branch (#4969). If someone wants to contribute to that branch you can PR against it.