Inspired by #786: `:filter-return' expects a function to be given. If neither
"zstd" or "gzip" are found on the executable path, then it gets given nil
instead, which results in sadness when trying to save files.
With (helm +childframe) in doom! section, without this patch
execute-persistent-action opens an extra non-child frame. This
doesn't play nicely with my tiling window manager.
This patch is taken from helm-posframe, and seems to fix it.
It's been a change a long time coming. Ivy's snappiness and simple API
was Ivy's selling point (as far as Doom is concerned). It helps that
much of helm's vast featureset has been ported over and its API is so
much simpler to grok, but its greatest weakness lies in its choice of
display mechanism: the minibuffer.
Ivy's performance suffers dramatically with large datasets because
mutating results in the minibuffer blocks the minibuffer, which also
happens to be where we type in our queries. This can make input feel
dreadfully sluggish in the best cases, locking up Emacs entirely in the
worst.
Helm updates a buffer asynchronously, so it suffers none of this (though
the overhead of maintaining this buffer is certainly overkill for tiny
datasets).
And Ivy's simple API, while easier to understand, is significantly less
powerful. That it takes so much effort to grok Helm is a huge turn
off (and of course, no fault of the dev). Still, there simply is no
excuse for power users like myself to not do so anyway. The more I learn
about it, the more I wonder why I stuck to ivy for so long (but also
reminds me exactly why I did)!
This addresses two edge cases:
1. if web-mode-auto-close-style == 3, <'s behavior may insert an extra
>
2. Some web-mode engines have pairs that end with smartparens pairs,
which will result in web-mode inserting its closing pairs _and_
smartparens inserting its closing pairs; resulting in extra
characters.
Reported by @ar1a
counsel-projectile-find-file has other capabilities (like actions and
sorting). So we conditionally use projectile-find-file only if the
project is large enough to warrant it.
Persistent undo history is great. I'm hoping that, with
undo-tree-enable-undo-in-region disabled, we can enable this feature
again safely.
Time will tell.
