unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* On tabs and spaces
@ 2015-01-14 23:15 Artur Malabarba
  2015-01-14 23:22 ` Dmitry Gutov
  0 siblings, 1 reply; 9+ messages in thread
From: Artur Malabarba @ 2015-01-14 23:15 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-14 23:15 On tabs and spaces Artur Malabarba
@ 2015-01-14 23:22 ` Dmitry Gutov
  2015-01-15  1:01   ` Artur Malabarba
                     ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Dmitry Gutov @ 2015-01-14 23:22 UTC (permalink / raw)
  To: bruce.connor.am, emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-14 23:22 ` Dmitry Gutov
@ 2015-01-15  1:01   ` Artur Malabarba
  2015-01-15  9:57   ` David Kastrup
  2015-01-16  7:23   ` Stephen Leake
  2 siblings, 0 replies; 9+ messages in thread
From: Artur Malabarba @ 2015-01-15  1:01 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-14 23:22 ` Dmitry Gutov
  2015-01-15  1:01   ` Artur Malabarba
@ 2015-01-15  9:57   ` David Kastrup
  2015-01-15 10:17     ` Dmitry Gutov
  2015-01-16  7:23   ` Stephen Leake
  2 siblings, 1 reply; 9+ messages in thread
From: David Kastrup @ 2015-01-15  9:57 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: bruce.connor.am, emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-15  9:57   ` David Kastrup
@ 2015-01-15 10:17     ` Dmitry Gutov
  2015-01-15 10:26       ` David Kastrup
  0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Gutov @ 2015-01-15 10:17 UTC (permalink / raw)
  To: David Kastrup; +Cc: bruce.connor.am, emacs-devel

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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-15 10:17     ` Dmitry Gutov
@ 2015-01-15 10:26       ` David Kastrup
  2015-01-15 10:43         ` Dmitry Gutov
  0 siblings, 1 reply; 9+ messages in thread
From: David Kastrup @ 2015-01-15 10:26 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: bruce.connor.am, emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-15 10:26       ` David Kastrup
@ 2015-01-15 10:43         ` Dmitry Gutov
  2015-01-15 11:42           ` David Kastrup
  0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Gutov @ 2015-01-15 10:43 UTC (permalink / raw)
  To: David Kastrup; +Cc: bruce.connor.am, emacs-devel

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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-15 10:43         ` Dmitry Gutov
@ 2015-01-15 11:42           ` David Kastrup
  0 siblings, 0 replies; 9+ messages in thread
From: David Kastrup @ 2015-01-15 11:42 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: bruce.connor.am, emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: On tabs and spaces
  2015-01-14 23:22 ` Dmitry Gutov
  2015-01-15  1:01   ` Artur Malabarba
  2015-01-15  9:57   ` David Kastrup
@ 2015-01-16  7:23   ` Stephen Leake
  2 siblings, 0 replies; 9+ messages in thread
From: Stephen Leake @ 2015-01-16  7:23 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-01-16  7:23 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-14 23:15 On tabs and spaces Artur Malabarba
2015-01-14 23:22 ` Dmitry Gutov
2015-01-15  1:01   ` Artur Malabarba
2015-01-15  9:57   ` David Kastrup
2015-01-15 10:17     ` Dmitry Gutov
2015-01-15 10:26       ` David Kastrup
2015-01-15 10:43         ` Dmitry Gutov
2015-01-15 11:42           ` David Kastrup
2015-01-16  7:23   ` Stephen Leake

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).