gnus-group-read-ephemeral-search-group -- Something Changed?

gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

I use gnus-group-read-ephemeral-search-group to search GMail via imap,
see details in this blog article:
https://emacspeak.blogspot.com/2020/09/searching-gmail-from-gnus.html

About  8 weeks or so, that function
gnus-group-read-ephemeral-search-group was declared obsolete but its
replacement was supposed to be backward compatible and everything
worked until about 2 days ago --- or from memory I updated/rebuilt
emacs yesterday and it's broken today.

Broken: How,

Now, when I invoke the afore-mentioned function
I get an additional prompt after supplying the query  and calling it
with the imap-search spec it expects. A quick look in git logs didn't
show anything suspicious, other than the file was changed with
comments to the effect that that function is obsolete.

-- 

Thanks,

--Raman
♉ Id: kg:/m/0285kf1  🦮

-- 

Thanks,

--Raman
♉ Id: kg:/m/0285kf1  🦮

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> I use gnus-group-read-ephemeral-search-group to search GMail via imap,
> see details in this blog article:
> https://emacspeak.blogspot.com/2020/09/searching-gmail-from-gnus.html
>
> About  8 weeks or so, that function
> gnus-group-read-ephemeral-search-group was declared obsolete but its
> replacement was supposed to be backward compatible and everything
> worked until about 2 days ago --- or from memory I updated/rebuilt
> emacs yesterday and it's broken today.
>
> Broken: How,
>
> Now, when I invoke the afore-mentioned function
> I get an additional prompt after supplying the query  and calling it
> with the imap-search spec it expects. A quick look in git logs didn't
> show anything suspicious, other than the file was changed with
> comments to the effect that that function is obsolete.

Yes, this function has changed in the past couple of days, as nnir.el
has been obsoleted. I'm guessing you're calling
`gnus-gorup-read-ephemeral-search-group' with a spec that contains an
`nnir-search-spec' key? That key is now called `gnus-search-spec'.

I can provide better backwards compatibility by continuing to check for
the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
think people would be using that function programmatically in this way.

Would you be willing to show me exactly how you're calling this
function? I can be more certain about providing backwards compatibility
that way, and might be able to suggest some alterations.

Sorry for the roadbump,

Eric

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

you're correct. But please keep the backward compatibility, since I
need emacspeak to work with both the released emacs 27, as well as
emacs-28 built from head which I use --- that latter is what helps me
make sure that when Emacs-28 does get released, emacspeak works out of
the box with it.Eric Abrahamsen writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > I use gnus-group-read-ephemeral-search-group to search GMail via imap,
 > > see details in this blog article:
 > > https://emacspeak.blogspot.com/2020/09/searching-gmail-from-gnus.html
 > >
 > > About  8 weeks or so, that function
 > > gnus-group-read-ephemeral-search-group was declared obsolete but its
 > > replacement was supposed to be backward compatible and everything
 > > worked until about 2 days ago --- or from memory I updated/rebuilt
 > > emacs yesterday and it's broken today.
 > >
 > > Broken: How,
 > >
 > > Now, when I invoke the afore-mentioned function
 > > I get an additional prompt after supplying the query  and calling it
 > > with the imap-search spec it expects. A quick look in git logs didn't
 > > show anything suspicious, other than the file was changed with
 > > comments to the effect that that function is obsolete.
 > 
 > Yes, this function has changed in the past couple of days, as nnir.el
 > has been obsoleted. I'm guessing you're calling
 > `gnus-gorup-read-ephemeral-search-group' with a spec that contains an
 > `nnir-search-spec' key? That key is now called `gnus-search-spec'.
 > 
 > I can provide better backwards compatibility by continuing to check for
 > the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
 > think people would be using that function programmatically in this way.
 > 
 > Would you be willing to show me exactly how you're calling this
 > function? I can be more certain about providing backwards compatibility
 > that way, and might be able to suggest some alterations.
 > 
 > Sorry for the roadbump,
 > 
 > Eric

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> you're correct. But please keep the backward compatibility, since I
> need emacspeak to work with both the released emacs 27, as well as
> emacs-28 built from head which I use --- that latter is what helps me
> make sure that when Emacs-28 does get released, emacspeak works out of
> the box with it.

