[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
bug#29290: 25.3; bug-gnu-emacs archive web search fails to find matching bugs, Eli Zaretskii, 2017/11/14