bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29290: 25.3; bug-gnu-emacs archive web search fails to find matching


From: myglc2
Subject: bug#29290: 25.3; bug-gnu-emacs archive web search fails to find matching bugs
Date: Tue, 14 Nov 2017 15:41:02 -0500
User-agent: mu4e 0.9.18; emacs 25.3.1

On 11/14/2017 at 18:53 Eli Zaretskii writes:

>> From: myglc2 <myglc2@gmail.com>
>> Cc: 29290@debbugs.gnu.org
>> Date: Tue, 14 Nov 2017 12:42:36 -0500
>>
>> >   https://debbugs.gnu.org/cgi/search.cgi
>> >
>> > It is more sophisticated and does find the above bug report.
>>
>> I tried the link above. It takes an unnatural amount of effort to find
>> the bug between the garbled titles and summary lines.
>
> "Garbled"?  What do you see there, exactly, and what browser did you
> use to do that?  I see nothing garbled, everything is perfectly
> legible and clear.  I wonder what did you do differently and what did
> you see.

Using Safari on Macos on https://debbugs.gnu.org/cgi/search.cgi, when I
enter "server-name AND set-variable" and look in the results for 23576,
I find ...

#23576: Re: bug#23576: [documentation] =?utf-8?Q?=E2=80=98Using?= Emacs
 as a Package: emacs
 Severity: minor;
 Sent by: Eli Zaretskii <eliz@gnu.org> at Wed, 18 May 2016 22:53:33
 +0300
 Received: (at 23576-done) by debbugs.gnu.org; 18 May 2016 19:53:50
 +0000 From debbugs-submit-bou  . . .  s as a
 =?utf-8?Q?Server=E2=80=99=3A_=E2=80=98M-x?= set-variable RET
 server-name RET foo =?utf-8?Q?RET=E2=80=99?= R  . . .  ach one a unique
 “server name”, using the variable server-name. For > example,
 M-x set-variable RET server-name R  . . .
 ode/emacs/Emacs-Server.html > > First of all, ‘M-x set-variable RET
 server-name RET foo RET' just does > not work,  . . .  rning “Value
 ‘foo' does not match type string of > server-name”. It actually
 should be ‘M-x set-variable RET serv

I call this "garbled" because it is so mangled by escape that the title
is uninformative and the paragraph is unreadable.

It looks the same in Chrome. It looks only a bit better in 'M-x eww' ...

* #23576: Re: bug#23576: [documentation] =?utf-8?Q?=E2=80=98Using?= Emacs as a 
Package:
 emacs
 Severity: minor;
 Sent by: Eli Zaretskii <eliz@gnu.org> at Wed, 18 May 2016 22:53:33 +0300

 Received: (at 23576-done) by debbugs.gnu.org; 18 May 2016 19:53:50 +0000 From
 debbugs-submit-bou . . . s as a =?utf-8?Q?Server=E2=80=99=3A_=E2=80=98M-x?=
 set-variable RET server-name RET foo =?utf-8?Q?RET=E2=80=99?= R . . . ach one 
a unique
 “server name”, using the variable server-name. For > example, M-x set-variable 
RET
 server-name R . . . ode/emacs/Emacs-Server.html > > First of all, ‘M-x 
set-variable
 RET server-name RET foo RET' just does > not work, . . . rning “Value ‘foo' 
does not
 match type string of > server-name”. It actually should be ‘M-x
 set-variable RET serv

Am I being too harsh? ;-)

>
> After getting to the above search page, I type "server-name" into the
> "Phrase" field, select "Order by Submission date", in "descending
> (number or date)" order, change "Max results" to 100, and click
> "Search".  Did you do something else?

No, the page works that way for me too.

>> > The reasons why the mailman search didn't find the report could be a
>> > few.  One of them could be the way the Subject line was formatted
>> > (download the bug report in mbox format and see for yourself).  Or it
>> > could be some other snafu.
>>
>> But aren't you alarmed it works so poorly?
>
> Alarmed? no.  Searching for a particular discussion is never easy for
> me.
>
Ouch! Search is the great success story of the the 20th century, but
only when you can read the results ;-)
>
>> > But you are advised to try the above
>> > search engine before concluding that a bug for some issue doesn't
>> > exist.
>>
>> Sorry, I didn't see that. Where is this advised?
>
> In my email.

OH, thanks. I thought you were saying I had failed to see something.
>
>> The first google hit for "emacs bug" is https://debbugs.gnu.org
>>
>> So, OK, both put you on debbugs.gnu.org. Now if you search the page for
>> "emacs" ...
>>
>> ... the first hit is the aforementioned mailman search ;-(
>>
>> ... the second hit is
>>
>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1
>>
>> ... which I can't get to find the bug ;-(
>
> I see none of what you see, sorry.  It's as if we were in two
> different worlds.  https://debbugs.gnu.org/ has a few links to usage
> notes, package maintainers, and other not-so relevant stuff, then a
> few fields to use for searching bugs by their numbers, then "General
> Search", which I never user, and lastly "Advanced Search", which is
> what I suggested to click.  How come what you see is so different?
>

No we see the same thing but I am talking about some of the what you are
calling "not-so relevant stuff" ;-)

Please look for the links on https://debbugs.gnu.org/ with "emacs" in
their title.

You will see links to ...

1) https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs

2) 
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1

These send your emacs users with bugs to report to places that you don't
recommend that they go so I am saying please change them ...

>> So, bottom line,
>>
>> 1) if you _don't want_ people to go to mailman search please _remove the
>>    1st link_ on debbugs.gnu.org
>>
>> 2) if you want people to go to the search link you gave me, please _edit
>>    the 2nd link_ debbugs.gnu.org
>>
>> 3) If you want average users to use
>>    https://debbugs.gnu.org/cgi/search.cgi to pre-chew bug reports please
>>    to improve its usability.
>
> I don't understand what you are talking about, sorry.

So I tried again. HTH - George





reply via email to

[Prev in Thread] Current Thread [Next in Thread]