From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.devel Subject: Re: "If you're still seeing problems, please reopen." [Was: bug#25148:] Date: Thu, 02 Jan 2020 18:45:34 -0500 Message-ID: <87r20hh17l.fsf@md5i.com> References: <20191117113054.49837.qmail@mail.muc.de> <87pnhq7mxg.fsf@gnus.org> <87bltaz9g4.fsf@telefonica.net> <877e3y5r6x.fsf@gnus.org> <0b8f8b31-29aa-1a33-f70d-38bdaeefc6e5@yandex.ru> <87y2we4boo.fsf@gnus.org> <7c8e41f2-23e1-868b-4db9-e4f800675ee2@yandex.ru> <87woacotw1.fsf@web.de> <83zhf7jisj.fsf@gnu.org> <87tv5eegb0.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="268907"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 03 00:46:59 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1inAB8-0017nO-Ht for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2020 00:46:59 +0100 Original-Received: from localhost ([::1]:46866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inAB6-0001ZY-LV for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 18:46:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36627) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inA9p-0000ew-6U for emacs-devel@gnu.org; Thu, 02 Jan 2020 18:45:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1inA9n-0002UM-VJ for emacs-devel@gnu.org; Thu, 02 Jan 2020 18:45:37 -0500 Original-Received: from md5i.com ([75.151.244.229]:40790) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1inA9n-0002QV-LI for emacs-devel@gnu.org; Thu, 02 Jan 2020 18:45:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=md5i.com; s=dkim; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MjFrh4XrKxj50jJijgbVfrEGjPZPh3MyH94ZCCEO8VI=; b=vXngw6mLchz81P6NTqUSDnJQK5 JtIrzrD1Z4TFiNberZyHT9nhA+L0gMtSWHKnIbNqnjlQ3Q45OfNf38FiRYSeU6l4QEINaPFg5j3BK 32Lje10NLIOjehAOFmhAGleAV; Original-Received: from md5i by md5i.com with local (Exim 4.93) (envelope-from ) id 1inA9m-0004p6-GP for emacs-devel@gnu.org; Thu, 02 Jan 2020 18:45:34 -0500 In-Reply-To: <87tv5eegb0.fsf@web.de> (Michael Heerdegen's message of "Thu, 02 Jan 2020 03:35:31 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 75.151.244.229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243879 Archived-At: Michael Heerdegen writes: > Eli Zaretskii writes: > >> How about if we add a bug-reporting-function, to be set by any mode >> that wants to override the default one (which sends email to debbugs)? >> Then report-emacs-bug could be modified to detect the modes active in >> the buffer, and suggest the possible alternatives to the user. I >> think adding to our coding conventions a single variable that in most >> cases doesn't even have to be set will be easier to propagate to the >> few modes which want their own bug-tracking. And users will benefit >> from not having to search high and low for the relevant command. > > Sounds good, yes. But as you describe it, it doesn't cover those cases > where people invoke the command from an unrelated buffer (*scratch* or > so), e.g. because they needed to restart Emacs. Adding some > explanations to the initial text in the bug report buffer of the default > reporting command would thus be good I think. Another possibility is that at some point in the bug reporting process Emacs could query as to which mode is having problems. This could default to the current major mode (if there is a bug reporting function specific to that mode) and could contain generic categories such as "emacs" or "other". If the selected mode has a specific bug-reporting function associated with it, that bug-reporting function could be called instead of the generic function. As a bonus, even with a generic bug report, we might get a possibly useful user-selected mode field. -- Michael Welsh Duggan (md5i@md5i.com)