From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Whitespace cleanup, tab-width and religion. Date: Tue, 02 Jan 2007 10:56:17 +0100 Message-ID: References: <87fybafyis.fsf@lrde.org> <87slfaeh5z.fsf@lrde.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1167731940 6474 80.91.229.12 (2 Jan 2007 09:59:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Jan 2007 09:59:00 +0000 (UTC) Cc: =?utf-8?Q?Micha=C3=ABl?= Cadilhac , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 02 10:58:58 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H1gQ3-0000Wh-El for ged-emacs-devel@m.gmane.org; Tue, 02 Jan 2007 10:58:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H1gQ2-0005wG-17 for ged-emacs-devel@m.gmane.org; Tue, 02 Jan 2007 04:58:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H1gNQ-0004vJ-UG for emacs-devel@gnu.org; Tue, 02 Jan 2007 04:56:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H1gNO-0004s6-CS for emacs-devel@gnu.org; Tue, 02 Jan 2007 04:56:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H1gNN-0004re-EB for emacs-devel@gnu.org; Tue, 02 Jan 2007 04:56:09 -0500 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H1gNL-0000Kz-NL; Tue, 02 Jan 2007 04:56:07 -0500 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepa.post.tele.dk (Postfix) with SMTP id 16AF9FAC030; Tue, 2 Jan 2007 10:56:05 +0100 (CET) Original-To: "Rajesh Vaidheeswarran" In-Reply-To: (Rajesh Vaidheeswarran's message of "Mon\, 1 Jan 2007 13\:55\:51 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:64632 Archived-At: "Rajesh Vaidheeswarran" writes: > As the author of whitespace.el, it was my intent to keep tabs at 8 > characters.=20 I simply don't follow the logic of whitespace.el forcing tabs at a fixed value if the value is customizable in Emacs. If whitespace.el doesn't work correctly with basic Emacs' features, we need to fix it. BTW, after the release, we plan to make tabs even more dynamic than given by tab-width, and in that case, a regexp is most likely inadequate to detect tabs. So a fix would probably make w-i-regexp obsolete. > To be clear, from whitespace.el's point of view, it is not relevant what = the > tab-width is set at. People set tab-widths to whatever they please on the= ir > favorite editors.=20 favorite editor_s_ ? Isn't this an Emacs package? Shouldn't it _primarily_ work seamless with Emacs? If people need code to interoperate with other editors, they probably shouldn't change tab-width -- but in the specific case, Micha=C3=ABl actual= ly need to change tab-width because of interoperability issues! So why make whitespace.el _enforce_ "standards" which are unnecessary at best, and disruptive at worst. > However, there is no way to portably move the definition > of TAB across people and platforms, other than the value of 8 spaces. That > is why this is a religious argument, and that is also why it is documented > as such. I don't see it as religious -- tab-width exists, so it's reality, and there's no need to turn it into a religious issue. >> > >> > Also, putting w-i-regexp in a Local Variable part produces a warning. >> > And I don't really want to force a certain value of this variable but >> > just the amount of spaces it counts. >> > >> >> Sounds like whitespace-indent-regexp should be marked as a safe local >> variable. Unless it is risky somehow ... ?? Do you object that that change? --=20 Kim F. Storm http://www.cua.dk