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: Thu, 6 Sep 2018 17:10:09 -0700 (PDT) Message-ID: References: <<<3ce888af-aa04-4dd2-99b5-0882e37024f3@default> >> <<<494224f1-815f-4fb4-a779-75e243b519f0@default>>> <<<83sh2mwv8w.fsf@gnu.org>>> <<488f04e4-8389-459b-b3c7-603e48bed452@default>> <<83lg8ewk2c.fsf@gnu.org>> 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 1536278953 18493 195.159.176.226 (7 Sep 2018 00:09:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Sep 2018 00:09:13 +0000 (UTC) Cc: rms@gnu.org, 32643@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 07 02:09:09 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 1fy4Kh-0004ho-M4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Sep 2018 02:09:07 +0200 Original-Received: from localhost ([::1]:35906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fy4Mn-0007RQ-Ro for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Sep 2018 20:11:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fy4Mh-0007RI-E1 for bug-gnu-emacs@gnu.org; Thu, 06 Sep 2018 20:11:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fy4Mb-0000bz-1U for bug-gnu-emacs@gnu.org; Thu, 06 Sep 2018 20:11:11 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43542) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fy4MY-0000My-63 for bug-gnu-emacs@gnu.org; Thu, 06 Sep 2018 20:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fy4MX-00056q-U2 for bug-gnu-emacs@gnu.org; Thu, 06 Sep 2018 20:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Sep 2018 00: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.153627902119590 (code B ref 32643); Fri, 07 Sep 2018 00:11:01 +0000 Original-Received: (at 32643) by debbugs.gnu.org; 7 Sep 2018 00:10:21 +0000 Original-Received: from localhost ([127.0.0.1]:48560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fy4Ls-00055u-H9 for submit@debbugs.gnu.org; Thu, 06 Sep 2018 20:10:20 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:57586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fy4Lr-00055f-HA for 32643@debbugs.gnu.org; Thu, 06 Sep 2018 20:10:19 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w87092ee007364; Fri, 7 Sep 2018 00:10:13 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=bn5eoQPXKj9ADUBheDWB4Ajty+uhaV5pdifwJ09jC4U=; b=5lr5r7d1gAlWskGxnYgcxOZp/BHLu0Mo4dp38rUQK+Gx93A7hs45f7VAavsper/cY4zE 5nR8Hp/vOMHWyYds0wDVGiE3IDf7DhkIhBSyyJjWIC2rBVSKC6/449o1mza4cs9JuU7Q loRmMOoGI24IqzlRZUoAAn5QTAkopVw6k8n2c7y2Ruw46TnP7xoMVeELXed7p5ifL10x EMLVi5UDejTR8pvBc+9n29miheF+z2vjmFdwKmND35Q2Ps2BxlIX3QaPnUIp3oRiw8OE M+4YKKJtBD514YxzwysGClOQiSSsN5e/4/85pujMMYjGxJSueNRxD+EIYJABkSKfrFiy 6A== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2m7j6ty5eh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 07 Sep 2018 00:10:13 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w870ABca032200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Sep 2018 00:10:11 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w870AA2j021842; Fri, 7 Sep 2018 00:10:10 GMT In-Reply-To: <<83lg8ewk2c.fsf@gnu.org>> 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=9008 signatures=668708 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-1807170000 definitions=main-1809070001 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:150101 Archived-At: > > > Most probably, historical accidents. But even finding that out is a > > > non-trivial amount of work. > > > > `auto-fill-mode' has already been identified. Let this bug report serve > > (at least) to ask that Emacs set an `auto-fill-mode' mode variable. >=20 > You've changed the subject by eliding the context. The above was an > answer to your question why some modes have variables while others > don't. Yes, it was. And my redaction of the text just before it didn't change anything in that regard. If you think it did, please elaborate. > As for auto-fill-mode, can you tell why it is important to have a > variable there? What cannot you do without that variable? No, according to the convention the shoe is on the other foot. Why should it not have a variable? That's the convention. Why should `auto-fill-mode' be an exception? The fact that there are some exceptions is no argument for why `a-f-m' should be one of them. Plus, you're setting a high bar: you ask what is _impossible to do_ without the variable. If you insist on putting the shoe on my foot then the only somewhat reasonable question is how might it be useful to have the variable - not what is impossible (!) to do without it. Anyway, if you insist on asking for a possible use... One answer is the same as for any other variable: You can do `C-h v auto-fill-mode' to check whether it is on. Minor modes do not necessarily have mode-line lighters. And even in a customized mode-line that shows no lighters that will tell you whether the mode is on. Again, why would you _not_ want to have such a variable? > > > I think the manual already does what you want, it just doesn't say > > > this is a bug (because it isn't, IMO). > > > > The manual says nothing, AFAICT, that provides guidance about when > > a mode should not or need not have a variable. Based on what it does > > say, each mode "should" have a variable. Is that your point? >=20 > My point is that the manual recommends that there be a variable. No one disagrees that that is the case. > > In that case, perhaps we should remove the text about some existing > > modes not respecting this "should" - especially if that is only by > > historical accident. >=20 > If we remove that, we will have no way to respond to bug reports > requesting that all modes shall have a variable. Huh? Why can't you respond to such a report? Or do you think that the manual stating only that some do and some don't provides an excuse for doing nothing in that regard? That doesn't follow. > > Keeping the text suggests that there is some good reason why some > > modes do not have variables. >=20 > There's no such suggestion, it's just a statement of a fact. Why is that fact stated? Is it really to have a way to respond to bug reports that ask to follow the convention, by saying that the convention doesn't apply to some modes (without saying which or why or...)? That's the only reason you've given, so far.