From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20322: 25.0.50; indent-tabs-mode should default to nil Date: Fri, 17 Apr 2015 16:14:45 +0300 Message-ID: <55310745.3010601@yandex.ru> References: <861tjn3069.fsf@yandex.ru> <552D20B6.8030005@yandex.ru> <83mw2abul3.fsf@gnu.org> <552D34BC.4090806@yandex.ru> <83h9sibt0q.fsf@gnu.org> <552D7796.2090109@yandex.ru> <83vbgx9xtl.fsf@gnu.org> <55307468.8070307@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1429276548 23292 80.91.229.3 (17 Apr 2015 13:15:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2015 13:15:48 +0000 (UTC) Cc: 20322@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 17 15:15:37 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yj679-0005gS-Bj for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Apr 2015 15:15:23 +0200 Original-Received: from localhost ([::1]:41322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj673-0005u7-FC for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Apr 2015 09:15:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj66t-0005kF-Fd for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2015 09:15:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj66q-0002zx-6w for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2015 09:15:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj66p-0002zi-SP for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2015 09:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yj66p-0001tz-B6 for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2015 09:15:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Apr 2015 13:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20322 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20322-submit@debbugs.gnu.org id=B20322.14292764977279 (code B ref 20322); Fri, 17 Apr 2015 13:15:03 +0000 Original-Received: (at 20322) by debbugs.gnu.org; 17 Apr 2015 13:14:57 +0000 Original-Received: from localhost ([127.0.0.1]:58694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yj66i-0001tH-RX for submit@debbugs.gnu.org; Fri, 17 Apr 2015 09:14:57 -0400 Original-Received: from mail-wg0-f54.google.com ([74.125.82.54]:36062) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yj66g-0001ss-ME for 20322@debbugs.gnu.org; Fri, 17 Apr 2015 09:14:55 -0400 Original-Received: by wgsk9 with SMTP id k9so112702526wgs.3 for <20322@debbugs.gnu.org>; Fri, 17 Apr 2015 06:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iu3E2XJtA+ht7q5Ys9NbyE1fQFReDz6iIje+b5HwfLo=; b=fE72bDmjGsOzO40/ao11M+qzbyAUBpcF8Kpp7K3ak1o2umn7RHDOsAA843eWWiLxkP h8s4X4IZmuXf4TCWc/n+Pbja/jDrqWnYpRk3Qwr3NgesyvUsB8WDsHJbQRnmp6Ok6AqM OLS5ppZeTkWoACX8fbJCQ26KK7VyDd9lOXx2hU4Gqb4/PmBuj1a/BBnqLuQlnFWNoLKN kF5YL0cuqwPmXn1gs6T144lulqTimoExvanCW0wGzPb4cu+2wmuvuFYKHbSzJ/nAS2c0 BXl9QXTr/sV9lP3j0bkAS9kgQayMk3a6MePgtTAsZNZv6+YatrZRu9xk/vYsoGZV3SGU v6Vw== X-Received: by 10.194.110.233 with SMTP id id9mr5939415wjb.136.1429276489087; Fri, 17 Apr 2015 06:14:49 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id i10sm14620867wja.40.2015.04.17.06.14.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2015 06:14:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101622 Archived-At: On 04/17/2015 07:58 AM, Stefan Monnier wrote: > Yup. Adding more mode-specific variables to circumvent the problem is > not a good idea. If add-hook+lambda is considered too cumbersome, we > can wrap it in some function/macro to make it look prettier. Even if a user is fine with writing a lambda or using some new macro, they'd still have to fist discover that a specific mode overrides a given variable during its initialization. AFAIK, a lot of fairly experienced users don't routinely use `find-function'. > I personally find that Custom should grow a way to set the value of > those variables "per mode" or maybe even "per directory". "per directory" sounds like an appropriate addition to the project management functionality, which we'll grow any day now. "per mode" sounds easier, and maybe we can start with defining a programmatic API for that. How about a global variable, using the same format as .dir-locals.el contents? And then have an element at the end of `after-change-major-mode-hook' that would apply these values (or simply hardcode that logic in `run-mode-hooks'). One aspect I'm not clear on is how the modes would add elements to it. There'll probably be a button like "erase customization for this mode" in the Customize interface, but how would it know, and how would it convey to the user, that the variable would revert to the mode-specific value, not the global one?