Query doesn't seem to work for feeds comming from elfeed-protocol

[Thaodan]

Hey.

Does the query option use tags applied by autotags or just general tag?
I'm not sure if I explain properly but I applied tags with elfeed-autoags per feed entry for each feed item cumming from Nextcloud.

For example this is a section of my groups:

(group (:title . "Software Development")
       (:elements (query . (and dev))
                  (group . ((:title . "C++")
                            (:elements (query . (and cxx))
                                       (group . ((:title . "Qt")
                                                 (:elements (query . (and Qt))))))))
                  (group . ((:title . "Python")
                            (:elements (query . (and python)))))
                  (group . ((:title . "C")
                            (:elements (query . (and c))
                                       (group . ((:title . "GTK")
                                                 (:elements (query . (and gtk))))))))
                  (group . ((:title . "Rust")
                            (:elements  (query . (and rust)))))))

None of these groups seem to contains entries even thou there are feed entries matching these tags.
If I use search instead of query some feed entries are found.

[SqrtMinusOne]

query uses tags from elfeed-feeds, and it returns feeds rather than individual entries. E.g.

(("http://feeds.arstechnica.com/arstechnica/index/" news tech)
 ("https://my-instance-of-rss-bridge.com/?action=display&bridge=BleepingComputer&format=Atom" news tech))

(query . (and tech)) will return these two.

If you want individual entries (e.g. ones with the tag Qt), you can use

(search
 (:filter . "@6-months-ago +unread +Qt")
 (:title . "Qt"))

[Thaodan]

query uses tags from elfeed-feeds, and it returns feeds rather than individual entries. E.g.

That explains it, which would require that elfeed-protocol allows to declare the tag for each individual feed.

If you want individual entries (e.g. ones with the tag Qt), you can use

That is how I did it now, can I nest searches?

[SqrtMinusOne]

can I nest searches?

What do you mean by nesting? You can use the full elfeed filter syntax in :filter. It isn't too expressive, but at least queries with multiple tags are allowed, e.g. +tag1 +tag2 -tag3.

And you can put (search ...) anywhere you can put (query ...), as in your original example.

[Thaodan]

can I nest searches?

What do you mean by nesting? You can use the full elfeed filter syntax in :filter. It isn't too expressive, but at least queries with multiple tags are allowed, e.g. +tag1 +tag2 -tag3.

And you can put (search ...) anywhere you can put (query ...), as in your original example.

I meant I want to nest one search into another to avoid to have some searches for some tags double.
I have for example the tag Emacs that also applied to all the items having the tag org-mode.

[SqrtMinusOne]

I want to nest one search into another to avoid to have some searches for some tags double

So, basically make all the child searches inherit some parameters from the parent search? As of now, that's not possible unfortunately.

Maybe I'll make something like that in the future, but I'm not quite convinced it's worth the effort. There doesn't seem to be a whole lot of duplication to remove this way.

[Thaodan]

Yeah I use elfeed

So, basically make all the child searches inherit some parameters from the parent search? As of now, that's not possible unfortunately.

That isn't needed since they inherit the tags, the feed item should be just shown in a tree like or nested structure.

My feeds get tagged like this through Elfeed-Autotag:

** Software Development                                                   :dev:
*** C++                                                               :cxx:dev:
    :PROPERTIES:
    :CREATED:  [2022-11-15 Di 19:35]
    :END:
**** entry-title: \(C++\)
     :PROPERTIES:
     :CREATED:  [2022-11-15 Di 19:36]
     :END:
**** Qt                                                                       :Qt:
***** entry-title: \(\[Qq\]t\)
      :PROPERTIES:
      :CREATED:  [2022-11-15 Di 17:04]
      :END:
*** Python                                                               :python:
**** entry-title: \(python\|py\)
     :PROPERTIES:
     :CREATED:  [2022-11-15 Di 17:04]
     :END:
*** C
    :PROPERTIES:
    :CREATED:  [2022-11-15 Di 19:35]
    :END:
**** GTK                                                                     :gtk:
     :PROPERTIES:
     :CREATED:  [2022-11-15 Di 19:30]
     :END:
