From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#32643: 26; minor-mode variables Date: Sun, 9 Sep 2018 15:09:55 -0700 (PDT) Message-ID: References: <3ce888af-aa04-4dd2-99b5-0882e37024f3@default> <494224f1-815f-4fb4-a779-75e243b519f0@default> <87zhwsg2s5.fsf@gmail.com> <54558a99-f16d-41d4-ada4-02b4e598f426@default> <87worufm2e.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1536530949 13031 195.159.176.226 (9 Sep 2018 22:09:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2018 22:09:09 +0000 (UTC) Cc: rms@gnu.org, 32643@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 10 00:09:04 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fz7t9-0003It-V0 for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Sep 2018 00:09:04 +0200 Original-Received: from localhost ([::1]:48879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fz7vG-00040f-1b for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2018 18:11:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fz7v7-00040N-Tg for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 18:11:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fz7v4-0006r7-Ie for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 18:11:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46535) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fz7v4-0006qx-F6 for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 18:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fz7v4-0006zI-0u for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 18:11: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, 09 Sep 2018 22:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32643 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32643-submit@debbugs.gnu.org id=B32643.153653101326801 (code B ref 32643); Sun, 09 Sep 2018 22:11:01 +0000 Original-Received: (at 32643) by debbugs.gnu.org; 9 Sep 2018 22:10:13 +0000 Original-Received: from localhost ([127.0.0.1]:51553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fz7uG-0006yC-II for submit@debbugs.gnu.org; Sun, 09 Sep 2018 18:10:12 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:39822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fz7uE-0006xw-Ig for 32643@debbugs.gnu.org; Sun, 09 Sep 2018 18:10:11 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w89MA4C9002317; Sun, 9 Sep 2018 22:10:04 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=eYjS/uJG0Aye0w0Uh9JckPBUwpxmf4wMG8vushey1qI=; b=JcyNOvwQPPiw5nPRHdSbmxUipDaxwpo/bqaGImUeS6eHacrB4agZspJNEif0nj2JJ7xV V6kaxXdmHz6VOy3FA7ILqcFxNSPPP+EayWFz+GQbd7zA8RJ26bNuFIlnCBTt8ImAwmnx soMtlYPt4UeJ0CKUx/vwtCDU4DhO2+YVRJxxZfaAc4E+JvWq0E/6J7F3fxGYwLxu9uhT 9JRVMi/+DWTnugonE2fIRT6GAjUp8k+YbPweJZzxsResvdEDptVyeynl+DPU31DseKZ0 q9nMtxqFrK+wpdy/GdDbF/3adQrkud2Uwyw++nYqdbc6pjGHHreI+gpa2wRHvBouALIO yA== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2mc72qavth-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 09 Sep 2018 22:10:04 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w89M9vO5011181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 9 Sep 2018 22:09:58 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w89M9ur3023268; Sun, 9 Sep 2018 22:09:56 GMT In-Reply-To: <87worufm2e.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4735.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9011 signatures=668708 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 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-1807170000 definitions=main-1809090242 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: 208.118.235.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:150171 Archived-At: > >> I don't think the Elisp manual needs to fill in for user's common sens= e > >> by telling them they are free to break conventions if it makes sense t= o > >> do so. The fact that it's a "convention" and not a "requirement" shou= ld > >> be enough. > > > > It's not about users being free to break the convention - that's of > > course the case, for all Emacs conventions. It's about having some > > idea (see above) of when it might "make sense to do so". > > > > That users are free to not follow an Elisp coding convention is > > something different from whether and how much the distributed Emacs > > Lisp code should do so. The bug report is not about whether some user > > code should follow the convention >=20 > Okay, so I don't think the Emacs manual needs to fill in for user's > common sense by telling them that Emacs breaks conventions if it > makes sense to do so. The fact that it's a "convention" and not a > "requirement" should be enough. Why should someone assume that a given (distributed Emacs code) departure from a convention is intended and not just a "historical accident" or a bug for some other reason? Why shouldn't they wonder, in the absence of any info, why this or that mode has no variable? Saying that such a user just lacks common sense seems a bit insulting, no? Departure from a promoted convention puts the convention in doubt, at least for the scope of that particular departure. And in the case of `auto-fill-mode' it's not straightforward for a user (at least this user, and apparently Eli also) to tell whether the convention was not followed for a good reason, a bad reason, or no reason (accident). For Eli it was just a historical accident (probably). And what for you should have been a matter of "looking at the source for 5 minutes" was guessed by Eli to amount to a "non-trivial amount of work". I admit that I didn't try to figure out why there was no such variable by digging into the implementation. I thought it was enough to raise the question of non-respect of the convention. And yes, it was a _question_ - from the outset: It doesn't say why some do and some don't. Why doesn't it?=20 What's the answer to that question? For example, why doesn't variable `auto-fill-mode' exist? Shouldn't all minor modes have a variable? Which ones should? Those questions occurred to me when reading the manual. I think they might occur to some other readers too. So far I 've learned, since asking that, that one reason might be the use of `:variable' - though it's still not clear to me why that should preclude also having and syncing a normal mode variable. Thank you for pointing out the use of `:variable'. Other than that reason, it's been said that some modes don't have variables probably just due to historical accident. Both of those pieces of info are useful (to me, at least). > > - you twisted that around. >=20 > Did I?=20 I think you did. But I didn't mean that you were trying to do something nasty. I figured you did that by misunderstanding. The report is about whether and how much the distributed Lisp code should follow its convention. You replied saying that the manual doesn't need to tell users that they are free not to follow conventions. That wasn't the point. I never asked that the manual tell users they are free not to follow conventions. It's not about users following convention; it's about Emacs doing so. Would it help users for the manual to say that due to historical accident some modes don't have variables? I think it might, but I wouldn't insist on adding that. Would it help to say something about alternative mode variables and `:variable'? I think it would, but probably only in the Elisp manual. Would it help to come up with an easy way to sync a mode variable with an alternative (e.g. `:variable') variable? I think it might, but I don't have code for that. > From my end, it looks like you had some idle question about the > implementation of auto-fill-mode, and instead of looking at the source > for 5 minutes, you sent a long and rambling bug report. What's your aim, there? I didn't have an idle question about implementation. As a user I felt that (as Andreas seconded) the mode variable can be a useful "way to check if the mode is on". That's how I discovered that there was no standard variable for `auto-fill-mode': `C-h v'. The report is not about that particular variable, though I did (and still do) wonder whether it might be handled better. I thought that was clear from the outset. I hope it's clear now. As for the "long and rambling bug report": the report is 11 short lines, not counting text from the manuals. Sorry if it took too much of your time. Perhaps you'll prefer to skip my reports from now on. That would be unfortunate for me (and maybe for Emacs), as your attention has consistently been helpful (including for this report). > Then, you got 3 responses, none of which exactly matched > what you were trying to say.=20 No idea what you are trying to say there, by matching etc. Anyway, I believe I received only one response (from RMS), to which I replied. Then there were replies to that reply, and so on. Altogether there were 9 replies to my mails, and I wrote 7 replies (now 8) plus the report. > You respond with more rambling, argumentation, and > accusation. I don't think so. But I did present and reply to arguments. > Given your posting history, am I surprised that you rudely abuse > the bug list in this way? No. But I'm not happy about it either. Sorry you feel that way. Please point out what you think was rude, abusive, and accusative on my part. I hope to avoid prompting such a response in the future. Thanks.