Hello all, I have an nnvirtual group that combines a number of nnml groups. I would like gnus search to work on that folder using notmuch but gnus does not seem to allow setting the search engine for a virtual group. Any suggestions? FTR, I have tried (add-to-list 'gnus-search-default-engines '(nnvirtual . notmuch)) to no avail. Thank you, eric PS - I was confused by this description of a variable: gnus-search-engine is a variable without a source file. This variable is obsolete since 25.1; use 'gnus-search-engine instead -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2
Eric S Fraga <e.fraga@ucl.ac.uk> writes: > Hello all, > > I have an nnvirtual group that combines a number of nnml groups. I > would like gnus search to work on that folder using notmuch but gnus > does not seem to allow setting the search engine for a virtual group. > Any suggestions? Interesting question! First of all I don't think it will ever work with nnvirtual, as there's no integration of search and the nnvirtual backend at all. You'll have to use the nnselect backend, which can do everything that nnvirtual can do. Steps would be: - Recreating the basic virtual setup using nnselect instead. I'm not 100% how this should look, but I know it's doable. We may have to rope Andy in for advice. There should probably be a special interactive command to make this use-case easier. - Searching the group: I _think_ this should work transparently, with no additional configuration. nnselect knows which component groups make up a virtual group, knows how to get a list of the servers that own those groups, and should be able to route the same search query to each of those servers. In theory you should be able to have a virtual group made of some groups from an IMAP server and some from a nnml server that uses notmuch, and results will be returned transparently from the two different search engines. I've never actually tried this, though (making an nnselect group from an nnselect group), so it might take a little tweaking. Basically I was waiting for someone to ask :) > PS - I was confused by this description of a variable: > > gnus-search-engine is a variable without a source file. > > This variable is obsolete since 25.1; use 'gnus-search-engine > instead Some of this very confusing stuff (the byte compiler would produce similarly nonsensical complaints) has been fixed recently. Though not completely; when I do `describe-variable' I get: gnus-search-engine’s value is ‘gnus-search-engine’ Abstract base class for Gnus search engines. This variable is obsolete since 25.1; use \='gnus-search-engine instead :(
On Feb 01 2022, Eric Abrahamsen wrote:
> gnus-search-engine’s value is ‘gnus-search-engine’
>
> Abstract base class for Gnus search engines.
>
> This variable is obsolete since 25.1;
> use \='gnus-search-engine instead
See eieio-defclass-internal in eieio-core.el:
;; turn this into a usable self-pointing symbol; FIXME: Why?
(when eieio-backward-compatibility
(set cname cname)
(make-obsolete-variable cname (format "use '%s instead" cname)
"25.1"))
This is about deprecating the use of the variable gnus-search-engine in
favor of the (quoted) symbol gnus-search-engine.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hello Eric, On Tuesday, 1 Feb 2022 at 08:35, Eric Abrahamsen wrote: > First of all I don't think it will ever work with nnvirtual, as > there's no integration of search and the nnvirtual backend at > all. I was afraid this would be the case. Thank you for confirming. > You'll have to use the nnselect backend, which can do everything that > nnvirtual can do. I did try this back when you released nnselect but couldn't achieve the same functionality. I don't completely remember the details but I think it was that when the groups (that were brought together into a single nnselect group) were refreshed, i.e. fetching new mail, the virtual group did not get refreshed. Does this make sense? In any case, not being able to search the virtual group is not a deal breaker: I've put all the constituent groups into their own topic and I can simply search the topic! thank you, eric -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Feb 01 2022, Eric Abrahamsen wrote:
>
>> gnus-search-engine’s value is ‘gnus-search-engine’
>>
>> Abstract base class for Gnus search engines.
>>
>> This variable is obsolete since 25.1;
>> use \='gnus-search-engine instead
>
> See eieio-defclass-internal in eieio-core.el:
>
> ;; turn this into a usable self-pointing symbol; FIXME: Why?
> (when eieio-backward-compatibility
> (set cname cname)
> (make-obsolete-variable cname (format "use '%s instead" cname)
> "25.1"))
>
> This is about deprecating the use of the variable gnus-search-engine in
> favor of the (quoted) symbol gnus-search-engine.
Yar, I know what the issue is, it just shouldn't be doing that in
`describe-variable'. Even if we are, in a very technical sense, treating
the class name as a variable here.
Eric S Fraga <e.fraga@ucl.ac.uk> writes: > Hello Eric, > > On Tuesday, 1 Feb 2022 at 08:35, Eric Abrahamsen wrote: >> First of all I don't think it will ever work with nnvirtual, as >> there's no integration of search and the nnvirtual backend at >> all. > > I was afraid this would be the case. Thank you for confirming. > >> You'll have to use the nnselect backend, which can do everything that >> nnvirtual can do. > > I did try this back when you released nnselect (FTR that was Andy Cohen's work, not mine) > but couldn't achieve the same functionality. I don't completely > remember the details but I think it was that when the groups (that > were brought together into a single nnselect group) were refreshed, > i.e. fetching new mail, the virtual group did not get refreshed. Does > this make sense? That does make sense, and it's something to think about and possibly address. So you had to M-g on the nnselect group in particular to get it to refresh? I don't think nnvirtual is going anywhere, possibly ever, so if you've got a setup that works you should stick with it. But I'd like to get the nnselect stuff as usable as possible, because in the end it's a more versatile tool. > In any case, not being able to search the virtual group is not a deal > breaker: I've put all the constituent groups into their own topic and I > can simply search the topic! That's a good solution, I actually had forgotten you could do that.
On Tuesday, 1 Feb 2022 at 09:29, Eric Abrahamsen wrote: > (FTR that was Andy Cohen's work, not mine) Ah, yes, sorry Andy! > That does make sense, and it's something to think about and possibly > address. So you had to M-g on the nnselect group in particular to get it > to refresh? I've been re-reading the documentation and it does state you can set it for automatic rescan. The problem now is figuring out how to create the group I want. nnvirtual is very good for this as it's straightforward. nnselect is somewhat opaque. How do I create a group that combines all those nnml groups with the following pattern, for instance: nnml\\+somename:mail\\.* ? > I don't think nnvirtual is going anywhere, possibly ever, so if you've > got a setup that works you should stick with it. Indeed. Always a good approach: if it ain't broke, ... -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 1 Feb 2022 at 09:29, Eric Abrahamsen wrote:
>> (FTR that was Andy Cohen's work, not mine)
>
> Ah, yes, sorry Andy!
>
>> That does make sense, and it's something to think about and possibly
>> address. So you had to M-g on the nnselect group in particular to get it
>> to refresh?
>
> I've been re-reading the documentation and it does state you can set it
> for automatic rescan. The problem now is figuring out how to create the
> group I want. nnvirtual is very good for this as it's straightforward.
> nnselect is somewhat opaque.
>
> How do I create a group that combines all those nnml groups with the
> following pattern, for instance:
>
> nnml\\+somename:mail\\.*
>
> ?
Right, that's what I was saying in my original message: I'm pretty sure
this is possible, but I don't know the correct syntax. Once that's
sorted out, then we could add a convenience function that makes
"virtual" style select groups easier to create.
I just fooled around with this and couldn't get it to work, so I'm
cc'ing Andy to see what he thinks.
Andy, do you have a recommendation for how to make an nnselect group
that works just the same as an nnvirtual group: i.e. simply collects
several other groups and dumps them into one big one?
I tried doing it using gnus-search, like this:
(nnselect-request-create-group
"family" nil '((nnselect-specs
(nnselect-function . gnus-search-run-query)
(nnselect-args
(search-query-spec
(query . "*"))
(search-group-spec
("nnimap:NEA" "family.Dad" "family.Mom"))))))
But it gave me:
nnselect-request-update-info: Wrong type argument: consp, nil
Which I haven't looked into further. But maybe the right approach is a
custom 'nnselect-function, where the `nnselect-args is the list of
groups to combine, and then the function just... returns all the
articles in those groups? Or something?
Thanks for any hints!
Eric
On Tuesday, 1 Feb 2022 at 10:46, Eric Abrahamsen wrote: > Right, that's what I was saying in my original message: I'm pretty sure > this is possible, but I don't know the correct syntax. It's reassuring that it's not just me. :-) > Once that's sorted out, then we could add a convenience function that > makes "virtual" style select groups easier to create. Yes, this would be good. I look forward to seeing what Andy says. thank you, eric -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2
Hi, Here are some of my observations about nnselect groups : *** nnselect groups :PROPERTIES: :header-args: :noweb-ref gnus-nnselect-groups :tangle no :END: The nnselect method replaces the obsolete nnir method and most usage of virtual groups. Basically it lets you makes searches out of your servers, eventually making it permanent as a new group. It is designed to be build interactively (and well, it's /kinda/ easier). Can we wrap it non-interactively so it becomes declarative ? Yup. #+begin_src emacs-lisp (with-eval-after-load 'gnus (defun dal-gnus-group-make-group-batch (name meth address args) "Same as `gnus-group-make-group', but can be run non-interactively." (unless (gnus-get-info (gnus-group-prefixed-name name meth)) (cl-letf (((symbol-function 'gnus-group-insert-group-line-info) #'ignore) ((symbol-function 'gnus-group-position-point) #'ignore)) (save-excursion (gnus-group-make-group name meth address args)))))) (add-hook 'gnus-topic-mode-hook (lambda () (dal-gnus-group-make-group-batch "recent" '(nnselect "nnselect") nil '((nnselect-specs (nnselect-function . gnus-search-run-query) (nnselect-args (search-query-spec (query . "sentsince:7d")) (search-group-spec ("nnimap:Dal")))) (nnselect-rescan . t))))) #+end_src The group creation does not allow to specify arbitrary group parameters, let's correct that. #+begin_src emacs-lisp (with-eval-after-load 'nnoo ;; First the creation of the group does not allow to set parameters. (defun nnselect-request-create-group-a (group &optional _server args) (message "Creating nnselect group %s" group) (let* ((group (gnus-group-prefixed-name group '(nnselect "nnselect"))) (specs (assq 'nnselect-specs args)) (function-spec (or (alist-get 'nnselect-function specs) (intern (completing-read "Function: " obarray #'functionp)))) (args-spec (or (alist-get 'nnselect-args specs) (read-from-minibuffer "Args: " nil nil t nil "nil"))) (nnselect-specs (list (cons 'nnselect-function function-spec) (cons 'nnselect-args args-spec)))) (gnus-group-set-parameter group 'nnselect-specs nnselect-specs) (gnus-group-set-parameter group 'nnselect-artlist (nnselect-compress-artlist (or (alist-get 'nnselect-artlist args) (nnselect-run nnselect-specs)))) (setq args (assq-delete-all 'nnselect-specs args)) ;; patch (dolist (param args) (gnus-group-set-parameter group (car param) (cdr param))) (nnselect-request-update-info group (gnus-get-info group))) t) (advice-add 'nnselect-request-create-group :override #'nnselect-request-create-group-a) #+end_src Rescan the group regularly. but that doesn't work ?! Wth ? #+begin_src emacs-lisp (add-to-list 'gnus-parameters '("nnselect:recent" (nnselect-rescan . t))) #+end_src It doesn't work because of a confusion between ~gnus-group-get-parameter~ and ~gnus-group-find-parameter~. #+begin_src emacs-lisp (defun nnselect-request-scan-a (group _method) (when (and group (gnus-group-find-parameter (nnselect-add-prefix group) ; patch 'nnselect-rescan t)) (nnselect-request-group-scan group))) (advice-add 'nnselect-request-scan :override #'nnselect-request-scan-a)) #+end_src
>>>>> "dal-blazej" == dal-blazej <dal-blazej@onenetbeyond.org> writes:
dal-blazej> Hi, Here are some of my observations about nnselect
dal-blazej> groups :
[...]
dal-blazej> The group creation does not allow to specify arbitrary
dal-blazej> group parameters, let's correct that.
Good idea, I'll incorporate that.
dal-blazej> Rescan the group regularly. but that doesn't work ?!
dal-blazej> Wth ?
And nice catch---I'll incorporate this fix too.
--
Andrew Cohen