Closed swflint closed 2 days ago
Thanks for the bug report! So the error looks like it has occurred when your search query has ran and when trying to calculate the total file size, encountered a file that it was unable to calculate the size of.
After digging into this, I found that this error can occur in the following sequence of events:
A superficial fix when encountering this would be to run the command p-search-hard-refresh-buffer
(G) which refreshes the candidate generator which removes the deleted file. I thinking of a better way to recover from this error or inform the user though. What I'm leaning towards is if any error occurs when calculating the size the the files, like the one above, recover from it and display a user error "Unable to process session candidates. This can occur if the document no longer exists. Run `p-search-hard-refresh-buffer' to refresh the candidate list." or something like it. I could also force remove the candidate and message something to the user. Definitely let me know your thoughts.
This touches the general problem of document's content changing after they've been added to the p-search session...
I think that seems reasonable, at least at first.
However, I have noticed this happens in a fresh, unused session, and the error remains even after performing the hard refresh (making it difficult/impossible to use at the moment.
oh, this definitely shouldn't be happening for fresh sessions as all candidate documents generated should have content
and size
. After looking into this some more, it appears commands like git ls-files
will return deleted files, thus ruining the session from the start.
I added a check for the filesystem candidate generator to make sure that the file is actually on the filesystem and not to blindly trust git ls-files
. Let me know if this fixes this problem!
That fixed it!
Is query-string interpreted as a regex or something else?
I hope you don't mind the issues -- I like the idea of this project quite a bit (it seems like a really helpful interface into Denote), and hope to make some additional contributions at some point.
Is query-string interpreted as a regex or something else?
The internal logic is kind of complicated and I'm planning on improving the UI to make it clearer what's actually being searched for. Essentially from each query term (space separated item in query-string) it performs a number of actual searches. Quoted terms are searched exactly as is. Unquoted terms are searched in a number of ways: if it is a compound word, a case insensitive search is performed for the whole term, the parts converted to snake, camel, kebab case, and each component individually each with reduced impact on the score. A non-composite term (e.g. frame
) does a case-sensitive word-boundary search and a case insensitive search.
So for example, the query string frame window buffer-list "= (+ 1 2)"
will spawn ten search processes: "\bframe\b", "frame", "\bwindow\b", "window", "buffer-list", "bufferList", "buffer_list", "buffer", "list", "= (+ 1 2)".
I'm planning on documenting this as well as making this expansion system more customizable so definitely let me know if you have any ideas about this.
And please do send any issue, question, or idea you might have, I greatly appreciate the feedback!
Backtrace below.