***** entry-title: \(gtk\|GTK\)
      :PROPERTIES:
      :CREATED:  [2022-11-15 Di 19:30]
      :END:
*** Rust                                                                 :rust:
    :PROPERTIES:
    :CREATED:  [2022-11-16 Mi 13:06]
    :END:
**** entry-title: \(rust\)
     :PROPERTIES:
     :CREATED:  [2022-11-16 Mi 13:06]
     :END:

[SqrtMinusOne]

So, in a syntax like that

 (group (:title . "Software Development")
        (:elements (search
                    (:filter . "@6-months-ago +dev")
                    (:title . "Software development"))
                   (group
                    (:title . "C++")
                    (:elements
                     (search
                      (:filter . "@6-months-ago +dev +cxx")
                      (:title . "C++"))
                     (search
                      (:filter . "@6-months-ago +dev +cxx +Qt")
                      (:title . "Qt"))))))

you want to avoid that +dev +cxx +Qt part? Which is what I meant in the previous comment.

The tree structure for the above looks something like

- Software Development [group]
  - Software Development [search]
  - C++ [group]
    - C++ [search]
    - Qt [search]

It's also not possible to group elements under searches, so there's a group called "Software Development" and a search with the same name. So yeah, I guess this is suboptimal for your case, if I understand that correctly.

No two elfeed setups are quite the same :)

[Thaodan]

Yeah that's how it looks for me right now. Optionally filter should apply the global filters such as unread or not unread.

How would you add the default parameters to :filter? elfeed-summary--build-search could add them.

[SqrtMinusOne]

Adding that to the list of enhancements, provided that I understood your idea correctly.

I've remembered that I wanted to have a bit more complex logic around elfeed searches, so I think I'll implement that and the discussed enhancement as well.

Probably not quite in the nearest future, but will do when I'm a bit less overloaded with various development.

Also, the +unread tag is already added automatically when you open a feed or search that has at least one unread record (I was inspired by tt-rss in that regard). You can do M-RET to force it to show all entries.

[Thaodan]

Also, the +unread tag is already added automatically when you open a feed or search that has at least one unread record (I was inspired by tt-rss in that regard). You can do M-RET to force it to show all entries.

That doesn't seem to work for me, for example for Qt the filter is always +Qt and not +Qt or +Qt +unread depending on the read-status.

[Thaodan]

I've remembered that I wanted to have a bit more complex logic around elfeed searches, so I think I'll implement that and the discussed enhancement as well.

That is my attempt to add such a thing so far:

@@ -479,11 +483,16 @@ SEARCH is a `<search-params>' form as described in
 `elfeed-summary-settings'.
 
 Implented the same way as `elfeed-search--update-list'."
-  (let* ((filter (elfeed-search-parse-filter (alist-get :filter search)))
+  (let* ((filterstr (if (alist-get :default search)
+                        (concat (alist-get :filter search) " "
+                                elfeed-summary-default-filter)
+                      (alist-get :filter search)))
+         (filter (elfeed-search-parse-filter filterstr))
          (head (list nil))
          (tail head)
          (unread 0)
          (total 0))

However the filterstr is modified but isn't applied when elfeed-search is opened from the filter.

[SqrtMinusOne]

That doesn't seem to work for me

That was meant to be :) Fixed in 125e0f0.

That is my attempt to add such a thing so far

Just prepending the filter string with elfeed-summary-default-filter is more or less trivial, added that as well. :add-default in the search form enables it now:

(search
 (:filter . "+unread sqrtminusone")
 (:title . "About me")
 (:add-default t))

Just had to modify the corresponding action functions.

I may have thought you needed something more complex if that's all you were trying to do.

[Thaodan]

Hey,

I got into this issue again. Your last changes work quite good except in case of the "ungrouped" doesn't indicate unread entries:

      (group (:title . "Ungrouped")
                    (:elements :misc)
                    (:add-default . t))))

The resulting elfeed filter when selecting the entry including read entries in my case is:
-youtube =owncloud\+https://cloud.example.com