The same as 7d617f15, but for ivy:
+ Heavily refactored +ivy-file-search
+ Removed -z flag from all engines by default
+ Changed the behavior of the universal argument for from-cwd
interactive commands (e.g. +ivy/rg-from-cwd). It used to enable
recursive searches, but now enables inclusion of hidden and compressed
files in the search instead. *-from-cwd searches are always recursive
now.
+ Now generates +ivy/X and +ivy/X-from-cwd commands dynamically.
+ Split +ivy/project-search into +ivy/project-search-from-cwd.
Universal arguments are passed from these commands to their delegated
engine command.
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.
counsel-projectile-find-file fontifies visited files and sorts the
resulting file list from projectile-find-file, adding considerable
overhead. Then, ivy-prescient performs a frecency sort and filter,
adding more overhead.
Altogether, this makes projectile-find-file unusable for larger projects
when fuzzy search is on (and in some extreme cases, when it's off). This
change disables both features specifically for projectile-find-file.
Fixes#774, hopefully
This occurs when invoking it from the root of massive file trees, like
$HOME or certain non-project folders. It's better that it defer to a
different command altogether (counsel-find-file) if invoked from $HOME,
and counsel-file-jump from anywhere else, which offers approximately
what we want, but at a fraction of the performance cost in those cases.
This allows you to control what search engines for project-search
commands (bound to SPC / p) to try, and in what order. If you didn't
want to use ripgrep, for instance, remove 'rg from these variables, or
move it to the end of the list.
Fixes wrong-number-of-args error caused by new counsel-more-chars
implementation upstream.
These hacks removed the hard-coded minimum input length requirement for
counsel-ag and its ilk. The recent counsel update made those
requirements customizable through counsel-more-chars-alist.
Phasing out the +module@name convention for plain old
+module-name-hydra, which is more compatible with elisp reflection tools
like describe-function and such.
Also, Emacs starts up faster now. Tee hee.
The display function was being set on ivy-display-functions-props. The
correct variable for it is ivy-display-functions-alist.
Reported by randoom in discord.
After some profiling, it turns out map-put and map-delete are 5-7x
slower (more on Emacs 25) than delq, setf/alist-get and add-to-list for
small lists (under 250 items), which is exactly how I've been using
them.
The only caveat is alist-get's signature is different on Emacs 25, thus
a polyfill is necessary in core-lib.
Now accepts a flat plist of all its former parameters, including new
:parameters and :actions properties to increase your control over the
fate of your windows.
The old usage of set-popup-rule! is deprecated and may not work right!
The :ui popup module has also seen a major refactor to improve
efficiency and load times.
Sorry! This is the last "big" change before 2.1!
+ :popup -> set-popup-rule!
+ :popups -> set-popup-rules!
+ :company-backend -> set-company-backend!
+ :evil-state -> set-evil-initial-state!
I am slowly phasing out the setting system (def-setting! and set!),
starting with these.
What are autodefs? These are functions that are always defined, whether
or not their respective modules are enabled. However, when their modules
are disabled, they are replaced with macros that no-op and don't
waste time evaluating their arguments.
The old set! function will still work, for a while.
This is in preparation for general.el integration coming in 2.1.1. It is
very likely that map! will change (and even more, be split into several
macros). Not much, but change none-the-less. Specifically, the state
keywords (e.g. :nvi, :n, :i) will be removed in favor of a :state
property that takes a list, e.g. (normal visual insert).
In any case, both map! and general are also relatively expensive
compared to define-key and evil-define-key* (and the new define-key!
macro), so use that when we can.
This also means changes to either API won't affect Doom's modules in the
long term.
