deft
deft copied to clipboard
Deft hangs on emacs 28
Hi,
When opening deft
with the latest build from source, deft
hangs for a very long time. toggle-debug-on-quit
doesn't output much, only the functions used to create the *Deft*
buffer. When I quit with C-g
, I get the first entries I usually have from deft
which seems to indicate it's just really slow yet it does not bug out.
I confirm this behavior (tried with 0.8 and latest build) on:
GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10) of 2021-05-29
with no supplementary clue though.
PS. See https://www.reddit.com/r/emacs/comments/nnk2im/can_someone_help_me_debug_emacs_freezing_in_some/ and https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-05/msg02244.html
Can confirm the same issue on emacs28, native-comp on Mac. This wasn't an issue before going native-comp. Initializing deft takes a long time, I can then scroll down note entries and open them quickly, but the moment I try to enter anything to search, emacs basically freezes up. I don't even have that many entries; I just recently started using deft.
GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.6.0, NS appkit-2022.50 Version 11.5 (Build 20G5023d)) of 2021-06-01
Ed: One thing has changed since yesterday - I updated to MacOS 12 beta. Maybe rebuild emacs to see if error persists?
Ed: One thing has changed since yesterday - I updated to MacOS 12 beta. Maybe rebuild emacs to see if error persists?
This was, not surprisingly, a very bad idea. Now fighting dependency hell on a system not actually supported by homebrew.
This has been fixed at least on my build, I rebuilt emacs from source today. Can anyone else confirm? Maybe @tea4or2wo ?
On my end, it's better but not resolved. That is, Deft now loads but responding to a key press when searching takes about a second. From my - amateur! - perspective, I think the solution is to also cache the length of the summary and to use that.
FWIW this does the trick for me.
(defun deft-parse-summary (contents title)
"Parse the file CONTENTS, given the TITLE, and extract a summary.
The summary is a string extracted from the contents following the
title."
(let* ((summary (let ((case-fold-search nil))
(replace-regexp-in-string deft-strip-summary-regexp " " contents)))
(summary-processed (deft-chomp
(if (and title
(not deft-use-filename-as-title)
(string-match (regexp-quote
(if deft-org-mode-title-prefix
(concat "^#+TITLE: " title)
title))
summary))
(substring summary (match-end 0) nil)
summary))))
(substring summary-processed 0 (min 512 (string-width summary-processed)))))
Unfortunately, because I have too many documents @malb's solution still takes too long for the initialization to finish.
Here's my workaround that simply shows the filename as the summary. It's uglier compared to before, but at least now deft shows up instantly.
(defun deft-parse-summary (contents title) title)
I also saw this with native-comp on Linux, built about a month ago. Newer version built just now (124ba9db96ff7c30963a6c2d44279ed66fc3284d
) seems to work fine.
I tried it again and it's actually not really fixed, it's still slow.
archlinux nativecomp no issue
I also had slow response times after beginning a search, but had issues with @malb's code (argument out of range). After shortening the result everything works fine and fast:
... (substring summary-processed 0 (min 120 (string-width summary-processed)))))
I had the same problem. Very annoying. After a long search I then found that I had caused this by changing the deft-extensions parameter.
deft-extensions '("org" "bib" "md" "org_archive" "RData" "lyx" "mm" "mom" "ms" "sty" "tex" "txt")
The "RData" was the problem. The '.RData-files are gzip files. And it doesn't get any better in unzipped form. Very many '\0' in it.
I took out the extension and now it works fine. Maybe you have a similar problem?
I have also the same problem, Deft is slow before to show the results when I strike some keys.
GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0) of 2023-05-14 Debian trixie (testing) Deft 20210707.1633 (MELPA)
EDIT: the tricks of @malb works well for me. Thank you!