New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow rendering of the files list #43
Comments
Thanks for reporting this. I can confirm a similar result when profiling, although I only have about 300 notes at the moment. I think rather than limiting the number of lines rendered (which would prevent being able to scroll down and see more), to solve the underlying issue a better approach would be a slight redesign where the widget and summary line for each file is created once and stored for re-use. I can't tackle that at the moment, but if anyone wants to take a shot at that I'll certainly accept at a PR. |
Small update: for my personal use, I ended up defining a advice function like this which limits the display to 30 files: ;; Overwrite `deft-current-files` for the `deft-buffer-setup` and limit it to 30 entries
(defun anks-deft-limiting-fn (orig-fun &rest args)
(let
((deft-current-files (-take 30 deft-current-files)))
(apply orig-fun args)))
(advice-add 'deft-buffer-setup :around #'anks-deft-limiting-fn) This gives me snappy search, and 30 results are 'good enough'. This is probably not the best solution, but works for me. Note: the |
Issue: jrblevin/deft#43 Temp fix: use a advising function to limit `deft-current-files` to 30 items, which speeds up rendering.
Update: Nvm, user error. :) @Anks I'm seeing this error with your snippet after adding to
|
@joech4n why added into a (defalias (quote ...)) block? |
I added built-in support for limiting the number of files shown via `deft-file-limit'. See the updated README and the docstring for details. |
@jrblevin Thank you! |
I have over 1000 different files in my deft directory.
Over time, deft has started to feel very slow while filtering: there is a noticeable delay with every key press while filtering files.
My first assumption was that incremental search might be slow, but a little profiling revealed that most of the time is spent in these lines of the
deft-buffer-setup
function:I'm not sure if it's something wrong with my local emacs configuration: I'm running emacs-mac with font composition enabled via
mac-auto-operator-composition-mode
. I haven't noticed a slowdown in any other modes though.For now, I have locally edited this function to show the first 10 files from
deft-current-files
. This fixes the problem for me – typing / filtering feels realtime again, without any perceived delay.I just wanted to report this. If anyone else has noticed a similar problem, I can provide a PR which will let you customise the total number of files displayed in deft.
The text was updated successfully, but these errors were encountered: