unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#7449: 24.0.50; Problems with the bug-querying mechanism
@ 2010-11-20 12:29       ` Eli Zaretskii
  2010-11-23 19:44         ` Glenn Morris
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2010-11-20 12:29 UTC (permalink / raw)
  To: 7449

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your report will be posted to the bug-gnu-emacs@gnu.org mailing list
and the gnu.emacs.bug news group, and at http://debbugs.gnu.org.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

The new feature for querying existing bugs is nice (thanks!), but it
needs some polishing, IMO:

 . It doesn't seem to handle non-ASCII (e.g., UTF-8) characters well.
   E.g., I get octal escapes in the description of bug#7373.

 . It seems not to support more than one keyword.  E.g., if I type
   either "cursor" or "overlay", I get the bug #6687 listed in the
   results, but if I type "cursor overlay", I get an empty list.  Did
   I understand the syntax of the keywords incorrectly?  (Btw, it
   would be nice to tell the expected syntax in the prompt.)

 . The "Report new bug" link does nothing except displaying a message
   in the echo area.  The code has a comment "TODO: Do something!";
   what it should do is simply invoke `report-emacs-bug' (unless I'm
   missing something), perhaps after checking if there's already a bug
   report in progress.

 . The header line of the query results ("Already known bugs") should
   IMO show in parens the keywords used for the query, for reference.

 . How about doing this automatically, using the bug subject as the
   keywords?  Or at least suggest running the query before the bug
   description buffer is created and displayed?

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-11-20 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> 
<up> <down> <help-echo> <help-echo> <help-echo> <help-echo> 
M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Quit
goto-history-element: Beginning of history; no preceding item
Loading emacsbug...done
Making completion list...
Contacting host: debbugs.gnu.org:80 [5 times]
Reporting new bug!

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader browse-url wid-edit mail-utils
url-cache url-http tls mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
url-gw url-auth url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-util url-parse auth-source netrc gnus-util
url-vars mm-util mail-prsvr mailcap emacsbug regexp-opt help-mode
easymenu view tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
button minibuffer faces cus-face files text-properties overlay md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
       [not found] <mailman.5.1290257071.20963.bug-gnu-emacs@gnu.org>
@ 2010-11-20 14:19 ` Tassilo Horn
  2010-11-20 15:27   ` Michael Albinus
  0 siblings, 1 reply; 9+ messages in thread
From: Tassilo Horn @ 2010-11-20 14:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7449, Michael Albinus

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> The new feature for querying existing bugs is nice (thanks!), but it
> needs some polishing, IMO:

Definitively.  I've just gotten a mail from Michael Albinus.  He's
trying to implement a proper debbugs interface using its SOAP protocol
with far more capabilities than what I've hacked up.  So probably many
of your remarks may be already addressed in his works.

With these new information, I think that it's seems a good idea to wait
for his implementation and then use that for all the querying and result
parsing stuff.

>  . It doesn't seem to handle non-ASCII (e.g., UTF-8) characters well.
>    E.g., I get octal escapes in the description of bug#7373.

Yep, it's totally agnostic to url-encoding, except that it replaces
spaces in the keywords with + when querying.

>  . It seems not to support more than one keyword.  E.g., if I type
>    either "cursor" or "overlay", I get the bug #6687 listed in the
>    results, but if I type "cursor overlay", I get an empty list.  Did
>    I understand the syntax of the keywords incorrectly?  (Btw, it
>    would be nice to tell the expected syntax in the prompt.)

I totally agree, and I don't have any clue about the syntax, too.  It's
the same that you would use in the search-by-subject field in the web
interface.

>  . The "Report new bug" link does nothing except displaying a message
>    in the echo area.  The code has a comment "TODO: Do something!";
>    what it should do is simply invoke `report-emacs-bug' (unless I'm
>    missing something), perhaps after checking if there's already a bug
>    report in progress.

Yeah, both the append and report new bug buttons do nothing, right now.
Simply calling report-emacs-bug is not DRT, cause then the last
keystrokes that this function grabs are those from navigating through
the existing bug list.  So the querying stuff has to be invoked after
the invocation of M-x report-emacs-bug.

