From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#27639: 25.2; Fix syntax for minor mode enabling in dir locals in manual Date: Tue, 11 Jul 2017 20:32:22 +0300 Message-ID: <83tw2ij2vt.fsf@gnu.org> References: <83wp7fhquh.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1499794953 2017 195.159.176.226 (11 Jul 2017 17:42:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Jul 2017 17:42:33 +0000 (UTC) Cc: 27639@debbugs.gnu.org To: Kaushal Modi Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 11 19:42:30 2017 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 1dUzB8-0000Hg-2U for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Jul 2017 19:42:30 +0200 Original-Received: from localhost ([::1]:47991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUzBD-00023n-Lq for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Jul 2017 13:42:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUz21-0001sM-Dv for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2017 13:33:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUz1y-00023V-6W for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2017 13:33:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59827) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dUz1y-00023E-2B for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2017 13:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dUz1x-00071H-PO for bug-gnu-emacs@gnu.org; Tue, 11 Jul 2017 13:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Jul 2017 17:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27639 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27639-submit@debbugs.gnu.org id=B27639.149979436126953 (code B ref 27639); Tue, 11 Jul 2017 17:33:01 +0000 Original-Received: (at 27639) by debbugs.gnu.org; 11 Jul 2017 17:32:41 +0000 Original-Received: from localhost ([127.0.0.1]:34271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dUz1d-00070f-CB for submit@debbugs.gnu.org; Tue, 11 Jul 2017 13:32:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dUz1b-00070T-8R for 27639@debbugs.gnu.org; Tue, 11 Jul 2017 13:32:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUz1S-000119-Qw for 27639@debbugs.gnu.org; Tue, 11 Jul 2017 13:32:33 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUz1S-00010t-No; Tue, 11 Jul 2017 13:32:30 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2057 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dUz1R-0002IV-8E; Tue, 11 Jul 2017 13:32:30 -0400 In-reply-to: (message from Kaushal Modi on Tue, 11 Jul 2017 16:57:32 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:134437 Archived-At: > From: Kaushal Modi > Date: Tue, 11 Jul 2017 16:57:32 +0000 > Cc: 27639@debbugs.gnu.org > > indent-tabs-mode is the mode variable, so setting it to t is not a > mistake. > > The mistake (as explained in the Reddit post) was setting a 'custom-mode' to t and expecting that that would > rightaway enable that 'custom-mode' minor mode. There's no variable by that name, so it's little surprise that it didn't work. > But why do you think we should only advertise one method, but not the > other? > > From (emacs) Minor Modes > > ===== > Most minor modes also have a "mode variable", with the same name as > the mode command. Its value is non-‘nil’ if the mode is enabled, and > ‘nil’ if it is disabled. In general, you should not try to enable or > disable the mode by changing the value of the mode variable directly in > Lisp; you should run the mode command instead. That's unrelated to file-local variables, IMO. > In any case, as a user, I find it clearer to understand that you must never enable minor modes by just setting > their var; you should call that minor mode fn instead. And I object to the "never" part. This is Emacs: we should teach users to know and understand what they are doing, not follow recipes prepared by others like a kind of cookbook. If the mode variable is a simple variable, and setting it is all that it takes to turn on or off the mode, why should we tell users it's wrong? > Also, if a user uses the (mode . minor) convention instead of (minor-mode . t), they do not have to worry > about declaring them safe. Let them find that out by themselves, and see if they care. Who knows, we might even find a few bugs that way -- perhaps some mode variable should have a safe-local-variable property that we failed to specify. IOW, I think it's wrong to try to save users from themselves. We should provide clear documentation which explains the pros and cons, and then let the users decide based on knowledge, not on blindly following advice that makes some of the methods "magic". OK, that's my opinion. What do others think?