* 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 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 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).