Okay, will do. Are you sure that checking for the nnir key symbol is
enough to make everything work correctly?

> > Eric Abrahamsen writes:
>  > "T.V Raman" <raman@google.com> writes:
>  > 
>  > > I use gnus-group-read-ephemeral-search-group to search GMail via imap,
>  > > see details in this blog article:
>  > > https://emacspeak.blogspot.com/2020/09/searching-gmail-from-gnus.html
>  > >
>  > > About  8 weeks or so, that function
>  > > gnus-group-read-ephemeral-search-group was declared obsolete but its
>  > > replacement was supposed to be backward compatible and everything
>  > > worked until about 2 days ago --- or from memory I updated/rebuilt
>  > > emacs yesterday and it's broken today.
>  > >
>  > > Broken: How,
>  > >
>  > > Now, when I invoke the afore-mentioned function
>  > > I get an additional prompt after supplying the query  and calling it
>  > > with the imap-search spec it expects. A quick look in git logs didn't
>  > > show anything suspicious, other than the file was changed with
>  > > comments to the effect that that function is obsolete.
>  > 
>  > Yes, this function has changed in the past couple of days, as nnir.el
>  > has been obsoleted. I'm guessing you're calling
>  > `gnus-gorup-read-ephemeral-search-group' with a spec that contains an
>  > `nnir-search-spec' key? That key is now called `gnus-search-spec'.
>  > 
>  > I can provide better backwards compatibility by continuing to check for
>  > the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
>  > think people would be using that function programmatically in this way.
>  > 
>  > Would you be willing to show me exactly how you're calling this
>  > function? I can be more certain about providing backwards compatibility
>  > that way, and might be able to suggest some alterations.
>  > 
>  > Sorry for the roadbump,
>  > 
>  > Eric
>
> -- 
> ♉Id: kg:/m/0285kf1  🦮♉

"T.V Raman" <raman@google.com> writes:

> P.S. how am calling that function was documented in the blog article I
> mentioned; here is a pointer to the code in Git to make it easier.
> https://github.com/tvraman/emacspeak/blob/master/lisp/gm-nnir.el#L133

I'll take a look at this over the weekend. Maybe I can suggest some more
changes to take advantage of the new gnus-search.el library.

Thanks for the report,
Eric

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

Not sure, will need to try it once you've added the check for the
older keyEric Abrahamsen writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > you're correct. But please keep the backward compatibility, since I
 > > need emacspeak to work with both the released emacs 27, as well as
 > > emacs-28 built from head which I use --- that latter is what helps me
 > > make sure that when Emacs-28 does get released, emacspeak works out of
 > > the box with it.
 > 
 > Okay, will do. Are you sure that checking for the nnir key symbol is
 > enough to make everything work correctly?
 > 
 > > > Eric Abrahamsen writes:
 > >  > "T.V Raman" <raman@google.com> writes:
 > >  > 
 > >  > > I use gnus-group-read-ephemeral-search-group to search GMail via imap,
 > >  > > see details in this blog article:
 > >  > > https://emacspeak.blogspot.com/2020/09/searching-gmail-from-gnus.html
 > >  > >
 > >  > > About  8 weeks or so, that function
 > >  > > gnus-group-read-ephemeral-search-group was declared obsolete but its
 > >  > > replacement was supposed to be backward compatible and everything
 > >  > > worked until about 2 days ago --- or from memory I updated/rebuilt
 > >  > > emacs yesterday and it's broken today.
 > >  > >
 > >  > > Broken: How,
 > >  > >
 > >  > > Now, when I invoke the afore-mentioned function
 > >  > > I get an additional prompt after supplying the query  and calling it
 > >  > > with the imap-search spec it expects. A quick look in git logs didn't
 > >  > > show anything suspicious, other than the file was changed with
 > >  > > comments to the effect that that function is obsolete.
 > >  > 
 > >  > Yes, this function has changed in the past couple of days, as nnir.el
 > >  > has been obsoleted. I'm guessing you're calling
 > >  > `gnus-gorup-read-ephemeral-search-group' with a spec that contains an
 > >  > `nnir-search-spec' key? That key is now called `gnus-search-spec'.
 > >  > 
 > >  > I can provide better backwards compatibility by continuing to check for
 > >  > the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
 > >  > think people would be using that function programmatically in this way.
 > >  > 
 > >  > Would you be willing to show me exactly how you're calling this
 > >  > function? I can be more certain about providing backwards compatibility
 > >  > that way, and might be able to suggest some alterations.
 > >  > 
 > >  > Sorry for the roadbump,
 > >  > 
 > >  > Eric
 > >
 > > -- 
 > > ♉Id: kg:/m/0285kf1  🦮♉
 > 
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > P.S. how am calling that function was documented in the blog article I
 > > mentioned; here is a pointer to the code in Git to make it easier.
 > > https://github.com/tvraman/emacspeak/blob/master/lisp/gm-nnir.el#L133
 > 
 > I'll take a look at this over the weekend. Maybe I can suggest some more
 > changes to take advantage of the new gnus-search.el library.
 > 
 > Thanks for the report,
 > Eric

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

