On tabs and spaces

On tabs and spaces

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

Given that `.dir-locals.el' sets `indent-tabs-mode' to nil, does that mean
we prefer spaces for indentation everywhere?
And, if so, would it be acceptable to push a commit that simply converts a
file from tabs to spaces?

[-- Attachment #2: Type: text/html, Size: 257 bytes --]

Re: On tabs and spaces

[Dmitry Gutov]

On 01/15/2015 02:15 AM, Artur Malabarba wrote:
> Given that `.dir-locals.el' sets `indent-tabs-mode' to nil,

Which one?

> does that
> mean we prefer spaces for indentation everywhere?
> And, if so, would it be acceptable to push a commit that simply converts
> a file from tabs to spaces?

Nope. As per previous discussions, you're only really allowed to 
fix/change indentation in the places you make other, meaningful changes to.

Mostly so that 'git blame' returns meaningful results (it has a -w 
option, but that makes it even slower).

Re: On tabs and spaces

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

2015-01-14 21:22 GMT-02:00 Dmitry Gutov <dgutov@yandex.ru>:

> On 01/15/2015 02:15 AM, Artur Malabarba wrote:
>
>> Given that `.dir-locals.el' sets `indent-tabs-mode' to nil,
>>
>
> Which one?
>

None, I must have been delusional. Sorry about this.


>
>  does that
>> mean we prefer spaces for indentation everywhere?
>> And, if so, would it be acceptable to push a commit that simply converts
>> a file from tabs to spaces?
>>
>
> Nope. As per previous discussions, you're only really allowed to
> fix/change indentation in the places you make other, meaningful changes to.
>
> Mostly so that 'git blame' returns meaningful results (it has a -w option,
> but that makes it even slower).
>

Alright. Thanks for answering.

[-- Attachment #2: Type: text/html, Size: 1546 bytes --]

Re: On tabs and spaces

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/15/2015 02:15 AM, Artur Malabarba wrote:
>> Given that `.dir-locals.el' sets `indent-tabs-mode' to nil,
>
> Which one?
>
>> does that
>> mean we prefer spaces for indentation everywhere?
>> And, if so, would it be acceptable to push a commit that simply converts
>> a file from tabs to spaces?
>
> Nope. As per previous discussions, you're only really allowed to
> fix/change indentation in the places you make other, meaningful
> changes to.
>
> Mostly so that 'git blame' returns meaningful results (it has a -w 
> option, but that makes it even slower).

git blame does not spend that much of its time diffing.  Even if the
difference between plain and -w has become larger with Git 2.1+ (simply
because it wastes vastly less time with other endeavors), the bulk of
the run time is likely spent in unpacking files from the repository
rather than comparing them.

If you use a Git version older than 2.1, upgrading might make sense just
because of git blame performance.  The difference is quite noticeable.

-- 
David Kastrup

Re: On tabs and spaces

[Dmitry Gutov]

On 01/15/2015 12:57 PM, David Kastrup wrote:

> git blame does not spend that much of its time diffing.  Even if the
> difference between plain and -w has become larger with Git 2.1+ (simply
> because it wastes vastly less time with other endeavors), the bulk of
> the run time is likely spent in unpacking files from the repository
> rather than comparing them.

Would you consider this kind of difference of no consequence?

$ time git blame src/xdisp.c >/dev/null

real	0m11.875s
user	0m10.753s
sys	0m0.583s
$ time git blame -w src/xdisp.c >/dev/null

real	0m17.127s
user	0m16.779s
sys	0m0.356s

> If you use a Git version older than 2.1

2.1.0 here.

But anyway, I distinctly remember the performance of blaming being one 
of the reasons why we shouldn't do whitespace-cleaning across the 
repository.

Re: On tabs and spaces

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/15/2015 12:57 PM, David Kastrup wrote:
>
>> git blame does not spend that much of its time diffing.  Even if the
>> difference between plain and -w has become larger with Git 2.1+ (simply
>> because it wastes vastly less time with other endeavors), the bulk of
>> the run time is likely spent in unpacking files from the repository
>> rather than comparing them.
>
> Would you consider this kind of difference of no consequence?
>
> $ time git blame src/xdisp.c >/dev/null
>
> real	0m11.875s
> user	0m10.753s
> sys	0m0.583s
> $ time git blame -w src/xdisp.c >/dev/null
>
> real	0m17.127s
> user	0m16.779s
> sys	0m0.356s

Once you factor the time of C-x v g into the equation, the 5.5s of
difference are not all that impressive.  On my computer, previous to
version 2.1 we were talking about about 5 _minutes_ of runtime.

> But anyway, I distinctly remember the performance of blaming being one
> of the reasons why we shouldn't do whitespace-cleaning across the
> repository.

I don't think it was as much the performance rather than the
_convenience_ or knowledge.  Most people call git blame without -w at
first, and sometimes they don't even know about the option.  Emacs
doesn't use -w by default when doing C-x v g either IIRC.  Getting it in
there is somewhat cumbersome.

-- 
David Kastrup

Re: On tabs and spaces

[Dmitry Gutov]

On 01/15/2015 01:26 PM, David Kastrup wrote:

> Once you factor the time of C-x v g into the equation, the 5.5s of
> difference are not all that impressive.  On my computer, previous to
> version 2.1 we were talking about about 5 _minutes_ of runtime.

Still inconvenient, though. And maybe we also care about the developers 
with older versions of Git, for now.

The improvement is impressive, to be sure.

> Emacs
> doesn't use -w by default when doing C-x v g either IIRC.  Getting it in
> there is somewhat cumbersome.

Using it by default would be a trivial change. And with 
http://debbugs.gnu.org/17945, vc-annotate will be more customizable.

Re: On tabs and spaces

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/15/2015 01:26 PM, David Kastrup wrote:
>
>> Once you factor the time of C-x v g into the equation, the 5.5s of
>> difference are not all that impressive.  On my computer, previous to
>> version 2.1 we were talking about about 5 _minutes_ of runtime.
>
> Still inconvenient, though. And maybe we also care about the
> developers with older versions of Git, for now.

The developers with older versions of Git are much less likely to even
notice the difference since the older versions spend the bulk of the
runtime elsewhere.  So the 5.5s of difference are likely still about
5.5s of difference for the old versions.

> The improvement is impressive, to be sure.
>
>> Emacs
>> doesn't use -w by default when doing C-x v g either IIRC.  Getting it in
>> there is somewhat cumbersome.
>
> Using it by default would be a trivial change.

But not likely appropriate for some applications, and not likely matched
by the behavior of other version control systems in VC.  Still, it's a
bit too far out of reach from inside Emacs.

> And with http://debbugs.gnu.org/17945, vc-annotate will be more
> customizable.

Not yet looked at it.

-- 
David Kastrup

Re: On tabs and spaces

[Stephen Leake]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/15/2015 02:15 AM, Artur Malabarba wrote:
>> Given that `.dir-locals.el' sets `indent-tabs-mode' to nil,
>
> Which one?
>
>> does that
>> mean we prefer spaces for indentation everywhere?
>> And, if so, would it be acceptable to push a commit that simply converts
>> a file from tabs to spaces?
>
> Nope. As per previous discussions, 

It's much better to refer to current documents than previous
discussions; this is precisely what /CONTRIBUTE is for.

However, there is no discussion of tab/space in there yet; perhaps
someone should add it.

-- 
-- Stephe