>  . The header line of the query results ("Already known bugs") should
>    IMO show in parens the keywords used for the query, for reference.

Yes, that's a good idea.

>  . How about doing this automatically, using the bug subject as the
>    keywords?

Then you'd most probably get zero results because debbugs seems to
search mostly literally.

>  Or at least suggest running the query before the bug description
>  buffer is created and displayed?

That's exactly the plan. :-)

I just wanted to get some feedback on the overall interface before doing
the needed restructurings in `report-emacs-bug'.

Bye,
Tassilo





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2010-11-20 14:19 ` bug#7449: 24.0.50; Problems with the bug-querying mechanism Tassilo Horn
@ 2010-11-20 15:27   ` Michael Albinus
  2010-11-20 17:02     ` Tassilo Horn
  0 siblings, 1 reply; 9+ messages in thread
From: Michael Albinus @ 2010-11-20 15:27 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: 7449, Alex Harsanyi

Tassilo Horn <tassilo@member.fsf.org> writes:

> Hi Eli,

Hi,

>> The new feature for querying existing bugs is nice (thanks!), but it
>> needs some polishing, IMO:
>
> Definitively.  I've just gotten a mail from Michael Albinus.  He's
> trying to implement a proper debbugs interface using its SOAP protocol
> with far more capabilities than what I've hacked up.  So probably many
> of your remarks may be already addressed in his works.
>
> With these new information, I think that it's seems a good idea to wait
> for his implementation and then use that for all the querying and result
> parsing stuff.

There are (at least) 2 problems which might delay publishing a little bit:

- The SOAP interface does not support querying bug subjects yet. I'm
  investigating, whether this could be enhanced.

- My code uses soap-client.el from
  <http://code.google.com/p/emacs-soap-client/>. I've asked Alex
  Harsanyi, the author, for signing FSF legal papers, and he agreed. So
  we must wait, until this procedure is finished.

>>  . It doesn't seem to handle non-ASCII (e.g., UTF-8) characters well.
>>    E.g., I get octal escapes in the description of bug#7373.
>
> Yep, it's totally agnostic to url-encoding, except that it replaces
> spaces in the keywords with + when querying.

It shouldn't be a problems when handled via SOAP.

>>  . It seems not to support more than one keyword.  E.g., if I type
>>    either "cursor" or "overlay", I get the bug #6687 listed in the
>>    results, but if I type "cursor overlay", I get an empty list.  Did
>>    I understand the syntax of the keywords incorrectly?  (Btw, it
>>    would be nice to tell the expected syntax in the prompt.)
>
> I totally agree, and I don't have any clue about the syntax, too.  It's
> the same that you would use in the search-by-subject field in the web
> interface.

I have in mind a simple interface. Strings, separated by spaces, are
used as AND concatenation. For the time being this could be in the bug's
subject, but I would also like to have a full text search in the
future. If the search is directed to other bug attributes, it could be
prefixed by the attribute, like "package:gnus" or
"submitter:tassilo@member.fsf.org".

> Bye,
> Tassilo

Best regards, Michael.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2010-11-20 15:27   ` Michael Albinus
@ 2010-11-20 17:02     ` Tassilo Horn
  2010-11-20 12:29       ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Tassilo Horn @ 2010-11-20 17:02 UTC (permalink / raw)
  To: Michael Albinus; +Cc: 7449, Alex Harsanyi

Michael Albinus <michael.albinus@gmx.de> writes:

Hi!

>>>  . It seems not to support more than one keyword.  E.g., if I type
>>>    either "cursor" or "overlay", I get the bug #6687 listed in the
>>>    results, but if I type "cursor overlay", I get an empty list.  Did
>>>    I understand the syntax of the keywords incorrectly?  (Btw, it
>>>    would be nice to tell the expected syntax in the prompt.)
>>
>> I totally agree, and I don't have any clue about the syntax, too.  It's
>> the same that you would use in the search-by-subject field in the web
>> interface.
>
> I have in mind a simple interface. Strings, separated by spaces, are
> used as AND concatenation.