P.S. how am calling that function was documented in the blog article I
mentioned; here is a pointer to the code in Git to make it easier.
https://github.com/tvraman/emacspeak/blob/master/lisp/gm-nnir.el#L133
-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I can provide better backwards compatibility by continuing to check for
> the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
> think people would be using that function programmatically in this way.
>
> Would you be willing to show me exactly how you're calling this
> function? I can be more certain about providing backwards compatibility
> that way, and might be able to suggest some alterations.

I am calling the same function using the default keybinding `G G'. And
it is giving this error to me.

--8<---------------cut here---------------start------------->8---
cl-no-applicable-method: No applicable method: gnus-search-run-search,
nil, "nnimap:gml", ((parsed-query "hello") (query . "hello") (raw)),
("nnimap+gml:INBOX")
--8<---------------cut here---------------end--------------->8---

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I can provide better backwards compatibility by continuing to check for
>> the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
>> think people would be using that function programmatically in this way.
>>
>> Would you be willing to show me exactly how you're calling this
>> function? I can be more certain about providing backwards compatibility
>> that way, and might be able to suggest some alterations.
>
> I am calling the same function using the default keybinding `G G'. And
> it is giving this error to me.
>
> cl-no-applicable-method: No applicable method: gnus-search-run-search,
> nil, "nnimap:gml", ((parsed-query "hello") (query . "hello") (raw)),
> ("nnimap+gml:INBOX")

This is the error you'd get if gnus-search can't find the right search
engine to use for nnimap servers. I just changed the type of the default
value of `gnus-search-default-engines', so maybe you've gotten caught in
between. Can you please confirm that you're using the latest master, and
that the value of `gnus-search-default-engines' looks like:

'((nnimap . gnus-search-imap))

Thanks

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> I am calling the same function using the default keybinding `G G'. And
>> it is giving this error to me.
>>
>> cl-no-applicable-method: No applicable method: gnus-search-run-search,
>> nil, "nnimap:gml", ((parsed-query "hello") (query . "hello") (raw)),
>> ("nnimap+gml:INBOX")
>
> This is the error you'd get if gnus-search can't find the right search
> engine to use for nnimap servers. I just changed the type of the default
> value of `gnus-search-default-engines', so maybe you've gotten caught in
> between. Can you please confirm that you're using the latest master, and
> that the value of `gnus-search-default-engines' looks like:
>
> '((nnimap . gnus-search-imap))

I am on the master and the value of `gnus-search-default-engines' is,

Its value is ((nnimap gnus-search-imap))
Original value was 
((nnimap . gnus-search-imap))

