help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compi


From: Emanuel Berg
Subject: Re: tabs, and runoff whitespace (was; Re: replace-regexp, the byte-compiler, docstrings, and suggestions)
Date: Sat, 15 Nov 2014 20:14:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]