That's what I've expected from the normal search, too.  And it seems to
be just that, but with the major annoyance of recognizing a subject like

  next-line, no worky!

as words "next-line,", "no", and "worky!".  So you'll find the bug with
keyword "no", but not with "next-line", because the comma is missing...

Bye,
Tassilo





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2010-11-20 12:29       ` Eli Zaretskii
@ 2010-11-23 19:44         ` Glenn Morris
  2010-11-24 12:21           ` Alex Harsanyi
  0 siblings, 1 reply; 9+ messages in thread
From: Glenn Morris @ 2010-11-23 19:44 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: 7449, Michael Albinus, Alex Harsanyi


As written it won't work in Emacs -Q, because it uses CL functions.
(This is flagged by the compiler.)





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2010-11-23 19:44         ` Glenn Morris
@ 2010-11-24 12:21           ` Alex Harsanyi
  2012-11-08  0:20             ` Glenn Morris
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Harsanyi @ 2010-11-24 12:21 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Tassilo Horn, Michael Albinus, 7449

On Wed, Nov 24, 2010 at 3:44 AM, Glenn Morris <rgm@gnu.org> wrote:
>
> As written it won't work in Emacs -Q, because it uses CL functions.
> (This is flagged by the compiler.)
>

I have rewritten the parts that used CL functions, so this package is
not required at runtime  (it is still needed at compile time).

Cheers,
Alex.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2010-11-24 12:21           ` Alex Harsanyi
@ 2012-11-08  0:20             ` Glenn Morris
  2012-11-08  7:29               ` Tassilo Horn
  0 siblings, 1 reply; 9+ messages in thread
From: Glenn Morris @ 2012-11-08  0:20 UTC (permalink / raw)
  To: 7449


I suggest just removing this stuff from emacsbug.el, since the debbugs
package in GNU ELPA provides many, many more features.

AFAIK, report-emacs-bug-query-existing-bugs isn't documented or
advertised anywhere, and hasn't seen any development.







^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2012-11-08  0:20             ` Glenn Morris
@ 2012-11-08  7:29               ` Tassilo Horn
  2012-11-10 23:20                 ` Glenn Morris
  0 siblings, 1 reply; 9+ messages in thread
From: Tassilo Horn @ 2012-11-08  7:29 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 7449

Glenn Morris <rgm@gnu.org> writes:

> I suggest just removing this stuff from emacsbug.el, since the debbugs
> package in GNU ELPA provides many, many more features.
>
> AFAIK, report-emacs-bug-query-existing-bugs isn't documented or
> advertised anywhere, and hasn't seen any development.

I agree.  I've just hacked it together to have something to query the
bug database initially, but in the meantime it has been totally
superseeded by debbugs.el.

Bye,
Tassilo





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#7449: 24.0.50; Problems with the bug-querying mechanism
  2012-11-08  7:29               ` Tassilo Horn
@ 2012-11-10 23:20                 ` Glenn Morris
  0 siblings, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2012-11-10 23:20 UTC (permalink / raw)
  To: 7449-done

Version: 24.4

Tassilo Horn wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
>> I suggest just removing this stuff from emacsbug.el, since the debbugs
>> package in GNU ELPA provides many, many more features.
[...]
> I agree.  I've just hacked it together to have something to query the
> bug database initially, but in the meantime it has been totally
> superseeded by debbugs.el.

Removed.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-11-10 23:20 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.5.1290257071.20963.bug-gnu-emacs@gnu.org>
2010-11-20 14:19 ` bug#7449: 24.0.50; Problems with the bug-querying mechanism Tassilo Horn
2010-11-20 15:27   ` Michael Albinus
2010-11-20 17:02     ` Tassilo Horn
2010-11-20 12:29       ` Eli Zaretskii
2010-11-23 19:44         ` Glenn Morris
2010-11-24 12:21           ` Alex Harsanyi
2012-11-08  0:20             ` Glenn Morris
2012-11-08  7:29               ` Tassilo Horn
2012-11-10 23:20                 ` Glenn Morris

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).