Earlier, I had this in my file,

(require 'nnir)
(setq nnir-method-default-engines
      '((nnml . notmuch)
	(nnimap . imap)))
        
But after the merge, I have changed it to,

(let ((maxver 27))
  (if (> emacs-major-version maxver)
      (custom-set-variables
       '(gnus-search-default-engines
	 '((nnimap gnus-search-imap)))
       '(gnus-search-use-parsed-queries t))
    (custom-set-variables
       '(nnir-method-default-engines
	 '((nnimap imap))))))

It started working again when I changed them back to cons cells.

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> I am calling the same function using the default keybinding `G G'. And
>>> it is giving this error to me.
>>>
>>> cl-no-applicable-method: No applicable method: gnus-search-run-search,
>>> nil, "nnimap:gml", ((parsed-query "hello") (query . "hello") (raw)),
>>> ("nnimap+gml:INBOX")
>>
>> This is the error you'd get if gnus-search can't find the right search
>> engine to use for nnimap servers. I just changed the type of the default
>> value of `gnus-search-default-engines', so maybe you've gotten caught in
>> between. Can you please confirm that you're using the latest master, and
>> that the value of `gnus-search-default-engines' looks like:
>>
>> '((nnimap . gnus-search-imap))
>
> I am on the master and the value of `gnus-search-default-engines' is,
>
> Its value is ((nnimap gnus-search-imap))
> Original value was 
> ((nnimap . gnus-search-imap))
>
> Earlier, I had this in my file,
>
> (require 'nnir)
> (setq nnir-method-default-engines
>       '((nnml . notmuch)
> 	(nnimap . imap)))
>         
> But after the merge, I have changed it to,
>
> (let ((maxver 27))
>   (if (> emacs-major-version maxver)
>       (custom-set-variables
>        '(gnus-search-default-engines
> 	 '((nnimap gnus-search-imap)))
>        '(gnus-search-use-parsed-queries t))
>     (custom-set-variables
>        '(nnir-method-default-engines
> 	 '((nnimap imap))))))
>
> It started working again when I changed them back to cons cells.

There are downsides to being an early adopter (the earliest)! Hopefully
sailing will be smoother here on out.

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> It started working again when I changed them back to cons cells.
>
> There are downsides to being an early adopter (the earliest)! Hopefully
> sailing will be smoother here on out.

Definitely, it will change the whole experience I am sure. Two things I
am enjoying:

   1. No more server-side filtering rules.
   2. No more splitting rules that add to launch time of Gnus.

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> It started working again when I changed them back to cons cells.
>>
>> There are downsides to being an early adopter (the earliest)! Hopefully
>> sailing will be smoother here on out.
>
> Definitely, it will change the whole experience I am sure. Two things I
> am enjoying:
>
>    1. No more server-side filtering rules.
>    2. No more splitting rules that add to launch time of Gnus.

Personally I think I'll come down somewhere in the middle: server-side
sieve rules for messages that don't ever need to be mingled (those from
the utility companies or the bank), and then persistent searches for
pulling together other "thematically linked" messages.

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Stefan Monnier]

> There are downsides to being an early adopter (the earliest)! Hopefully
> sailing will be smoother here on out.

I'm talking about things I don't know, but seeing this exchange from the
back of the room gives me the impression that maybe gnus-search should
try and signal a more user-friendly error in his case rather than expose
a "no applicable method" that doesn't seem immediately related to
his settings.


        Stefan

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There are downsides to being an early adopter (the earliest)! Hopefully
>> sailing will be smoother here on out.
>
> I'm talking about things I don't know, but seeing this exchange from the
> back of the room gives me the impression that maybe gnus-search should
> try and signal a more user-friendly error in his case rather than expose
> a "no applicable method" that doesn't seem immediately related to
> his settings.

I'm definitely coming to the same conclusion. No user should ever see a
"no applicable method" error.

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 151 bytes --]

I just did a git update and build, and the problem I reported originally
still remains.
-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> I just did a git update and build, and the problem I reported originally
> still remains.

I just pushed this and some other changes, please pull and try again!

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 533 bytes --]

It's still broken (just pulled and built). Now I get the error:

 No search engine defined for (nnimap "gmail" (nnimap-address
 "imap.gmail.com") (nnimap-server-port 993) (nnimap-user
 "raman@google.com") (nnimap-authenticator xoauth2) (nnimap-expunge
 always) (nnmail-expiry-wait immediate) (nnimap-streaming t)
 (nnimap-stream ssl))
 Could you perhaps move your changes to a separate branch  where we can
 debug things and restore the previously working world?
-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> It's still broken (just pulled and built). Now I get the error:
>
>  No search engine defined for (nnimap "gmail" (nnimap-address
>  "imap.gmail.com") (nnimap-server-port 993) (nnimap-user
>  "raman@google.com") (nnimap-authenticator xoauth2) (nnimap-expunge
>  always) (nnmail-expiry-wait immediate) (nnimap-streaming t)
>  (nnimap-stream ssl))
>  Could you perhaps move your changes to a separate branch  where we can
>  debug things and restore the previously working world?

With current master and `gnus-search-default-engines' at its default
value, this should not happen. Can you confirm that
`gnus-search-default-engines' contains the cons:

(nnimap . gnus-search-imap)

If it does and you still get that error, then yes I'll happily roll the
changes back out until we figure out what's going on.

Thanks,
Eric

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1196 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

It contains:
((nnimap . imap))
and I've never touched or changed that var.> "T.V Raman"
<raman@google.com> writes:
The above is the result of hitting C-x C-e over the variable name in
your message.

>
>> It's still broken (just pulled and built). Now I get the error:
>>
>>  No search engine defined for (nnimap "gmail" (nnimap-address
>>  "imap.gmail.com") (nnimap-server-port 993) (nnimap-user
>>  "raman@google.com") (nnimap-authenticator xoauth2) (nnimap-expunge
>>  always) (nnmail-expiry-wait immediate) (nnimap-streaming t)
>>  (nnimap-stream ssl))
>>  Could you perhaps move your changes to a separate branch  where we can
>>  debug things and restore the previously working world?
>
> With current master and `gnus-search-default-engines' at its default
> value, this should not happen. Can you confirm that
> `gnus-search-default-engines' contains the cons:
>
> (nnimap . gnus-search-imap)
>
> If it does and you still get that error, then yes I'll happily roll the
> changes back out until we figure out what's going on.
>
> Thanks,
> Eric

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> It contains:
> ((nnimap . imap))
> and I've never touched or changed that var.> "T.V Raman"
> <raman@google.com> writes:
> The above is the result of hitting C-x C-e over the variable name in
> your message.

That's the value of `nnir-method-default-engines'; the new
`gnus-search-default-engines' has never had that value.

Could this be the result of interaction between
`define-obsolete-variable-alias' and `defcustom'? If you've customized
`nnir-method-default-engines', and gnus-search.el contains:

(define-obsolete-variable-alias 'nnir-method-default-engines
  'gnus-search-default-engines "28.1")

(defcustom gnus-search-default-engines '((nnimap . gnus-search-imap)))

Could the customized value of `nnir-method-default-engines' be copied to
`gnus-search-default-engines'?

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Stefan Monnier]

> (define-obsolete-variable-alias 'nnir-method-default-engines
>   'gnus-search-default-engines "28.1")
>
> (defcustom gnus-search-default-engines '((nnimap . gnus-search-imap)))
>
> Could the customized value of `nnir-method-default-engines' be copied to
> `gnus-search-default-engines'?

I think it can.  At the very least if/when the (defcustom
nnir-method-default-engines ...) is executed, i.e. when `nnir.el`
is loaded.


        Stefan

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1265 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

I've not customized that variable.
The error that is thrown looks like it's not handling groups configured
via gnus-secondary-select-methods ---  which is where I have configured
my various GMail accounts.
> "T.V Raman" <raman@google.com> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>> It contains:
>> ((nnimap . imap))
>> and I've never touched or changed that var.> "T.V Raman"
>> <raman@google.com> writes:
>> The above is the result of hitting C-x C-e over the variable name in
>> your message.
>
> That's the value of `nnir-method-default-engines'; the new
> `gnus-search-default-engines' has never had that value.
>
> Could this be the result of interaction between
> `define-obsolete-variable-alias' and `defcustom'? If you've customized
> `nnir-method-default-engines', and gnus-search.el contains:
>
> (define-obsolete-variable-alias 'nnir-method-default-engines
>   'gnus-search-default-engines "28.1")
>
> (defcustom gnus-search-default-engines '((nnimap . gnus-search-imap)))
>
> Could the customized value of `nnir-method-default-engines' be copied to
> `gnus-search-default-engines'?

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> I've not customized that variable.
> The error that is thrown looks like it's not handling groups configured
> via gnus-secondary-select-methods ---  which is where I have configured
> my various GMail accounts.

That shouldn't be the problem, as `gnus-server-to-method' will find your
methods wherever you've defined them. I've just pushed a change that
checks for old nnir values no matter where they come from. If this
doesn't do the trick I'll back the changes out.

Thanks,
Eric

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 208 bytes --]

at this point, I'm unable to get it work --- also, if you have a gmail
account, it should be relatively easy to try my solution to gmail search 
-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> at this point, I'm unable to get it work --- also, if you have a gmail
> account, it should be relatively easy to try my solution to gmail search 

Okay, I've checked the emacspeak code, and tried to make sure everything
works. gnus-search now avoids parsing search queries when they come via
an 'nnir-query-spec key.

Your code passes the query in as:

`(nnir-specs (nnir-query-spec (query ,q)))

I'm not sure how this works with Emacs 27, as nnir expects the query to
be a cons cell (ie, (query . ,q)) not a two-element list. But I guess it
must be working! I've added an extra check in gnus-search to catch this
case. I hope everything's working now.

Eric

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2885 bytes --]

1. Works now, Thanks!

   2. Not sure how it worked without the "cons", but that code was written
   from memory in 2012, or thereabouts -- so even if we insist on the
   cons if it's the right thing, it's likely it might break other code
   out there.

   3. Finally, we may not be completely done, though searches now work,
      closing the ephemeral group when done causes emacs to hang -- here
      is a backtrace generated by setting debug-on-quit to t  and
      hitting C-g.

      

      Debugger entered--Lisp error: (quit)
  (nnselect-close-group "nnselect-p91mtzrfjc2.fsf" "nnselect-ephemeral")
  (gnus-close-group "nnselect:nnselect-p91mtzrfjc2.fsf")
  (#f(compiled-function (&optional temporary leave-hidden) "Exit reading current newsgroup, and then return to group selection mode.\n`gnus-exit-group-hook' is called with no arguments if that value is non-nil." (interactive nil) #<bytecode -0x457d6c6e87e41bb>) nil nil)
  (ad-Advice-gnus-summary-exit #f(compiled-function (&optional temporary leave-hidden) "Exit reading current newsgroup, and then return to group selection mode.\n`gnus-exit-group-hook' is called with no arguments if that value is non-nil." (interactive nil) #<bytecode -0x457d6c6e87e41bb>))
  (apply ad-Advice-gnus-summary-exit #f(compiled-function (&optional temporary leave-hidden) "Exit reading current newsgroup, and then return to group selection mode.\n`gnus-exit-group-hook' is called with no arguments if that value is non-nil." (interactive nil) #<bytecode -0x457d6c6e87e41bb>) nil)
  (gnus-summary-exit)
  (#<subr funcall-interactively> gnus-summary-exit)
  (apply #<subr funcall-interactively> gnus-summary-exit nil)
  (ad-Advice-funcall-interactively #<subr funcall-interactively> gnus-summary-exit)
  (apply ad-Advice-funcall-interactively #<subr funcall-interactively> gnus-summary-exit)
  (funcall-interactively gnus-summary-exit)
  (#<subr call-interactively> gnus-summary-exit nil nil)
  (apply #<subr call-interactively> gnus-summary-exit (nil nil))
  (call-interactively@ido-cr+-record-current-command #<subr call-interactively> gnus-summary-exit nil nil)
  (apply call-interactively@ido-cr+-record-current-command #<subr call-interactively> (gnus-summary-exit nil nil))
  (#f(advice-wrapper :around #<subr call-interactively> call-interactively@ido-cr+-record-current-command) gnus-summary-exit nil nil)
  (ad-Advice-call-interactively #f(advice-wrapper :around #<subr call-interactively> call-interactively@ido-cr+-record-current-command) gnus-summary-exit nil nil)
  (apply ad-Advice-call-interactively #f(advice-wrapper :around #<subr call-interactively> call-interactively@ido-cr+-record-current-command) (gnus-summary-exit nil nil))
  (call-interactively gnus-summary-exit nil nil)
  (command-execute gnus-summary-exit)

   
-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> 1. Works now, Thanks!
>
>    2. Not sure how it worked without the "cons", but that code was written
>    from memory in 2012, or thereabouts -- so even if we insist on the
>    cons if it's the right thing, it's likely it might break other code
>    out there.

If it ain't broke, let's not fix it!

>    3. Finally, we may not be completely done, though searches now work,
>       closing the ephemeral group when done causes emacs to hang -- here
>       is a backtrace generated by setting debug-on-quit to t  and
>       hitting C-g.

Does this happen if you quit the group with "Q" as well as "q"?

I wouldn't expect this to be related to gnus-search, but I assume you
haven't seen this in the time between nnselect landing, and gnus-search?

Eric

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[T.V Raman]

will keep track of it, and no, I've never seen quitting with q hang
until now.Eric Abrahamsen writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > 1. Works now, Thanks!
 > >
 > >    2. Not sure how it worked without the "cons", but that code was written
 > >    from memory in 2012, or thereabouts -- so even if we insist on the
 > >    cons if it's the right thing, it's likely it might break other code
 > >    out there.
 > 
 > If it ain't broke, let's not fix it!
 > 
 > >    3. Finally, we may not be completely done, though searches now work,
 > >       closing the ephemeral group when done causes emacs to hang -- here
 > >       is a backtrace generated by setting debug-on-quit to t  and
 > >       hitting C-g.
 > 
 > Does this happen if you quit the group with "Q" as well as "q"?
 > 
 > I wouldn't expect this to be related to gnus-search, but I assume you
 > haven't seen this in the time between nnselect landing, and gnus-search?
 > 
 > Eric

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> will keep track of it, and no, I've never seen quitting with q hang
> until now.

Okay. Andy is working on cleaning up some aspects of ephemeral group
exiting, and that may resolve this.

Re: gnus-group-read-ephemeral-search-group -- Something Changed?

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I can provide better backwards compatibility by continuing to check for
>> the `nnir-search-spec' and `nnir-group-spec' keys, I guess I didn't
>> think people would be using that function programmatically in this way.
>>
>> Would you be willing to show me exactly how you're calling this
>> function? I can be more certain about providing backwards compatibility
>> that way, and might be able to suggest some alterations.
>
> I am calling the same function using the default keybinding `G G'. And
> it is giving this error to me.
>
> cl-no-applicable-method: No applicable method: gnus-search-run-search,
> nil, "nnimap:gml", ((parsed-query "hello") (query . "hello") (raw)),
> ("nnimap+gml:INBOX")

This is the error you'd get if gnus-search can't find the right search
engine to use for nnimap servers. I just changed the type of the default
value of `gnus-search-default-engines', so maybe you've gotten caught in
between. Can you please confirm that you're using the latest master, and
that the value of `gnus-search-default-engines' looks like:

'((nnimap . gnus-search-imap))

Thanks