* nnir-run-gmane search broken
@ 2010-12-07 4:08 Matt Lundin
2010-12-07 10:09 ` Robert Pluim
0 siblings, 1 reply; 6+ messages in thread
From: Matt Lundin @ 2010-12-07 4:08 UTC (permalink / raw)
To: ding
Commit 37a6bcd4423177ae79be2f6ac5b8f8ea4829aca7 broke nnir searches on
my gmane groups. I surmise this is because the nntp-address that nnir
looks for is not always present in the select method. My
gnus-select-method looks like this:
(setq gnus-select-method '(nntp "news.gmane.org"))
As a result, line 1383 in nnir.el...
(cadr (assoc 'nntp-address
(cddr (gnus-server-to-method "nntp:news.gmane.org"))))
...evaluates to nil, because...
(gnus-server-to-method "nntp:news.gmane.org")
...evaluates simply to...
(nntp "news.gmane.org")
Best,
Matt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nnir-run-gmane search broken
2010-12-07 4:08 nnir-run-gmane search broken Matt Lundin
@ 2010-12-07 10:09 ` Robert Pluim
2010-12-07 13:20 ` Andrew Cohen
0 siblings, 1 reply; 6+ messages in thread
From: Robert Pluim @ 2010-12-07 10:09 UTC (permalink / raw)
To: ding
Matt Lundin <mdl@imapmail.org> writes:
> Commit 37a6bcd4423177ae79be2f6ac5b8f8ea4829aca7 broke nnir searches on
> my gmane groups. I surmise this is because the nntp-address that nnir
> looks for is not always present in the select method. My
> gnus-select-method looks like this:
>
> (setq gnus-select-method '(nntp "news.gmane.org"))
>
> As a result, line 1383 in nnir.el...
>
> (cadr (assoc 'nntp-address
> (cddr (gnus-server-to-method "nntp:news.gmane.org"))))
>
> ...evaluates to nil, because...
>
> (gnus-server-to-method "nntp:news.gmane.org")
>
> ...evaluates simply to...
>
> (nntp "news.gmane.org")
Should this not fallback to using nnir-method-default-engines? (I
haven't checked the code)
Robert
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nnir-run-gmane search broken
2010-12-07 10:09 ` Robert Pluim
@ 2010-12-07 13:20 ` Andrew Cohen
2010-12-08 19:17 ` Matt Lundin
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cohen @ 2010-12-07 13:20 UTC (permalink / raw)
To: ding
>>>>> "Robert" == Robert Pluim <rpluim@gmail.com> writes:
Robert> Matt Lundin <mdl@imapmail.org> writes:
>> Commit 37a6bcd4423177ae79be2f6ac5b8f8ea4829aca7 broke nnir
>> searches on my gmane groups. I surmise this is because the
>> nntp-address that nnir looks for is not always present in the
>> select method. My gnus-select-method looks like this:
>>
>> (setq gnus-select-method '(nntp "news.gmane.org"))
>>
>> As a result, line 1383 in nnir.el...
>>
>> (cadr (assoc 'nntp-address (cddr (gnus-server-to-method
>> "nntp:news.gmane.org"))))
>>
>> ...evaluates to nil, because...
>>
>> (gnus-server-to-method "nntp:news.gmane.org")
>>
>> ...evaluates simply to...
>>
>> (nntp "news.gmane.org")
Ugh. Previously I just checked whether the server name had gmane in
it. But this isn't great since someone might have the string "gmane" in
their own server that isn't really news.gmane.org (why? I have no idea,
but people are funny that way). So I thought it would be safer to test
the 'nntp-address. But you don't have the address set, which is the
cause of the failure.
Several options here:
1. Require the presence of 'nntp-address in the server definition (and
nnir-run-gmane could warn if this variable is not present and suggest
adding it). This is probably the "right" solution, but requires
work on the part of the user.
2. Turn off checking altogether. This would have the undesired effect of
making an http connection to search.gmane.org when searching on
non-gmane groups. Nothing really bad happens since no search results
will be found, but its a waste of a network roundtrip and of
resources on search.gmane.org. I don't like it.
3. A compromise: go back to the crappy test of gmane in the server
name. Most of the time this will DTRT except when a user has the
string "gmane" in some server that isn't really news.gmane.org (or
snews.gmane.org). This has the defects of 2, but only in rare cases.
I'll push 3 right now, but if anyone prefers something else let me know.
Andy
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: nnir-run-gmane search broken
2010-12-07 13:20 ` Andrew Cohen
@ 2010-12-08 19:17 ` Matt Lundin
2010-12-08 19:27 ` Matt Lundin
0 siblings, 1 reply; 6+ messages in thread
From: Matt Lundin @ 2010-12-08 19:17 UTC (permalink / raw)
To: ding
Andrew Cohen <cohen@andy.bu.edu> writes:
> Ugh. Previously I just checked whether the server name had gmane in
> it. But this isn't great since someone might have the string "gmane"
> in their own server that isn't really news.gmane.org (why? I have no
> idea, but people are funny that way). So I thought it would be safer
> to test the 'nntp-address. But you don't have the address set, which
> is the cause of the failure.
>
> Several options here:
>
> 1. Require the presence of 'nntp-address in the server definition (and
> nnir-run-gmane could warn if this variable is not present and suggest
> adding it). This is probably the "right" solution, but requires
> work on the part of the user.
And I think the manual (not to mention many .gnus files) would need to
be updated, since it offers examples of the short method:
(setq gnus-select-method '(nntp "news.somewhere.edu"))
(info "(gnus) Finding the News")
>
> 3. A compromise: go back to the crappy test of gmane in the server
> name. Most of the time this will DTRT except when a user has the
> string "gmane" in some server that isn't really news.gmane.org (or
> snews.gmane.org). This has the defects of 2, but only in rare
> cases.
Could we simply check whether the nntp-address is defined? If so, then
the nntp-address must match "gmane.org$"; if not, then the server name
should match "gmane.org$". These are effectively the same test, since in
the shorter method of defining the server the name *is* the address. In
other words, if one uses a "nickname" (supergmane, gmaneman, etc.) for
some other nntp server, then one must define an nntp-address;
conversely, if one does not define an nntp-address, then the name of the
server has to be the full address. In either case, you are testing
against the address instead of some arbitrary name and thus can enforce
the stricter match ("gmane.org$").
Another issue here: I believe one can currently access the complete
gmane hierarchy via news.gwene.org.
Best,
Matt
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: nnir-run-gmane search broken
2010-12-08 19:17 ` Matt Lundin
@ 2010-12-08 19:27 ` Matt Lundin
2010-12-10 15:01 ` Matt Lundin
0 siblings, 1 reply; 6+ messages in thread
From: Matt Lundin @ 2010-12-08 19:27 UTC (permalink / raw)
To: ding
Matt Lundin <mdl@imapmail.org> writes:
> Andrew Cohen <cohen@andy.bu.edu> writes:
>> 3. A compromise: go back to the crappy test of gmane in the server
>> name. Most of the time this will DTRT except when a user has the
>> string "gmane" in some server that isn't really news.gmane.org (or
>> snews.gmane.org). This has the defects of 2, but only in rare
>> cases.
>
> Could we simply check whether the nntp-address is defined? If so, then
> the nntp-address must match "gmane.org$"; if not, then the server name
> should match "gmane.org$". These are effectively the same test, since in
> the shorter method of defining the server the name *is* the address. In
> other words, if one uses a "nickname" (supergmane, gmaneman, etc.) for
> some other nntp server, then one must define an nntp-address;
> conversely, if one does not define an nntp-address, then the name of the
> server has to be the full address. In either case, you are testing
> against the address instead of some arbitrary name and thus can enforce
> the stricter match ("gmane.org$").
>
I suppose I should have written "gmane\.org$" (or "gmane\\.org$" for the
emacs-lisp). :)
Best,
Matt
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: nnir-run-gmane search broken
2010-12-08 19:27 ` Matt Lundin
@ 2010-12-10 15:01 ` Matt Lundin
0 siblings, 0 replies; 6+ messages in thread
From: Matt Lundin @ 2010-12-10 15:01 UTC (permalink / raw)
To: ding
Matt Lundin <mdl@imapmail.org> writes:
> Matt Lundin <mdl@imapmail.org> writes:
>
>> Andrew Cohen <cohen@andy.bu.edu> writes:
>>> 3. A compromise: go back to the crappy test of gmane in the server
>>> name. Most of the time this will DTRT except when a user has the
>>> string "gmane" in some server that isn't really news.gmane.org (or
>>> snews.gmane.org). This has the defects of 2, but only in rare
>>> cases.
>>
>> Could we simply check whether the nntp-address is defined? If so, then
>> the nntp-address must match "gmane.org$"; if not, then the server name
>> should match "gmane.org$". These are effectively the same test, since in
>> the shorter method of defining the server the name *is* the address. In
>> other words, if one uses a "nickname" (supergmane, gmaneman, etc.) for
>> some other nntp server, then one must define an nntp-address;
>> conversely, if one does not define an nntp-address, then the name of the
>> server has to be the full address. In either case, you are testing
>> against the address instead of some arbitrary name and thus can enforce
>> the stricter match ("gmane.org$").
>>
>
> I suppose I should have written "gmane\.org$" (or "gmane\\.org$" for the
> emacs-lisp). :)
>
Here's a brief patch that implements my rather verbose proposal above.
Best,
Matt
diff --git a/lisp/nnir.el b/lisp/nnir.el
index 726b015..820e565 100644
--- a/lisp/nnir.el
+++ b/lisp/nnir.el
@@ -1394,7 +1394,10 @@ Tested with Namazu 2.0.6 on a GNU/Linux system."
;; gmane interface
(defun nnir-run-gmane (query srv &optional groups)
"Run a search against a gmane back-end server."
- (if (gnus-string-match-p "gmane" srv)
+ (if (gnus-string-match-p
+ "gmane\\.org$"
+ (or (cadr (assoc 'nntp-address (cddr (gnus-server-to-method srv))))
+ srv))
(let* ((case-fold-search t)
(qstring (cdr (assq 'query query)))
(server (cadr (gnus-server-to-method srv)))
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-12-10 15:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-07 4:08 nnir-run-gmane search broken Matt Lundin
2010-12-07 10:09 ` Robert Pluim
2010-12-07 13:20 ` Andrew Cohen
2010-12-08 19:17 ` Matt Lundin
2010-12-08 19:27 ` Matt Lundin
2010-12-10 15:01 ` Matt Lundin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).