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

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

[Emanuel Berg]

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*

But speaking even more broadly, why would anyone want
whitespace after the "end" of lines, or whitespace
after the "end" of files, or for that matter tabs
instead of whitespace?

I know tabs are needed in Makefiles but I suspect that
to be something implementation-related. I don't think
it would be impossible to program make to not have
that requirement. Perhaps someone already tried or
even succeeded...

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?

-- 
underground experts united

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

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

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> I'm sure you'll soon have to work with others, we
> all do.

Really? You think so?! <3

;)

> 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).

Yes, I understood the first time :)

> 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.

No, it is not.

> 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.

Cool that the veterans are still around.

How about a forth idea: the compiler will somehow
determine if the changes in whitespace are "only"
cosmetical - "only" within quotation marks because
that matters to the programmer, it can matter a lot
actually, and if he is happy the way it looks he'll
write better code. Not only will the VC program not
report changes in whitespace, it won't do anything
about it - that way every programmer can have their
own indentation!

-- 
underground experts united