From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M- Date: Sun, 7 Jul 2019 08:34:42 -0700 (PDT) Message-ID: <9551e332-3baf-49d0-a6ff-4b2432457d5d@default> References: <584510D2C7DE47CBAE19B5058B21B51C@us.oracle.com> <87eh3ba7s9.fsf@building.gnus.org> <877fhuej87.fsf@gnus.org> <87bn4t7ih6.fsf@gnus.org> <2493efa4-e079-446c-8926-f7ee14c04ec9@default> <87eg9oa7kp.fsf@gnus.org> <6b5e4737-edb3-4f0c-b4e7-252330d3436e@default> <8736ji3vgs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="14534"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 12535@debbugs.gnu.org, Lars Ingebrigtsen To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 07 17:36:12 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1hk9D2-0003eF-1u for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jul 2019 17:36:12 +0200 Original-Received: from localhost ([::1]:35930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hk9D0-0002yy-Vw for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jul 2019 11:36:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60365) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hk9Cv-0002yl-Cr for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 11:36:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hk9Cs-0006vv-TQ for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 11:36:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48508) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hk9Cs-0006vZ-Ot for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 11:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hk9Cs-0003nL-HT for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2019 11:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jul 2019 15:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12535 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12535-submit@debbugs.gnu.org id=B12535.156251370214488 (code B ref 12535); Sun, 07 Jul 2019 15:36:02 +0000 Original-Received: (at 12535) by debbugs.gnu.org; 7 Jul 2019 15:35:02 +0000 Original-Received: from localhost ([127.0.0.1]:57329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hk9Bt-0003lW-N0 for submit@debbugs.gnu.org; Sun, 07 Jul 2019 11:35:02 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:43418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hk9Br-0003lA-3j for 12535@debbugs.gnu.org; Sun, 07 Jul 2019 11:34:59 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x67FY25K064948; Sun, 7 Jul 2019 15:34:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=XPG3y2bJtNchfF+uwO6zh22dEzOhxK0nOeQxTMJO40A=; b=XdzQt5e5E/eTIAhoiI0KuTCYuxd+huFZyJ3J1CuV1S+U6/Bj0uApzJhtXz0z8WugmQGH Wc8BSgQFJkfBLCm4wBbzBIrLJMR/I4mKg09KjxO6OcLBcwFPUY7jEt2nzw8gBOq7n5DL USlPilzMx3cxTXwdK4xI79FE3bofUqUv1gUJSYb9YjenlZeELAM5jTMsh4/1QxArZTkc zGsafpQamQwjTOUWxDUq2dBVxlR9ZI3yyHy4c4kgqCvAEipX+GyLLn4dd2e6PLfR5TiT UteHfhX9CB65qk2cuQQ6p+c32I49sgc6HehX3VfYkMDldFwtRnwKzD8+vkjRLalMg1wh mQ== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2tjm9qaxmg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 07 Jul 2019 15:34:51 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x67FXW1R063386; Sun, 7 Jul 2019 15:34:50 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2tjkf1v9yf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 07 Jul 2019 15:34:50 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x67FYh2p031503; Sun, 7 Jul 2019 15:34:44 GMT In-Reply-To: <8736ji3vgs.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4861.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9311 signatures=668688 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907070215 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9311 signatures=668688 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907070215 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162288 Archived-At: > > I really cannot imagine why that 6-char fix would > > not have been applied sometime in the 7 years that > > have elapsed since the report - let alone why the > > bug would now be closed as "wontfix". >=20 > I think the reason is that when you say things like this: >=20 > > Can you submit a new patch, preferably tested? >=20 > Sorry; I really don't have the time now. But I > think that all of the relevant info has been > provided, so you should be able to DTRT. >=20 > You unavoidably send the message that your time is more important than > the person handling your bug report (to be clear, it's not the "I'm busy > right now" part alone, but the combination of "I'm busy, you do it" > that's the problem). The "YOU should be able" was not, and is not, directed at any particular person. It's not at all about "the person handling [my] bug report". Not that I don't take into consideration someone handling the report, but that "you" is not about that person or any other. It's a statement that the bug description - and even a possible solution - is complete and clear (IMHO), and Someone(TM) _could_ easily apply it. And it questions why the bug should be _closed_, if it has not yet been fixed. It's not at all about my time vs someone else's time. We each contribute the way we can and the way we want to. I contributed a bug report, and a possible fix, and I then contributed time and effort trying to clarify and better communicate the problem and proposed fix. The possible fix is an "extra", a "nice-to-have", a "freebie". - it's fine if how I think the problem might be fixed is ignored in favor of a better solution. What's important is the bug report - recording the bug so we're aware of it, and so it might be fixed someday. We are _all_ volunteers. Submitting a bug report is volunteer work, intended to help Emacs. No one should take a bug report as a commandment to work or as a burden. Bug reports are good, not bad. And they are for us all; they are not personal directives for anyone to do anything. > > Just the bug report, regardless of whether > > any freebie suggested solution code was also > > provided (which it was) [...] >=20 > Similarly, use of the word "freebie" implies that you don't consider the > time spent reading and checking posted patches for mistakes as important. No, it does not imply that at all. See above. It stresses that what's important in the contribution I chose to make is the bug report. _If_ someone wants to _also_ consider the fix I suggested, fine; if not, another fix would be fine. There is nothing in what I said that suggests that I consider the work of actually fixing the bug to be unimportant or trivial. Relative to other bug fixes I do think the suggested fix is pretty simple. But I know that it takes time to apply and test even a simple fix. Just because I don't work on that myself doesn't mean I trivialize that work if done by someone else. Quite the contrary. If a school boy spends extra time reading poetry and neglects his math studies, does that mean he thinks math is unimportant or trivial? No, that doesn't follow. He just prefers reading poetry. The use of "freebie" emphasizes that I don't care whether it gets fixed using my fix suggestion - that was just a suggestion, aimed to help. If someone has a better fix then that's even better. The point is that there is a _bug_, described. It can be fixed, and I think that can be done easily. Whether someone else has the time or will to do that is for them to decide. When a user submits a bug report it's OK to ask if they also want to provide a patch. It's not so OK to close the bug just because they don't decline to do that. In this case, the code change for the suggested fix is truly trivial. Requiring a patch and testing from the submitter is over the top, IMO. If that's the requirement - that the bug won't be fixed unless the reporter submits a tested patch - so be it. Note the difference: The fact that the bug _hasn't_ been fixed _because_ of that is a bit surprising to me. But _closing_ the bug because of that, and because it hasn't yet been fixed, is not good (IMHO). > If bug reports were answered by utility-maximising robots this wouldn't > matter. However, we have only squishy humans available for bug report > handling. Therefore, please try to think about the human on the > receiving end before you post something. We are _all_ squishy humans, including users who volunteer bug reports and possible fixes, however imperfect or unclear the report or unwise or imperfect the fix. This reporter does _not_ expect that robots read Emacs bug reports and fix bugs. Nor do I expect bugs to be closed robotically. I'm grateful that other squishy humans read bug reports, try to understand them, and sometimes find time to fix them. I've always been so.=20 Did I hound this thread with demands that this bug be fixed - let alone demands that my suggested fix be applied? I don't think so. How many years have passed? How many times did I ping or insist that it be fixed? If no one wants to fix it, fine - but too bad (for us all). I don't blame (and have not blamed) anyone for not volunteering to fix it. I expressed surprise, years later, that it hasn't been fixed and, especially, that it's being closed. Personally, I don't think such a bug (or any bug that is recognized as such and is not deemed unfeasible to fix) should be closed. But I know that others can feel differently. In some organizations (e.g. companies) there are members whose job it is to reduce the set of outstanding bugs. I don't see why a user-run volunteer group would want to close bugs (recognized as bugs and as feasible to fix) just because time has passed or there is currently no one to work on fixing them. No one gets a raise from reducing the bug count. But again, I know that others can see this differently.