Overriding the value of indent-tabs-mode in Emacs code

Overriding the value of indent-tabs-mode in Emacs code

[Dmitry Gutov]

On 05/25/2016 09:51 AM, Paul Eggert wrote:

>> As an aside, how did you manage to create a patch that's using tabs for
>> indentation, with indent-tabs-mode bound to nil in .dir-locals.el? That's
>> troubling.
>
> I override that setting, as I find it annoying in too many cases. It's
> just a minor annoyance, but there it is.

Using spaces for indentation is somehow annoying? How do you even notice 
that?

Please don't do that, not in Emacs sources, at least.

.dir-locals.el is there for everyone, and if everyone sticks to their 
preference instead, we'll have zero chance of converging on one style.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Paul Eggert]

On 05/25/2016 05:48 AM, Dmitry Gutov wrote:
> Using spaces for indentation is somehow annoying? How do you even 
> notice that? 

I notice it all the time, by running commands like 'git diff' where 
outputs do not line up. Admittedly these annoyances are minor, but the 
advantages of switching sources to all-spaces are also minor, and for me 
the cost of switching to all-spaces outweighs the benefit.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Dmitry Gutov]

On 05/26/2016 12:44 AM, Paul Eggert wrote:

> I notice it all the time, by running commands like 'git diff' where
> outputs do not line up.

I notice that problem all the time as well when someone reformats a 
piece of code to use a different convention.

It's not caused by using spaces for indentation (that would be 
preposterous), but by using different conventions in the same file. And 
as long as some people choose to go against the project-wide convention, 
the problem will never go away.

> Admittedly these annoyances are minor, but the
> advantages of switching sources to all-spaces are also minor, and for me
> the cost of switching to all-spaces outweighs the benefit.

We're not "switching" to all-spaces. Emacs source code doesn't use 
either style consistently, and we've picked the spaces style last time 
the subject was discussed.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Paul Eggert]

On 05/25/2016 03:00 PM, Dmitry Gutov wrote:
>
> It's not caused by using spaces for indentation (that would be 
> preposterous), but by using different conventions in the same file.

In this particular case, the existing code uses tabs for indentation. So 
it is puzzling that you'd be troubled by a patch that sticks with that 
convention. Here, switching to all-spaces would make the patch harder to 
read.

> We're not "switching" to all-spaces.
Yes, that's what I thought.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Dmitry Gutov]

On 05/26/2016 01:11 AM, Paul Eggert wrote:

> In this particular case, the existing code uses tabs for indentation. So
> it is puzzling that you'd be troubled by a patch that sticks with that
> convention. Here, switching to all-spaces would make the patch harder to
> read.

I'm troubled by you overriding the project's convention. If you do it 
here, you must do it in other cases as well.

And the function in question contains both conventions already.

>> We're not "switching" to all-spaces.
> Yes, that's what I thought.

"Switching" implies we've had a single, different convention before.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Paul Eggert]

On 05/25/2016 03:18 PM, Dmitry Gutov wrote:
>
>>> We're not "switching" to all-spaces.
>> Yes, that's what I thought.
>
> "Switching" implies we've had a single, different convention before.
>
>
I didn't intend that implication. What I meant was that we're not 
switching all the Elisp sources to use only spaces to indent. At least, 
that is my understanding. In this particular case, switching to 
all-spaces would have made the patch harder to read. I read a lot of 
patches and perhaps are more sensitive to this issue.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Dmitry Gutov]

On 05/26/2016 01:36 AM, Paul Eggert wrote:

> I didn't intend that implication. What I meant was that we're not
> switching all the Elisp sources to use only spaces to indent. At least,
> that is my understanding.

We do. Gradually. Using .dir-locals.el.

> In this particular case, switching to
> all-spaces would have made the patch harder to read. I read a lot of
> patches and perhaps are more sensitive to this issue.

OK, if that's all you do. I do see people switching from spaces to tabs 
sometimes, and that's a bigger concern.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Michael Heerdegen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> We do. Gradually. Using .dir-locals.el.

Dumb question: why don't we just convert the files to the spaces
convention, if that's the goal anyway?  Doing it gradually patch by
patch (patches that are sometimes harder to read) seems to be quite
troublesome...


Michael.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Dmitry Gutov]

On 05/26/2016 02:24 AM, Michael Heerdegen wrote:

> Dumb question: why don't we just convert the files to the spaces
> convention, if that's the goal anyway?  Doing it gradually patch by
> patch (patches that are sometimes harder to read) seems to be quite
> troublesome...

This way we don't break each affected line's attribution in 'git blame' 
(one can ask it to ignore whitespace changes, but the user has to know 
to do that, and it makes the command considerably slower).

Re: Overriding the value of indent-tabs-mode in Emacs code

[Karl Fogel]

