Re: [PATCH] implement a capf for address completion
On 2024-03-19 16:12:04, Antoine Beaupré wrote: [...] > The closest we have in the archive is (author in CC): > > <71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org> > > ... which writes a new `kea/notmuch-address-message-capf' function from > scratch. It might, however, do a better job than i do at taking into > account the "harvest" process, which I only discovered after writing the > patch and decided I would pretend it doesn't exist (and is probably > inaccurate). So that might be a flaw with my patch already, but in my > defense, WTF is that harvest thing!? :) Thinking about this more, I *think* the capf *can* return a *function* instead of a list of strings, so we might be able to refactor this a bit better and send a function that waits for the harvesting to complete, or stream the results or something. Above my pay grade, at this point. -- We have no friends but the mountains. - Kurdish saying ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] implement a capf for address completion
I have *just* realized, after writing all this code and sending the patch, that someone else might have discussed this here. Oops. So, turns out, it *has* been discussed, but it doesn't look like anyone tackled that problem fully just yet. The closest we have in the archive is (author in CC): <71a3382b-3f1b-4b81-883c-b4a8bd710888%40picnicpark.org> ... which writes a new `kea/notmuch-address-message-capf' function from scratch. It might, however, do a better job than i do at taking into account the "harvest" process, which I only discovered after writing the patch and decided I would pretend it doesn't exist (and is probably inaccurate). So that might be a flaw with my patch already, but in my defense, WTF is that harvest thing!? :) Another discussion about capf was about integration with EUDC: <8a437e3f646f7972c86c4aae57ae7452%40condition-alpha.com> But I don't quite understand what EUDC is or why it matters here. Might be *some* overlap, not sure. Finally, there's this whole other thread from 2022 about capf, but it's quite diffuse and I couldn't make heads or tails of it. The head of the thread according to the online archives is: ... but that's a reply to... something else, so I'm not sure. As usual, your mileage may vary. :) To test my patch, you apply it, restart Emacs (or rewire `message-completion-alist' like Keith Amidon did), fire off a new email, start entering an address, and hit TAB (or, if you have corfu, just wait for the timeout). a. -- We don't need any more heroes. We just need someone to take out recycling. - Banksy ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] implement a capf for address completion
I recently enabled corfu-mode everywhere, and was disappointed to find out that I lost tab-completion on my message buffers. At most, corfu would pop suggestions about existing words in the buffer, but no address completion, even when I would hit TAB. I believe this is because `message-tab' won't attempt completion if something else already did it, and also because, somehow, `notmuch-address-expand-name' ends up in `message--old-style-completion-functions'. Now, it seems to me a simple fix is to implement a proper capf (`completion-at-point-function') for notmuch. And that, in turn, is actually pretty simple compared to the code hidden underneath `notmuch-address-expand-name', which not only finds completion candidates, but also does the whole trouble of editing the buffer. So this patch turns `notmuch-address-expand-name' into a wrapper around the capf, and hooks the capf instead of the old function in the message-mode completion hooks. This ... works. Now I have popup completion, automatically (even before hitting TAB), in my message-mode buffers. It's a bit jarring because I'm so used to having completion in the minibuffer, but I think I'll get used to it. I haven't figured out how to make an escape hatch for this, to get autocompletion in the minibuffer the same wauy way we did before. Maybe we'd need something like the `notmuch-address-from-minibuffer', but interactive somehow. Not sure. But for now, this allows me to keep corfu globally active, and I suspect will make things easier and faster going forward. --- emacs/notmuch-address.el | 33 +++-- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index f756254c..0c57add8 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -171,7 +171,7 @@ matching `notmuch-address-completion-headers-regexp'." (require 'company nil t)) (notmuch-company-setup)) (cl-pushnew (cons notmuch-address-completion-headers-regexp - #'notmuch-address-expand-name) + #'notmuch-address-complete-at-point) message-completion-alist :test #'equal))) (defun notmuch-address-toggle-internal-completion () @@ -225,15 +225,10 @@ requiring external commands." (bound-and-true-p company-mode)) (company-manual-begin)) (notmuch-address-command -(let* ((end (point)) - (beg (save-excursion - (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*") - (goto-char (match-end 0)) - (point))) - (orig (buffer-substring-no-properties beg end)) - (completion-ignore-case t) - (options (with-temp-message "Looking for completion candidates..." - (notmuch-address-options orig))) +(let* ((capf (notmuch-address-complete-at-point)) + (beg (pop capf)) + (end (pop capf)) + (options (pop capf)) (num-options (length options)) (chosen (cond ((eq num-options 0) @@ -256,6 +251,24 @@ requiring external commands." (ding (t nil))) +(defun notmuch-address-complete-at-point () + "Complete the address using `notmuch-address-command'. + +This replaces the old `notmuch-address-expand-name' with the new +`completion-at-point-functions' (capf) system that's compatible +with corfu, company and friends." + (when notmuch-address-command +(let* ((end (point)) + (beg (save-excursion + (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*") + (goto-char (match-end 0)) + (point))) + (orig (buffer-substring-no-properties beg end)) + (completion-ignore-case t) + (options (with-temp-message "Looking for completion candidates..." + (notmuch-address-options orig + (list beg end options + ;;; Harvest (defun notmuch-address-harvest-addr (result) -- 2.39.2 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Forward email error - forward-sexp: Scan error
David Bremner writes: > Jon Fineman writes: > >> Received this error while trying to forward a complex html email from ebay. >> >> Unfortunately there is probably some PII embedded in it, so trying to >> remove that to include the email might confuse things. >> >> Any suggestions on how to find the error? >> >> >> Sending... >> forward-sexp: Scan error: "Unbalanced parentheses", 22384, 32216 >> >> > > Does "M-x toggle-debug-on-error" yield a useful backtrace? Debugger entered--Lisp error: (scan-error "Unbalanced parentheses" 22384 32216) scan-sexps(22384 1) forward-sexp() mml-expand-html-into-multipart-related((part (type . "text/html") (charset . "UTF-8") (nofile . "yes") (tag-location . 907) (contents . "\n
Re: Forward email error - forward-sexp: Scan error
Jon Fineman writes: > Received this error while trying to forward a complex html email from ebay. > > Unfortunately there is probably some PII embedded in it, so trying to > remove that to include the email might confuse things. > > Any suggestions on how to find the error? > > > Sending... > forward-sexp: Scan error: "Unbalanced parentheses", 22384, 32216 > > Does "M-x toggle-debug-on-error" yield a useful backtrace? ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
