Re: tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions)

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> 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