Michael Heerdegen <michael_heerdegen@web.de> writes:
>Dmitry Gutov <dgutov@yandex.ru> writes:
>> We do. Gradually. Using .dir-locals.el.
>
>Dumb question: why don't we just convert the files to the spaces
>convention, if that's the goal anyway?  Doing it gradually patch by
>patch (patches that are sometimes harder to read) seems to be quite
>troublesome...

It might be worth it, but it does cause a "blame shadow" across the whole source tree at that point in history.  That is, when one is using 'git blame' to find out the provenance of certain lines of code, one's view into the past gets obscured by this single revision that touched gazillions of lines of the Emacs source code.

This can be worked around, of course -- you just step back past that special revision and try again -- but it is a bit of inconvenience when one is digging through history.

(Subversion did something like this in 2006: http://svn.apache.org/viewvc?view=revision&revision=858545)

Best regards,
-Karl

Re: Overriding the value of indent-tabs-mode in Emacs code

[Stefan Monnier]

> This way we don't break each affected line's attribution in 'git blame' (one
> can ask it to ignore whitespace changes, but the user has to know to do
> that, and it makes the command considerably slower).

And doing such wholesale rewrites messes up the merges for everyone
who's maintaining local changes.

Much better if people stop being anal-retentive and stop wasting their
time checking/fiddling what kind of emptiness filling the empty spaces.


        Stefan

Re: Overriding the value of indent-tabs-mode in Emacs code

[Michael Heerdegen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05/26/2016 02:24 AM, Michael Heerdegen wrote:
>
> > Dumb question: why don't we just convert the files to the spaces
> > convention, if that's the goal anyway?  Doing it gradually patch by
> > patch (patches that are sometimes harder to read) seems to be quite
> > troublesome...
>
> This way we don't break each affected line's attribution in 'git
> blame' (one can ask it to ignore whitespace changes, but the user has
> to know to do that, and it makes the command considerably slower).

Aahh - too bad.


Thanks,

Michael.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Michael Heerdegen]

Karl Fogel <kfogel@red-bean.com> writes:

> This can be worked around, of course -- you just step back past that
> special revision and try again -- but it is a bit of inconvenience
> when one is digging through history.

It's inconvenient, but I think most people won't even retry.  So it's
probably really not worth it.


Thanks,

Michael.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Dmitry Gutov]

On 05/26/2016 02:54 AM, Stefan Monnier wrote:

> And doing such wholesale rewrites messes up the merges for everyone
> who's maintaining local changes.

'git merge -Xignore-space-change' could help with that.

> Much better if people stop being anal-retentive and stop wasting their
> time checking/fiddling what kind of emptiness filling the empty spaces.

Not all of us can be cool like you, and still push out decent code.

It's entirely possible that, were I not anal-retentive, I wouldn't have 
started using Emacs in the first place.

Re: Overriding the value of indent-tabs-mode in Emacs code

[Stefan Monnier]

>> Much better if people stop being anal-retentive and stop wasting their
>> time checking/fiddling what kind of emptiness filling the empty spaces.
> Not all of us can be cool like you, and still push out decent code.
> It's entirely possible that, were I not anal-retentive, I wouldn't have
> started using Emacs in the first place.

Oh, definitely.  I'm pretty anal-retentive myself.  I'm just saying we
have to try and make an effort to overcome our natural instinct.

I have daily appointments with M-x doctor for that.


        Stefan

Re: Overriding the value of indent-tabs-mode in Emacs code

[John Wiegley]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Much better if people stop being anal-retentive and stop wasting their time
> checking/fiddling what kind of emptiness filling the empty spaces.

Bike-shedding the shape of the void is perhaps the ultimate achievement.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Overriding the value of indent-tabs-mode in Emacs code

[Stefan Monnier]

>> Much better if people stop being anal-retentive and stop wasting their time
>> checking/fiddling what kind of emptiness filling the empty spaces.
> Bike-shedding the shape of the void is perhaps the ultimate achievement.

Oh I see I was confused, sorry.  I thought we were talking about its color.


        Stefan

Re: Overriding the value of indent-tabs-mode in Emacs code

[Paul Eggert]

On 05/27/2016 12:45 PM, John Wiegley wrote:
> Bike-shedding the shape of the void is perhaps the ultimate achievement.

The shape of the void is a serious question! You might get a Nobel Prize 
for figuring it out, as it would cast light on a whole bunch of things 
such as neutrino mass. And as it happens, GPLed software is a tool in 
finding the shape of cosmic voids. E.g., see 
<http://www.cosmicvoids.net/> for info about the VIDE void-finder 
toolkit, along with a cosmic void catalog.

Re: Overriding the value of indent-tabs-mode in Emacs code

[John Wiegley]

>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

> The shape of the void is a serious question! You might get a Nobel Prize for
> figuring it out, as it would cast light on a whole bunch of things such as
> neutrino mass. And as it happens, GPLed software is a tool in finding the
> shape of cosmic voids. E.g., see <http://www.cosmicvoids.net/> for info
> about the VIDE void-finder toolkit, along with a cosmic void catalog.

Sigh.

:)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2