From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Thorpe Newsgroups: gmane.emacs.help Subject: Re: tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions) Date: Thu, 13 Nov 2014 01:17:40 +0000 Message-ID: <87d28r3nm3.fsf@robertthorpeconsulting.com> References: <87fvdvdge7.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415841497 12120 80.91.229.3 (13 Nov 2014 01:18:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 01:18:17 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Emanuel Berg Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 13 02:18:09 2014 Return-path: Envelope-to: geh-help-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 1Xoj2z-0006Z2-Sy for geh-help-gnu-emacs@m.gmane.org; Thu, 13 Nov 2014 02:18:06 +0100 Original-Received: from localhost ([::1]:57404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoj2z-0006BY-82 for geh-help-gnu-emacs@m.gmane.org; Wed, 12 Nov 2014 20:18:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoj2i-0006BK-Fz for help-gnu-emacs@gnu.org; Wed, 12 Nov 2014 20:17:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xoj2c-0004ly-Du for help-gnu-emacs@gnu.org; Wed, 12 Nov 2014 20:17:48 -0500 Original-Received: from outbound-smtp04.blacknight.com ([81.17.249.35]:44956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoj2c-0004lr-7k for help-gnu-emacs@gnu.org; Wed, 12 Nov 2014 20:17:42 -0500 Original-Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp04.blacknight.com (Postfix) with ESMTP id B465498987 for ; Thu, 13 Nov 2014 01:14:45 +0000 (UTC) Original-Received: (qmail 22305 invoked from network); 13 Nov 2014 01:17:41 -0000 Original-Received: from unknown (HELO RTLaptop) (rt@robertthorpeconsulting.com@[109.78.214.179]) by 81.17.254.9 with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 13 Nov 2014 01:17:41 -0000 In-Reply-To: <87fvdvdge7.fsf@debian.uxu> (message from Emanuel Berg on Fri, 07 Nov 2014 01:05:20 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 81.17.249.35 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100904 Archived-At: Emanuel Berg writes: > Robert Thorpe writes: > >> In my opinion it's better to work this way: * Write >> a script to remove all of the tabs in all your >> personal file. Do that as a one-off operation * Set >> indent-tabs-mode so Emacs never generates new tabs. >> * Don't untab files before saving them. >> >> The advantage of this is that your own stuff will >> always be tab-clean but you can still cooperate with >> others who use VC. > > Good general point, but as for me I didn't do anything > with other people since my first years at the > university. It sure is lonesome at the top... *sob* I'm sure you'll soon have to work with others, we all do. > But speaking even more broadly, why would anyone want > whitespace after the "end" of lines, or whitespace > after the "end" of files Generally, they wouldn't. But, removing it causes problems for version-control systems. It marks lines as being changed, when in reality nothing of significance was changed. It's best to require everyone who makes a change to remove extraneous whitespace. But, once code is in the repository it's best not to remove extraneous whitespace because it makes using blame/annotate more difficult. (Git has a switch to prevent this problem, other systems don't. Even Git just fake it, it still versions the change, it just skips past it when presenting data to the user). >, or for that matter tabs > instead of whitespace? I know one advocate of tabs, I'll explain it the way he does.... He says that a tab means "indent here". It doesn't prescribe a particular number of spaces to indent by. Instead it allows the programmer to decide how many spaces he wants to see for an indentation level by configuring his editor. I disagree with this view, but it isn't obviously incorrect. > If it doesn't make sense to have, why should the guy > who removes it adapt to the people who stick with it, > and not the other way around? The issue is more about not creating phantom changes in version control. Generally every project has a convention on tabs-versus-spaces, which should be followed. The group that should "adapt" to the other are the group that aren't following the project's convention. There are three possibilities not two. One is to remove all tabs and replace them with spaces as you advocate. That creates phantom changes. The second is to replace spaces with tabs, that also creates phantom changes. The third is to live with some mistakes and make no whitespace changes. I'm advocating the third. If you read emacs-devel you'll see that Eric Raymond has converted the Emacs version-control repository from Bazaar to Git. He's done this using a tool he wrote called reposurgeon which can make changes to version-controlled files that don't show up in version control history. Perhaps the long term answer is something like this. To fix all the whitespace in a way that makes the records show it was never wrong. BR, Robert Thorpe