bug#20322: 25.0.50; indent-tabs-mode should default to nil

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

Is there a reason it's t by default?

There are different personal preferences for indentation, but spaces are
used quite a bit more often than tabs, in most languages I'm familiar with.

Having it be nil by default (but set locally by modes that really need
it, like makefile-mode) will mean that most users won't have to
customize it.

In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2015-04-14 on axl
Repository revision: 56dfd3de9c63dbb6325129de8e38c420808146c9
Windowing system distributor `The X.Org Foundation', version 11.0.11601901
System Description:	Ubuntu 14.10

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> Is there a reason it's t by default?

There was probably a reason originally.  Nowadays, I think the main
reason it's t is because there's no sufficiently good reason to change
it (the hypothetical benefit of change will be smaller than the pain of
having to suffer through too many people bitching at the change).

I.e. this is kind of like endianness.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 06:07 AM, Stefan Monnier wrote:

> There was probably a reason originally.  Nowadays, I think the main
> reason it's t is because there's no sufficiently good reason to change
> it (the hypothetical benefit of change will be smaller than the pain of
> having to suffer through too many people bitching at the change).

Let's do a trial in master, to see how much bitching this results in? :)

Consider this: when initially diving into Emacs (coming from some 
experience with two IDEs), I was learning how to configure indentation 
in different modes. The necessary steps were:

1) Find the variable `indent-tabs-mode'. See it doesn't help with the 
amount of indentation per level, keep looking. Same with `tab-width'.

2) Find the language-dependent variables (js-indent-level, 
css-indent-offset and c-basic-offset). It doesn't help that each one is 
named in a different fashion.

3) Notice that while it almost works like intended, sometimes you get 
tabs inserted. Go back to `indent-tabs-mode', put `(setq 
indent-tabs-mode nil)` in the init file, see that it doesn't help.

4) Find out about buffer-local-ness and `setq-default'. That finally 
does it.

The above steps required certain persistence.

> I.e. this is kind of like endianness.

One could say that about any variable with existing default value, no?

I think it's different enough: the current users should know pretty 
easily how to change it, whereas it's usually a bigger issue for 
newcomers.  Better defaults would result in a better initial experience 
bringing the adoption up somewhat; on the flip side, I can't imagine 
anyone quitting Emacs over this default value.

And since this value is not just a user preference (it's 
project-dependent), even those who prefer tabs have probably had to use 
a different value at some point. So they know what to change.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Tue, 14 Apr 2015 17:14:14 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: 20322@debbugs.gnu.org
> 
> Consider this: when initially diving into Emacs (coming from some 
> experience with two IDEs), I was learning how to configure indentation 
> in different modes. The necessary steps were:

The alternative is not to configure indentation at all, but instead to
use the defaults, which are quite reasonable.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 06:25 PM, Eli Zaretskii wrote:

> The alternative is not to configure indentation at all, but instead to
> use the defaults, which are quite reasonable.

No, they're not. They're only so in major modes that set several of the 
related variables locally (e.g. ruby-mode, and python-mode as I see now).

Speaking of JavaScript, the defaults do not conform to the current 
convention (2 spaces, no tabs).

I'm not 100% sure what's the split in C and C++ communities, but Java 
favors spaces as well.

Even folks who want tabs have to configure stuff, because of our 
`tab-width' default (which is indeed something we cannot change now): 
http://stackoverflow.com/a/21788651/615245

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Tue, 14 Apr 2015 18:39:40 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/14/2015 06:25 PM, Eli Zaretskii wrote:
> 
> > The alternative is not to configure indentation at all, but instead to
> > use the defaults, which are quite reasonable.
> 
> No, they're not.

Then by all means let's fix those modes whose defaults aren't.

> I'm not 100% sure what's the split in C and C++ communities

The vast majority of people I work with use tabs, FWIW.

> Even folks who want tabs have to configure stuff, because of our 
> `tab-width' default (which is indeed something we cannot change now): 
> http://stackoverflow.com/a/21788651/615245

Our tab-width default is simply the default tab width everywhere.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 06:59 PM, Eli Zaretskii wrote:

> Then by all means let's fix those modes whose defaults aren't.

So, most of them? Like I said, in the end that would call for the change 
of the default value. In the meantime, should we have an 
xxx-indent-tabs-mode variable per major mode?

Here's some statistics: http://sideeffect.kr/popularconvention/#java 
(you can click on the language names), sources at 
https://github.com/outsideris/popularconvention

I understand that C (and, to lesser extent, C++) have a lot of history, 
and a lot of variance in their communities.

But the only semi-official style guide I could find that advises to use 
tabs in the Linux kernel one: 
http://www.maultech.com/chrislott/resources/cstyle/LinuxKernelCodingStyle.txt

The GNU coding style, to the best of my understanding, does not mention 
tabs at all.

> The vast majority of people I work with use tabs, FWIW.

Do they use 8-column offsets, then?

>> Even folks who want tabs have to configure stuff, because of our
>> `tab-width' default (which is indeed something we cannot change now):
>> http://stackoverflow.com/a/21788651/615245
>
> Our tab-width default is simply the default tab width everywhere.

I'm not sure what you mean by that, but my point was, the defaults are 
not suitable as-is (even) for a certain part of our users that use tabs.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> Here's some statistics: http://sideeffect.kr/popularconvention/#java (you
> can click on the language names), sources at
> https://github.com/outsideris/popularconvention

This doesn't seem to talk about the same thing as what indent-tabs-mode does.
I haven't looked at the code they use, but at least the example they
give is:
   function foo() {
     return "bar";
   }

vs

   function foo() {
       // use tab for indentation
       return "bar";
   }

whereas indent-tabs-mode does not influence which column is used, only
which chars are used to get there.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/15/2015 12:43 AM, Stefan Monnier wrote:

> This doesn't seem to talk about the same thing as what indent-tabs-mode does.
> I haven't looked at the code they use, but at least the example they
> give is:
>     function foo() {
>       return "bar";
>     }
>
> vs
>
>     function foo() {
>         // use tab for indentation
>         return "bar";
>     }
>
> whereas indent-tabs-mode does not influence which column is used, only
> which chars are used to get there.

The examples are admittedly bad (not sure why; maybe because the author 
found it non-trivial to insert a tab in the middle of a string literal, 
in their editor). Also see the Ruby one, where both sides of the 
comparison use 2-space offset.

However, the implementation seems to do the right thing:

https://github.com/outsideris/popularconvention/blob/master/src/parser/js-parser.coffee#L99-L100
https://github.com/outsideris/popularconvention/blob/master/src/parser/java-parser.coffee#L51-L52
https://github.com/outsideris/popularconvention/blob/master/src/parser/php-parser.coffee#L59-L60

Anyway, the results seem to coincide with what's I've seen in practice.

If they can actually change someone's position, we can double-check 
them, run the analysis ourselves, look for other statistics, etc.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> However, the implementation seems to do the right thing:

> https://github.com/outsideris/popularconvention/blob/master/src/parser/js-parser.coffee#L99-L100

This seems to count the number of lines which start with a SPC and those
which start with a TAB.

If your indentation rules use an indentation step of 2, you'd likely get
many more lines that start with SPC regardless of indent-tabs-mode
(just because most lines of code are less indented than 8 columns).

So, I don't think it does the right test.  I think the right test would be

  tab = /^\t/
  space = /^\s\s\s\s\s\s\s\s/


-- Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/15/2015 04:19 AM, Stefan Monnier wrote:
>> However, the implementation seems to do the right thing:
>
>> https://github.com/outsideris/popularconvention/blob/master/src/parser/js-parser.coffee#L99-L100
>
> This seems to count the number of lines which start with a SPC and those
> which start with a TAB.

That sounds right. But I'd say the projects that mix tabs and spaces 
must be a minority among those that use tabs at all.

> If your indentation rules use an indentation step of 2, you'd likely get
> many more lines that start with SPC regardless of indent-tabs-mode
> (just because most lines of code are less indented than 8 columns).

I don't actually recall seeing code intentionally mixing tabs and spaces 
like that, ever, before looking at Emacs's sources.

> So, I don't think it does the right test.  I think the right test would be
>
>    tab = /^\t/
>    space = /^\s\s\s\s\s\s\s\s/

That would be more correct indeed. Again, if you think the results of 
this can matter in some future decision, I can spend the time to apply 
the fix, deploy it myself and rerun the analysis.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> That would be more correct indeed. Again, if you think the results of this
> can matter in some future decision, I can spend the time to apply the fix,
> deploy it myself and rerun the analysis.

For most major modes, you don't need to convince me (because I just
don't know that language enough to have an opinion), but in any case
if the decision is based on such analysis (which could make sense), then
I think it's worth making the analysis correct, indeed.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/15/2015 07:19 AM, Stefan Monnier wrote:

> For most major modes, you don't need to convince me (because I just
> don't know that language enough to have an opinion), but in any case
> if the decision is based on such analysis (which could make sense), then
> I think it's worth making the analysis correct, indeed.

Looking into this more, your suggestion favors tabs, a lot.

Since (as I can tell from looking at all "tabs vs spaces" blog posts, 
discussions, etc, and from recalling my petulant youth), the prevailing 
approach is to use one tab per indent level, whereas /^ {8}/ matches 1-4 
indent levels, depending on the language and project (but usually 2 for 
Java and 4 for JS), we skip a lot of space-indented lines.

Keeping this in mind, here's some results. I've ran through all 
2015-01-01 diffs (which is admittedly not the best date; as far as bias 
in concerned), and counted the "added" lines matching either regexp.

Doing this for the rest of the January would take a few more days, and 
I'm not sure if that's really valuable, considering the above.

C:     tabs => 1241263, spaces =>   636266
C++:   tabs =>  466087, spaces =>   926052
JS:    tabs => 8430336, spaces => 11739058
Java:  tabs => 7620803, spaces =>  1509610
Elisp: tabs =>  150071, spaces =>   185015

You can look at the implementation here: 
https://gist.github.com/dgutov/addc25762453c5a205ea

To run it locally, one would also need to download the files for 
January, from https://www.githubarchive.org/ (it comes out to ~460MB per 
day), and a persistent Internet connection to actually download the diffs.

If anyone wants, I can also post the fairly verbose (as you can see from 
the script) log from the current run. It's 15MB gzipped.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> Doing this for the rest of the January would take a few more days, and I'm
> not sure if that's really valuable, considering the above.

> C:     tabs => 1241263, spaces =>   636266
> C++:   tabs =>  466087, spaces =>   926052
> JS:    tabs => 8430336, spaces => 11739058
> Java:  tabs => 7620803, spaces =>  1509610
> Elisp: tabs =>  150071, spaces =>   185015

Ah, so the units are lines?  Indeed, then this can be strongly biased if
people use smaller tab-width than 8.

It seems it would make more sense to count files (or projects), where
each file gets to be counted either as SPC or as TAB depending on
whether it has more lines that use TAB than lines that use either spaces.

This way, the bias only affects a file at a time, which should be
insignificant if we assume that those files should use a consistent
style (i.e. either 99% TABs or 99% SPC).


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/20/2015 10:26 PM, Stefan Monnier wrote:

> Ah, so the units are lines?  Indeed, then this can be strongly biased if
> people use smaller tab-width than 8.
>
> It seems it would make more sense to count files (or projects), where
> each file gets to be counted either as SPC or as TAB depending on
> whether it has more lines that use TAB than lines that use either spaces.

That sounds better, but still would discount the JavaScript files with 
less than 4 levels of nesting (unless we only count each project once; 
but I think the project size is important, too). And in our case, any 
hunks which didn't include this level of nesting (see the caveat at the 
bottom).

Here's updated counts (in number of files), produced by parsing the log 
(one you can download here: http://dropcanvas.com/3mwn1):

C:     tabs => 17422, spaces =>  6509
C++:   tabs =>  7366, spaces => 17155
JS:    tabs => 30100, spaces => 73370
Java:  tabs => 66922, spaces => 38243
Elisp: tabs =>   515, spaces =>  1465

(The ratio for C became even more tab-favored, but others seem to have 
moved towards spaces).

Script:

File.open("print.log", "r") do |file|
   results = Hash[%w(c cpp js java el).map { |ext| [ext, {tabs: 0, 
spaces: 0}]}]
   file_re = /\.(#{results.keys.join("|")}): spaces ([0-9]+), tabs 
([0-9]+)$/

   file.each_line do |line|
     if line =~ file_re
       ext    = $~[1]
       spaces = $~[2].to_i
       tabs   = $~[3].to_i

       ext_results = results[ext]
       if spaces > tabs
         ext_results[:spaces] += 1
       elsif spaces < tabs
         ext_results[:tabs] += 1
       end
     end
   end

   puts results
end

> This way, the bias only affects a file at a time, which should be
> insignificant if we assume that those files should use a consistent
> style (i.e. either 99% TABs or 99% SPC).

CAVEAT: The above was still only the result of the diffs analysis, and 
didn't examine the files in their entirety (the original run took more 
than 8 hours here, and downloading the actual files is bound to take an 
order of magnitude more, just for January 1st).

But to get a feeling for the margin of error, here's the result of 
running a modified script, which sorted all "spaces 0, tabs 0" files 
into the "spaces" bucket:

C:     tabs => 17422,  spaces =>  16683
C++:   tabs =>  7366,  spaces =>  44641
JS:    tabs => 30100,  spaces => 143709
Java:  tabs => 66922,  spaces =>  98886
Elisp: tabs =>   515,  spaces =>   2423

So yeah, it seems C programmers favored tabs either way that day. The 
Java programmers, however, are undecided.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> But to get a feeling for the margin of error, here's the result of
> running a modified script, which sorted all "spaces 0, tabs 0" files into
> the "spaces" bucket:

> C:     tabs => 17422,  spaces =>  16683
> C++:   tabs =>  7366,  spaces =>  44641
> JS:    tabs => 30100,  spaces => 143709
> Java:  tabs => 66922,  spaces =>  98886
> Elisp: tabs =>   515,  spaces =>   2423

That suggests that it might be OK to set indent-tabs-mode to nil in
javascript-mode and in elisp-mode.  Maybe even in C++.  But clearly not
in C nor in Java.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/21/2015 04:25 AM, Stefan Monnier wrote:

> That suggests that it might be OK to set indent-tabs-mode to nil in
> javascript-mode and in elisp-mode.  Maybe even in C++.  But clearly not
> in C nor in Java.

C -- seems so. But I disagree about Java: my run was inconclusive, and 
the analysis I originally linked to, 
http://sideeffect.kr/popularconvention/#java (66% spaces), is almost 
(thought not quite) within the margin of error.

The "\s\s" vs "\s{8}" distinction is also unlikely to matter in that 
community, because if they do use tabs, it's almost always one tab per 
indent level. Any Java developers reading this should feel free to 
contradict me.

Considering that Java is a corporate-driven language, and both Oracle's 
and Google's Java style guides advise to use spaces, it seems to be the 
way to go.

Now, provided we agree to default to spaces in the majority of the 
popular programming languages modes, what's the reasoning not to flip 
the default? Have I missed some important languages (note that Python 
and Ruby are already covered), or is using tabs supposed to be 
beneficial for the text modes?

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Tue, 21 Apr 2015 22:25:23 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: 20322@debbugs.gnu.org
> 
> On 04/21/2015 04:25 AM, Stefan Monnier wrote:
> 
> > That suggests that it might be OK to set indent-tabs-mode to nil in
> > javascript-mode and in elisp-mode.  Maybe even in C++.  But clearly not
> > in C nor in Java.
> 
> C -- seems so.

Please don't make different defaults for C and C++.  These are very
closely related languages, and there are many projects that start as C
and then migrate to C++ (GCC, for example).  It would be confusing to
have the defaults suddenly change under you when that happens.

> Now, provided we agree to default to spaces in the majority of the 
> popular programming languages modes, what's the reasoning not to flip 
> the default?

If you flip the default (I guess in prog-mode?) and then change the
mode switch function to restore the current value, there's no reason
not to flip the default, since doing that will not affect those modes
in any way.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/21/2015 10:47 PM, Eli Zaretskii wrote:

> Please don't make different defaults for C and C++.  These are very
> closely related languages, and there are many projects that start as C
> and then migrate to C++ (GCC, for example).  It would be confusing to
> have the defaults suddenly change under you when that happens.

 From where I'm standing, it's an argument to just use spaces for both C 
and C++.

But anyway, I don't think project migration is a good problem example. 
There are a lot things to do during that kind of migration, and adding 
an `indent-tabs-mode' to dir-locals.el should be trivial in comparison. 
A project that lives long enough to migrate must already have this file.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Wed, 22 Apr 2015 18:02:28 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/21/2015 10:47 PM, Eli Zaretskii wrote:
> 
> > Please don't make different defaults for C and C++.  These are very
> > closely related languages, and there are many projects that start as C
> > and then migrate to C++ (GCC, for example).  It would be confusing to
> > have the defaults suddenly change under you when that happens.
> 
>  From where I'm standing, it's an argument to just use spaces for both C 
> and C++.
> 
> But anyway, I don't think project migration is a good problem example. 
> There are a lot things to do during that kind of migration, and adding 
> an `indent-tabs-mode' to dir-locals.el should be trivial in comparison. 

I meant the actual usage of tabs/spaces in the files.  That, of
course, doesn't change when the project migrates.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/22/2015 06:18 PM, Eli Zaretskii wrote:

> I meant the actual usage of tabs/spaces in the files.  That, of
> course, doesn't change when the project migrates.

I don't see how this contradicts my previous message.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Wed, 22 Apr 2015 18:23:06 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/22/2015 06:18 PM, Eli Zaretskii wrote:
> 
> > I meant the actual usage of tabs/spaces in the files.  That, of
> > course, doesn't change when the project migrates.
> 
> I don't see how this contradicts my previous message.

I thought it was obvious: Changing the whitespace usage is not a
simple job, and no one will normally do that.  So having different
defaults will silently and subtly cause a change in project-wide
conventions, something that I think is undesirable.

There are also mixed C/C++ projects, where different defaults will
cause similar problems.

In short, these two languages are just too similar and inter-related
to justify using the same defaults in this regard.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/22/2015 06:28 PM, Eli Zaretskii wrote:

> I thought it was obvious: Changing the whitespace usage is not a
> simple job, and no one will normally do that.

What I'm suggesting is that such a project would add an entry to 
dir-locals, to solidify its current conventions. They've probably done 
it already:

> So having different
> defaults will silently and subtly cause a change in project-wide
> conventions, something that I think is undesirable.

Sneaky changes are not only caused by changed defaults. Some members of 
the team might have different tabs-indent-mode values set up in their 
configs. The only way to guard against that is to do the above anyway.

> In short, these two languages are just too similar and inter-related
> to justify using the same defaults in this regard.

Well, like mentioned before, exceptions add complexity. So it's not like 
I really disagree.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> But I disagree about Java: my run was inconclusive, and the

Exactly.  Which means it doesn't justify a change.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/21/2015 11:27 PM, Stefan Monnier wrote:

> Exactly.  Which means it doesn't justify a change.

Like I said, there's no reason not to trust the original results on the 
Java front.

Should I remind here that the common "tabs indentation" style used by 
Java programmers is different from what our defaults provide (which is 
mixed tabs and spaces, 
http://www.emacswiki.org/pics/static/TabsSpacesBoth.png)? As it is, we 
serve neither crowd, and changing the `tab-width' default is infeasible.

I've spent two years doing Java at the beginning of my career, so I'm 
familiar with the trending bike shed colors there (even if that was 
several years ago).

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> Now, provided we agree to default to spaces in the majority of the popular
> programming languages modes, what's the reasoning not to flip the default?

The reasoning is simple: the actual value matters much less than the fact
that it is changed.
If the default had been nil, I'd also oppose a change to set it to t for
the same reason.

IOW it is pure inertia.  *Very* few people would come a thank us for the
change, but many more will complaint.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/22/2015 04:56 PM, Stefan Monnier wrote:

> IOW it is pure inertia.  *Very* few people would come a thank us for the
> change, but many more will complaint.

But we'd have the same problem if we change the value in specific modes 
(which include all the popular programming languages where tabs aren't 
mandatory, maybe sans cc-mode supported ones).

Maybe with fewer people (excluding folks who prefer tabs but don't use 
any of the modes where it's changed), but the affected people would be 
more annoyed, because changing it back will be more complicated for them.

The users who most benefit from better defaults are of course the ones 
we don't have yet. They won't give thanks for this, but that doesn't 
mean it's not valuable.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

>> IOW it is pure inertia.  *Very* few people would come a thank us for the
>> change, but many more will complaint.
> But we'd have the same problem if we change the value in specific modes

Fundamentally, yes, but the number of people will be affected.
If the number of people who will be annoyed is small enough
(e.g. because it's a mode that's rarely used, or because most users
will be happy about the change), then it's OK.

> of the modes where it's changed), but the affected people would be more
> annoyed, because changing it back will be more complicated for them.

I don't buy the "more complicated" argument.  There are circumstances
where it will be marginally more complicated but in any case

    (add-hook 'foo-mode-hook (lambda () (setq indent-tabs-mode <bar>)))

is the recommended way to set it and that will work just fine.

Remember: TAB-vs-SPC is like arguing about which primer we should use
before painting the bikeshed.  Any gain will be minuscule, so the pain
has to be correspondingly minuscule.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/22/2015 05:59 PM, Dmitry Gutov wrote:

> The users who most benefit from better defaults are of course the ones
> we don't have yet. They won't give thanks for this, but that doesn't
> mean it's not valuable.

Here's another confused user: 
https://www.reddit.com/r/emacs/comments/3r8ec2/my_indentation_in_js2mode_is_messed_up_need_some/

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04/22/2015 05:59 PM, Dmitry Gutov wrote:
>> The users who most benefit from better defaults are of course the ones we
>> don't have yet. They won't give thanks for this, but that doesn't mean it's
>> not valuable.

> Here's another confused user:
> https://www.reddit.com/r/emacs/comments/3r8ec2/my_indentation_in_js2mode_is_messed_up_need_some/

I would also like to see this be `nil' by default. Eli, Stefan, Richard, do
you see a reason not to?

John

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 11/02/2015 10:37 PM, John Wiegley wrote:

> I would also like to see this be `nil' by default. Eli, Stefan, Richard, do
> you see a reason not to?

I believe at least 2 out of 3 aforementioned persons do. Have you read 
this thread?

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> I believe at least 2 out of 3 aforementioned persons do. Have you read this
> thread?

Ah, my mail reader didn't present your message to me as if it were part of a
larger thread, whose context I missed.  So no, I didn't see, but I see them
now on the mailing list. 

I'm still inclined to changed the default, since tabs are fairly evil in
general.

John

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> From: "John Wiegley" <jwiegley@gmail.com>
> Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, 20322@debbugs.gnu.org
> Date: Mon, 02 Nov 2015 15:37:49 -0500
> 
> >>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > On 04/22/2015 05:59 PM, Dmitry Gutov wrote:
> >> The users who most benefit from better defaults are of course the ones we
> >> don't have yet. They won't give thanks for this, but that doesn't mean it's
> >> not valuable.
> 
> > Here's another confused user:
> > https://www.reddit.com/r/emacs/comments/3r8ec2/my_indentation_in_js2mode_is_messed_up_need_some/
> 
> I would also like to see this be `nil' by default. Eli, Stefan, Richard, do
> you see a reason not to?

We should poll the users, if we want to revert this very old default.
(I will be against ;-)

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> We should poll the users, if we want to revert this very old default. (I
> will be against ;-)

Where would be a good place to advertise and carry out such a poll?

John

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I used to announce polls on info-gnu-emacs and help-gnu-emacs.  We
should continue doing that.  In addition we can announce them in
gnu.org/software/emacs and in emacswiki.

For each poll, we create a mailing list that dumps replies into a
file.  We use a new list and a new file for each poll.  A few weeks
after the announcement, we look at the responses in the file.

In the announcement, we ask people to state their reasons, their use
cases, and how the consequences will be good or bad for them -- not
just vote.  We evaluate the poll by how much good or bad the choices
would do, not by counting votes.

We also invite people to suggest other solutions.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> From: "John Wiegley" <jwiegley@gmail.com>
> Cc: dgutov@yandex.ru,  monnier@IRO.UMontreal.CA,  rms@gnu.org,  20322@debbugs.gnu.org
> Date: Mon, 02 Nov 2015 16:29:51 -0500
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We should poll the users, if we want to revert this very old default. (I
> > will be against ;-)
> 
> Where would be a good place to advertise and carry out such a poll?

gnu.emacs.help for starters, I think.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would also like to see this be `nil' by default. Eli, Stefan, Richard, do
  > you see a reason not to?

I will try changing it and see what I think.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Wolfgang Jenkner]

On Wed, Apr 15 2015, Dmitry Gutov wrote:

>> If your indentation rules use an indentation step of 2, you'd likely get
>> many more lines that start with SPC regardless of indent-tabs-mode
>> (just because most lines of code are less indented than 8 columns).
>
> I don't actually recall seeing code intentionally mixing tabs and
> spaces like that, ever, before looking at Emacs's sources.

This is also the traditional (and POSIX) behaviour of vi.  For example,
search for "autoindent, ai" (without the quotes) in

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Tue, 14 Apr 2015 23:24:54 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/14/2015 06:59 PM, Eli Zaretskii wrote:
> 
> > Then by all means let's fix those modes whose defaults aren't.
> 
> So, most of them?

If it turns out that most of the modes need indent-tabs-mode set to
nil, you can make it the default in prog-mode, or even in fundamental
mode.  As long as the modes that don't need to avoid tabs are changed
to have the same default as now, I won't object.

> Like I said, in the end that would call for the change of the
> default value. In the meantime, should we have an
> xxx-indent-tabs-mode variable per major mode?

I don't see a need for a mode-specific variable in this case; do you?

> I understand that C (and, to lesser extent, C++) have a lot of history, 
> and a lot of variance in their communities.
> 
> But the only semi-official style guide I could find that advises to use 
> tabs in the Linux kernel one: 
> http://www.maultech.com/chrislott/resources/cstyle/LinuxKernelCodingStyle.txt
> 
> The GNU coding style, to the best of my understanding, does not mention 
> tabs at all.

Let's just honor history in this case, OK?

> > The vast majority of people I work with use tabs, FWIW.
> 
> Do they use 8-column offsets, then?

No (that's how I know they use tabs in the first place!).

> >> Even folks who want tabs have to configure stuff, because of our
> >> `tab-width' default (which is indeed something we cannot change now):
> >> http://stackoverflow.com/a/21788651/615245
> >
> > Our tab-width default is simply the default tab width everywhere.
> 
> I'm not sure what you mean by that, but my point was, the defaults are 
> not suitable as-is (even) for a certain part of our users that use tabs.

For a customizable option, this is not an issue.  I can understand
that the new generation may want to get rid of tabs, but since most of
that generation don't work in C/C++, I think we can leave those alone
for now.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/15/2015 07:10 PM, Eli Zaretskii wrote:

> If it turns out that most of the modes need indent-tabs-mode set to
> nil, you can make it the default in prog-mode, or even in fundamental
> mode.

Make it the default in fundamental mode means changing the default value 
of the variable.

> As long as the modes that don't need to avoid tabs are changed
> to have the same default as now, I won't object.

I'm not aware of any popular programming language that doesn't work with 
tabs for indentation. So "need" is a pretty strong word. If the 
statistics show that spaces are more popular on GitHub for C and C++, 
why not follow the logical conclusion and change the defaults for those 
modes, too?

Note that cc-mode also services the needs of Emacs users writing Java 
and Objective-C (all seven of them), and those folks must be relatively 
modern-inclined.

And while I wouldn't mind leaving this bee's nest "as is", there's no 
way to do that just for C and C++ without introducing additional 
complication for users that *do* want to use spaces with those langs.

>> Like I said, in the end that would call for the change of the
>> default value. In the meantime, should we have an
>> xxx-indent-tabs-mode variable per major mode?
>
> I don't see a need for a mode-specific variable in this case; do you?

How, then, will the users change that value? With `add-hook', 
`xxx-mode-hook' and a lambda function?

That's a significant jump in complexity from what's currently needed to 
change `indent-tabs-mode' - either `setq-default', or actually using the 
`Customize' interface.

Think back to the four "how to configure indentation" steps I listed in 
an earlier email. Now mode-hooks and lambdas will add one or two new 
ones, and without a variable, the user will have to figure out somehow 
that the major mode function changes the `indent-tabs-mode' value.

It wouldn't have simplified the scenario for me: at the time I 
configured Emacs both for JavaScript *and* C (and a few other 
languages), to do tutorials, exercises and that kind of stuff.

>>> The vast majority of people I work with use tabs, FWIW.
>>
>> Do they use 8-column offsets, then?
>
> No (that's how I know they use tabs in the first place!).

One of us doesn't understand the other here. Just to be sure: I meant 
`c-basic-offset', not `tab-width'.

> For a customizable option, this is not an issue.  I can understand
> that the new generation may want to get rid of tabs, but since most of
> that generation don't work in C/C++, I think we can leave those alone
> for now.

The question is not what the majority of the "new generation" works in 
(probably Java, or PHP), but what fraction of C/C++ programmers uses spaces.

Anyway, just for an arbitrary example, here's the three projects using 
C++ that I've looked at most recently. All relevant to Emacs's code 
assistance (which is the area I'm paying attention to lately):

https://github.com/Sarcasm/irony-mode
https://github.com/AndersBakken/rtags
https://github.com/Valloric/ycmd

None of them use tabs.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> How, then, will the users change that value? With `add-hook',
> `xxx-mode-hook' and a lambda function?

Yup.  Adding more mode-specific variables to circumvent the problem is
not a good idea.  If add-hook+lambda is considered too cumbersome, we
can wrap it in some function/macro to make it look prettier.

I personally find that Custom should grow a way to set the value of
those variables "per mode" or maybe even "per directory".


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 07:58 AM, Stefan Monnier wrote:

> Yup.  Adding more mode-specific variables to circumvent the problem is
> not a good idea.  If add-hook+lambda is considered too cumbersome, we
> can wrap it in some function/macro to make it look prettier.

Even if a user is fine with writing a lambda or using some new macro, 
they'd still have to fist discover that a specific mode overrides a 
given variable during its initialization.

AFAIK, a lot of fairly experienced users don't routinely use 
`find-function'.

> I personally find that Custom should grow a way to set the value of
> those variables "per mode" or maybe even "per directory".

"per directory" sounds like an appropriate addition to the project 
management functionality, which we'll grow any day now.

"per mode" sounds easier, and maybe we can start with defining a 
programmatic API for that. How about a global variable, using the same 
format as .dir-locals.el contents?

And then have an element at the end of `after-change-major-mode-hook' 
that would apply these values (or simply hardcode that logic in 
`run-mode-hooks').

One aspect I'm not clear on is how the modes would add elements to it. 
There'll probably be a button like "erase customization for this mode" 
in the Customize interface, but how would it know, and how would it 
convey to the user, that the variable would revert to the mode-specific 
value, not the global one?

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Fri, 17 Apr 2015 05:48:08 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/15/2015 07:10 PM, Eli Zaretskii wrote:
> 
> > If it turns out that most of the modes need indent-tabs-mode set to
> > nil, you can make it the default in prog-mode, or even in fundamental
> > mode.
> 
> Make it the default in fundamental mode means changing the default value 
> of the variable.

Yes, I know that.  I'm saying that this default doesn't bother me, as
long as the modes that I care about still default to non-nil.

> > As long as the modes that don't need to avoid tabs are changed
> > to have the same default as now, I won't object.
> 
> I'm not aware of any popular programming language that doesn't work with 
> tabs for indentation. So "need" is a pretty strong word.

I meant "need" as in "most users of that language already use spaces".

> If the 
> statistics show that spaces are more popular on GitHub for C and C++, 
> why not follow the logical conclusion and change the defaults for those 
> modes, too?

I don't consider GitHub to be a representative sample for this matter.

> Note that cc-mode also services the needs of Emacs users writing Java 
> and Objective-C (all seven of them), and those folks must be relatively 
> modern-inclined.

Each one of them has a specific hook to take care of that, if needed.
Moreover, if most users of ObjC or Java want spaces, let's make that
change in the respective mode, java-mode etc.

> And while I wouldn't mind leaving this bee's nest "as is", there's no 
> way to do that just for C and C++ without introducing additional 
> complication for users that *do* want to use spaces with those langs.

I don't see any complications.  Doesn't everyone have their own hooks
for every language they use, anyway?  I know I do, since almost the
first day I started using Emacs.  That hook is the place where users
could customize the variable, if they don't the defaults.

> >> Like I said, in the end that would call for the change of the
> >> default value. In the meantime, should we have an
> >> xxx-indent-tabs-mode variable per major mode?
> >
> > I don't see a need for a mode-specific variable in this case; do you?
> 
> How, then, will the users change that value? With `add-hook', 
> `xxx-mode-hook' and a lambda function?

See above; and it doesn't have to be a lambda function, of course.
Mine has a name (my-c-stuff, if you want to know) and a doc string.

> That's a significant jump in complexity from what's currently needed to 
> change `indent-tabs-mode' - either `setq-default', or actually using the 
> `Customize' interface.

We are talking about programmers, for whom having a mode hook is not a
problem.  I'm actually guessing they already have such a hook anyway;
I cannot see how one can use a programming-language mode without a lot
of customizations, and the place to do that is in a mode hook.  This
is normal, routine practice in Emacs.

> >>> The vast majority of people I work with use tabs, FWIW.
> >>
> >> Do they use 8-column offsets, then?
> >
> > No (that's how I know they use tabs in the first place!).
> 
> One of us doesn't understand the other here. Just to be sure: I meant 
> `c-basic-offset', not `tab-width'.

Yes, I know that.  People I was talking about don't use 8 columns at
all, neither for the tab width, nor for the offsets.

> > For a customizable option, this is not an issue.  I can understand
> > that the new generation may want to get rid of tabs, but since most of
> > that generation don't work in C/C++, I think we can leave those alone
> > for now.
> 
> The question is not what the majority of the "new generation" works in 
> (probably Java, or PHP), but what fraction of C/C++ programmers uses spaces.

I gave you my personal statistics on that: most of them use tabs.  And
I personally get annoyed whenever a project asks me to untabify my
submissions (but abide, of course).

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Fri, 17 Apr 2015 10:26:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 20322@debbugs.gnu.org
> 
> I'm saying that this default doesn't bother me, as long as the modes
> that I care about still default to non-nil.

Btw, I'm also okay with introducing a new feature that would keep the
current style in existing files, something mentioned by Glenn.  I
guess this would need a new value of indent-tabs-mode, and code to
support that.  Maybe this is a compromise everyone would be at least
half-happy with.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 10:26 AM, Eli Zaretskii wrote:

> Yes, I know that.  I'm saying that this default doesn't bother me, as
> long as the modes that I care about still default to non-nil.

It seems that you won't object to changes as long as they don't affect 
your our experience, even if you'd just have to change one line in your 
init.el.

I mentioned the default value because it's a technical consideration.

> I meant "need" as in "most users of that language already use spaces".

So, you're open to considering C and C++ in this context, too?

> I don't consider GitHub to be a representative sample for this matter.

Maybe not, but it's a sample we can research. And Emacs could do worse 
than become more friendly to the modern-ish audience.

Do you have a better sample in mind?

> I don't see any complications.  Doesn't everyone have their own hooks
> for every language they use, anyway?  I know I do, since almost the
> first day I started using Emacs.  That hook is the place where users
> could customize the variable, if they don't the defaults.

The members of those "everyone" shouldn't be bothered with a change in 
one tiny default value anyway.

I think you're overestimating the savvy-ness of an average Emacs user. 
Not every beginner is fine with writing Elisp (some spend years without 
doing so), and the more effort a user's first steps in Emacs take, the 
more likely they are to settle for something else, because they haven't 
yet been properly exposed to Emacs's benefits yet.

That's why I think the default are important, and that they shouldn't 
take the entrenched user base so much into account.

> See above; and it doesn't have to be a lambda function, of course.
> Mine has a name (my-c-stuff, if you want to know) and a doc string.

I also use hooks quite a bit in my init script.

> We are talking about programmers, for whom having a mode hook is not a
> problem.

Not necessarily Emacs Lisp programmers, though.

> I'm actually guessing they already have such a hook anyway;
> I cannot see how one can use a programming-language mode without a lot
> of customizations, and the place to do that is in a mode hook.  This
> is normal, routine practice in Emacs.

The user options (and the Customize interface; I think we haven't given 
up on it yet) should cover the core of what a user might want to change.

Here's the sum total of my current ruby-mode tweaks. One 
`eval-after-load', but no custom functions in ruby-mode-hook:

(add-hook 'ruby-mode-hook 'flycheck-mode)
(add-hook 'ruby-mode-hook 'robe-mode)

(eval-after-load 'ruby-mode
   '(progn
      (define-key ruby-mode-map (kbd "C-c :") 'ruby-toggle-hash-syntax)
      (require 'ruby-end)))

Plus a few installed packages, some of which use `add-hook' at the top 
level. I do have one related `add-hook' with a lambda commented out 
currently, but it's also tiny, and the above provide a satisfactory 
experience already.

> I gave you my personal statistics on that: most of them use tabs.  And
> I personally get annoyed whenever a project asks me to untabify my
> submissions (but abide, of course).

Untabifying (or tabifying) should happen automatically, via 
project-local settings. There's even a cross-editor specification (as 
well as an Emacs package) for this: http://editorconfig.org/

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Fri, 17 Apr 2015 17:17:06 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/17/2015 10:26 AM, Eli Zaretskii wrote:
> 
> > Yes, I know that.  I'm saying that this default doesn't bother me, as
> > long as the modes that I care about still default to non-nil.
> 
> It seems that you won't object to changes as long as they don't affect 
> your our experience, even if you'd just have to change one line in your 
> init.el.

This argument goes both ways, you know.

And no, it's not only my experience, as I mentioned more than once in
this thread.

> > I meant "need" as in "most users of that language already use spaces".
> 
> So, you're open to considering C and C++ in this context, too?

Yes, except that there I have strong views, unlike with most other
languages.

Are _you_ open to leaving C and C++ at their current defaults?  What
would it take to convince you doing that?

> > I don't consider GitHub to be a representative sample for this matter.
> 
> Maybe not, but it's a sample we can research. And Emacs could do worse 
> than become more friendly to the modern-ish audience.
> 
> Do you have a better sample in mind?

I gave you mine.  I've seen, and still see, a lot of C/C++ code
written by others, and they all mix spaces and tabs.

> > I don't see any complications.  Doesn't everyone have their own hooks
> > for every language they use, anyway?  I know I do, since almost the
> > first day I started using Emacs.  That hook is the place where users
> > could customize the variable, if they don't the defaults.
> 
> The members of those "everyone" shouldn't be bothered with a change in 
> one tiny default value anyway.

True.  But changing long-lived defaults always annoys people; you can
see evidence to that on help-gnu-emacs almost every day.  So we
shouldn't change them without a very good reason.  And I don't see one
in this case.

> I think you're overestimating the savvy-ness of an average Emacs user. 
> Not every beginner is fine with writing Elisp (some spend years without 
> doing so), and the more effort a user's first steps in Emacs take, the 
> more likely they are to settle for something else, because they haven't 
> yet been properly exposed to Emacs's benefits yet.

I think you underestimate the widespread use of Google and questions
asked on stack-overflow and such likes.  People simply collect
snippets from there and paste them into their .emacs.  Problem solved.

> That's why I think the default are important, and that they shouldn't 
> take the entrenched user base so much into account.

But there's nothing wrong with this particular default.  It doesn't
reduce any functionality.  Users that aren't annoyed enough will learn
to live with it; those with higher motivation will discover how to
change that soon enough.  There's no real problem here.  Unlike other
arguments we had about changing defaults (font-lock, colors, and menus
come to mind), this one does not affect any functionality at all.

> > See above; and it doesn't have to be a lambda function, of course.
> > Mine has a name (my-c-stuff, if you want to know) and a doc string.
> 
> I also use hooks quite a bit in my init script.

I think everyone and their dog do.

> > We are talking about programmers, for whom having a mode hook is not a
> > problem.
> 
> Not necessarily Emacs Lisp programmers, though.

I don't think this matters much.  When you customize a package, you do
that in whatever extension language that package provides.  The
important aspect here is that programmers are less more likely to
become intimidated by the need to make such customizations, in
whatever language.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 05:36 PM, Eli Zaretskii wrote:

> This argument goes both ways, you know.

You're welcome to use it against myself when an opportunity rises. I 
don't believe it's the case here.

> And no, it's not only my experience, as I mentioned more than once in
> this thread.

Sure, but one's circle of acquaintances is not the best metric.

> Are _you_ open to leaving C and C++ at their current defaults?  What
> would it take to convince you doing that?

A decent statistical analysis of the current active C and C++ projects 
would do it, if it favors tabs (or at least doesn't favor spaces too 
heavily), as well as an obvious-enough way for the users to change the 
indent-tabs-mode value in those modes.

> I gave you mine.  I've seen, and still see, a lot of C/C++ code
> written by others, and they all mix spaces and tabs.

While GitHub is not an ideal sample, it's certainly bigger than your 
sample, don't you agree? And a lot of corporations have been migrating 
their libre software projects to GitHub in the recent years.

> True.  But changing long-lived defaults always annoys people; you can
> see evidence to that on help-gnu-emacs almost every day.  So we
> shouldn't change them without a very good reason.  And I don't see one
> in this case.

Considering the size of the Emacs user base, one might say the evidence 
on help-gnu-emacs is pretty underwhelming (or else we'd be drowning in it).

> I think you underestimate the widespread use of Google and questions
> asked on stack-overflow and such likes.  People simply collect
> snippets from there and paste them into their .emacs.  Problem solved.

Yeah, I guess they do. But that's definitely not ideal.

> But there's nothing wrong with this particular default.  It doesn't
> reduce any functionality.  Users that aren't annoyed enough will learn
> to live with it; those with higher motivation will discover how to
> change that soon enough.  There's no real problem here.  Unlike other
> arguments we had about changing defaults (font-lock, colors, and menus
> come to mind), this one does not affect any functionality at all.

The indentation style is one of the obvious bikeshedding topics. I 
suspect a significant fraction of Emacs users try to make it just right 
in their config from the start.

If you think that that value is not a problem, you shouldn't object to 
changing it to appease the majority either.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Fri, 17 Apr 2015 18:55:48 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> > But there's nothing wrong with this particular default.  It doesn't
> > reduce any functionality.  Users that aren't annoyed enough will learn
> > to live with it; those with higher motivation will discover how to
> > change that soon enough.  There's no real problem here.  Unlike other
> > arguments we had about changing defaults (font-lock, colors, and menus
> > come to mind), this one does not affect any functionality at all.
> 
> The indentation style is one of the obvious bikeshedding topics. I 
> suspect a significant fraction of Emacs users try to make it just right 
> in their config from the start.
> 
> If you think that that value is not a problem, you shouldn't object to 
> changing it to appease the majority either.

No, it means there aren't any good reasons to change the long
established defaults.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> Untabifying (or tabifying) should happen automatically, via project-local
> settings.  There's even a cross-editor specification (as well as an Emacs
> package) for this: http://editorconfig.org/

I think adding support for such cross-editor configs would be good.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 09:12 PM, Stefan Monnier wrote:

> I think adding support for such cross-editor configs would be good.

The said project distributes an Emacs plugin: 
https://github.com/editorconfig/editorconfig-emacs#readme

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 10:26 AM, Eli Zaretskii wrote:

> People I was talking about don't use 8 columns at
> all, neither for the tab width, nor for the offsets.

I think that means that the Emacs defaults don't fit them either.

It would be nice to have a significant group of people for whom the 
defaults serve well.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm not aware of any popular programming language that doesn't work with
> tabs for indentation.

Python is a prominent example (if you use a non-default tab width).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  20322@debbugs.gnu.org
> Date: Fri, 17 Apr 2015 09:55:40 +0200
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > I'm not aware of any popular programming language that doesn't work with
> > tabs for indentation.
> 
> Python is a prominent example (if you use a non-default tab width).

Indeed, and python.el already sets indent-tabs-mode to nil in its mode
function.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 10:55 AM, Andreas Schwab wrote:

> Python is a prominent example (if you use a non-default tab width).

It's just incompatible with the mix of tabs and spaces. 
One-tab-per-indent level works just fine.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

Here's another recent analysis:

http://ukupat.github.io/tabs-or-spaces/

It's different from the previous ones in certain aspects:

- Analyses XX most popular GitHub repositories for a given language.

- Counts percentage of repositories using a given style, not files.

- Uses the algorithm that looks at the lines where indentation changes 
(https://github.com/sindresorhus/detect-indent/), mostly to distinguish 
between different offsets in spaces-based indentation.

https://github.com/ukupat/tabs-or-spaces

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Here's another recent analysis:

  > http://ukupat.github.io/tabs-or-spaces/

Would you please post the actual results of this analysis,
as text?  
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/27/2015 04:52 AM, Richard Stallman wrote:

> Would you please post the actual results of this analysis,
> as text?

C: 32% using tabs, the rest - different offsets using spaces.

C#: 18% using tabs.

C++: 20%.

F#: 0%.

CSS: 20%.

Erlang: 8%.

Go: 98% (the language mandates the use of tabs; the 2% outliers could be 
misdetected repositories, I don't know).

Groovy: 8%.

Haskell: 2%.

Java: 11%.

JavaScript: 13%.

Perl: 23%.

PHP: 29%

Python: 3%

Ruby: 0%

Rust: 3%

Scala: 0%

Shell: 22%

Swift: 6%

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 26 Dec 2015 16:27:55 +0200
> 
> Here's another recent analysis:
> 
> http://ukupat.github.io/tabs-or-spaces/

Given the proliferation of indentation that is default in Visual
Studio, I'm guessing that this has almost nothing to do with people's
preferences, and much more to do with the IDE they are using.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/27/2015 05:50 PM, Eli Zaretskii wrote:

> Given the proliferation of indentation that is default in Visual
> Studio, I'm guessing that this has almost nothing to do with people's
> preferences, and much more to do with the IDE they are using.

If the majority are okay with the defaults, that doesn't mean people are 
okay with *any* defaults. That might only mean that VS picked good defaults.

And it's not like VS supports all (or even most) of the languages on 
this list. Or is the predominant IDE of choice in all those communities. 
You're probably only thinking about the C and C++ results.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Cc: 20322@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 27 Dec 2015 18:10:26 +0200
> 
> On 12/27/2015 05:50 PM, Eli Zaretskii wrote:
> 
> > Given the proliferation of indentation that is default in Visual
> > Studio, I'm guessing that this has almost nothing to do with people's
> > preferences, and much more to do with the IDE they are using.
> 
> If the majority are okay with the defaults, that doesn't mean people are 
> okay with *any* defaults. That might only mean that VS picked good defaults.

I wouldn't go that far.  A product that is forced on many developers
doesn't have to pick good defaults.

> And it's not like VS supports all (or even most) of the languages on 
> this list. Or is the predominant IDE of choice in all those communities. 
> You're probably only thinking about the C and C++ results.

Yes, I thought about C, C++, and C#.  Sorry for not making it clear.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/27/2015 06:28 PM, Eli Zaretskii wrote:

 > forced on many developers

I wouldn't go that far. It might not be your, or mine, preference, but 
VS is generally considered to be a strong part of Microsoft's ecosystem.

 > good defaults.

There are technical reasons to prefer spaces (basically, everything but 
the file size argument), and they are popular as well. Do you have any 
other metrics for "good defaults"?

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

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

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> Here's another recent analysis:
> http://ukupat.github.io/tabs-or-spaces/

Dmitry, as much as I'd like to make TAB insert spaces as the default, this is
a really, REALLY old default, and I don't think we're going to gain anything
major by changing it. We're also going to annoy a huge host of users who
actually need tabs in places where they presently have no configuration
because Emacs just "does what they expect" right now.

So unless there is a really compelling argument for a change at this time, I'd
like to close this as "wontfix".

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/30/2015 06:47 AM, John Wiegley wrote:

> Dmitry, as much as I'd like to make TAB insert spaces as the default, this is
> a really, REALLY old default, and I don't think we're going to gain anything
> major by changing it. We're also going to annoy a huge host of users who
> actually need tabs in places where they presently have no configuration
> because Emacs just "does what they expect" right now.

That's nice.

> So unless there is a really compelling argument for a change at this time, I'd
> like to close this as "wontfix".

Not even going to wait for Richard to "see what he thinks", huh?

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/30/2015 01:48 PM, Dmitry Gutov wrote:
>> So unless there is a really compelling argument for a change at this
>> time

I've got only one argument: the longer we want, the more we continue 
confusing new user coming to the editor (because our "use tabs in 
indentation" setting does not even correspond to what majority of people 
coming from newer editors expect of "use tabs" behavior), and bigger yet 
the "host of users who will get annoyed" will become when we finally 
make that change.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> I've got only one argument: the longer we want, the more we continue
> confusing new user coming to the editor

The longer we wait? This has the default (according to Git) since at least
1991, or 25 years now. Probably much longer, since that commit is just there
to begin the Git history.

What about the needs of existing users who'll become confused by our changing
such an established default on them? When did pleasing the expectations of new
users become a driving force for these types of changes? We can also expect
new users to learn how Emacs does things, too.

What I would *like* is for tabs to insert spaces. But a change like this
affects far more people than just the target audience. We need an excellent
reason to do this.

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

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/30/2015 09:18 PM, John Wiegley wrote:

> The longer we wait? This has the default (according to Git) since at least
> 1991, or 25 years now. Probably much longer, since that commit is just there
> to begin the Git history.

The question is, do we believe it'll have to be changed eventually. If 
not now, then maybe in 10-20 years' time.

> What about the needs of existing users who'll become confused by our changing
> such an established default on them?

What's so confusing about it? They'll see the new behavior (or read 
NEWS), look it up, and customize one variable, if they really want to. 
Unlike new users, they might know the variable already, and they 
certainly know how to customize.

We do change defaults from time to time. Maybe usually not 25-year-old 
defaults, but there are not that many of them left anyway.

> When did pleasing the expectations of new
> users become a driving force for these types of changes?

You're saying this like making the barrier of entry low is a bad thing.

I also want 'emacs -Q' to behave better, and I want to be more 
comfortable in recommending Emacs to other people.

> We can also expect
> new users to learn how Emacs does things, too.

indent-tabs-mode is not "how". It's "what" Emacs does, for predominantly 
historical reasons. Learning about it isn't going to be gratifying, 
unlike many other aspects of Emacs.

> What I would *like* is for tabs to insert spaces. But a change like this
> affects far more people than just the target audience. We need an excellent
> reason to do this.

We don't actually know how many people it's going to be a problem for, 
do we? For all we know, most of the existing users already use spaces 
(the third-party community has standardized on them). And some fraction 
will be indifferent to the change.

There must also be some fraction of users who are not aware of this 
variable, who "mess up" indentation when they edit some existing code 
bases. Statistically speaking, we'll be doing them a favor as well.

Should we poll Reddit users? Only asking on the mailing lists, I'm 
afraid, would unfairly skew the results in favor of _real_ old-timers.

If it were up to me, we'd try changing the default during the 
development cycle of Emacs 26, and see how many complaints we get.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> What's so confusing about it? They'll see the new behavior (or read NEWS),
> look it up, and customize one variable, if they really want to. Unlike new
> users, they might know the variable already, and they certainly know how to
> customize.

I don't believe this is a realistic assessment of what will happen. I just
don't.

> We don't actually know how many people it's going to be a problem for, do
> we? For all we know, most of the existing users already use spaces (the
> third-party community has standardized on them). And some fraction will be
> indifferent to the change.

We don't know too many things, that's the point. You're suggesting an
improvement based on what you think will be an improvement, while causing
difficulties that you don't think will be worse overall.

But why change? What is the driving factor behind this request? Do we know
we're actively losing users because we insert tabs when one presses the TAB
key -- to such an extent that changing this default will keep those users? Is
the change important enough that it's OK to annoy the people (our existing
users) who will be surprised by this change?

Otherwise, it sounds like a theoretical improvement to me, which is not enough
to convince me in matters like this.

> If it were up to me, we'd try changing the default during the development
> cycle of Emacs 26, and see how many complaints we get.

You're welcome to poll, but I don't think you'd reach everyone that needs
reaching. It would, however, at least be a data point.

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

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 12/31/2015 03:17 AM, John Wiegley wrote:

> I don't believe this is a realistic assessment of what will happen. I just
> don't.

I can't imagine it happening otherwise. What else? Tab-fueled users' 
rebellion on Emacs mailing lists?

> We don't know too many things, that's the point. You're suggesting an
> improvement based on what you think will be an improvement, while causing
> difficulties that you don't think will be worse overall.

Yes.

> But why change? What is the driving factor behind this request? Do we know
> we're actively losing users because we insert tabs when one presses the TAB
> key -- to such an extent that changing this default will keep those users? Is
> the change important enough that it's OK to annoy the people (our existing
> users) who will be surprised by this change?

Not losing, no. But probably failing to capture some potential new users.

Likewise, I don't believe we'll lose any users to changing the default. 
We should make Emacs 26 more attractive in other ways anyway, which will 
offset this minor inconvenience.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> I can't imagine it happening otherwise. What else? Tab-fueled users'
> rebellion on Emacs mailing lists?

You're forgetting one thing: One cannot, by casual observation, tell that this
change has been made, since both spaces and tabs are invisible.

I'll tell you a little story. I'm making it up, but it's more probable than
you might think.

Imagine a programmer: we'll call him Joe. Joe works in a Java shop that
mandates the use of tabs in source files. They exist. I've worked in such
shops.

Joe is fine with this, because Emacs inserts tab characters; so he happily
goes about his task. He then sees that Emacs 25.1 comes out, and upgrades.
After all, a newer Emacs just means more good stuff, right?

However, without any indication (who reads the entire NEWS file? I don't), his
TAB key now inserts spaces. Joe doesn't know this, because everything appears
exactly the same.

But the head engineer who reads every diff notices. He storms into Joe's
office, wondering why he's suddenly ignoring the coding standard. Joe has no
idea way, and everyone is mystified for a moment. A quick Google explains the
reason.

Now Joe has lost face, and he's lost some trust in Emacs, because why did we
make such a change? Can't people who don't want tabs just configure *their*
Emacs, he thinks to himself?

And most of all, he'll be upset with me for letting this happen on my watch.

Everyone who uses Emacs and would be made happy by this change, has already
configured their Emacs not to use tabs. So they won't notice. Everyone who
doesn't use Emacs and would be made happy by this change, won't know that
things were different before. So they won't notice.

The people who will, finally, notice, will be everyone like Joe who came to
depend on their environment not changing long-held defaults without notice.

Therefore, I'm closing this as "wontfix". Feel free to re-open when the next
maintainer arrives. Take this as also establishing a general policy of not
changing long-held defaults without compelling reasons, rather than what we
think people will want.

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

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I am pretty sure that using tabs was enabled by default since I first
developed GNU Emacs.  If it were ever changed that would be visible
in the ChangeLog file and in NEWS.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Stefan Monnier]

> Speaking of JavaScript, the defaults do not conform to the current
> convention (2 spaces, no tabs).

Then maybe we should change javascript-mode accordingly.


        Stefan

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Nicolas Petton]

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


Stefan Monnier writes:

>> Speaking of JavaScript, the defaults do not conform to the current
>> convention (2 spaces, no tabs).
>
> Then maybe we should change javascript-mode accordingly.

Indeed, that would be nice.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 08:15 PM, Stefan Monnier wrote:
>> Speaking of JavaScript, the defaults do not conform to the current
>> convention (2 spaces, no tabs).
>
> Then maybe we should change javascript-mode accordingly.

Ok. How about emacs-lisp-mode too, then?

Aside from the Emacs sources (and possibly Org and Gnus), the 
third-party authors have settled on spaces-only indentation: 
https://github.com/bbatsov/emacs-lisp-style-guide/#source-code-layout--organization

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Achim Gratz]

Dmitry Gutov writes:
> Let's do a trial in master, to see how much bitching this results in? :)

If you really want to know, leave your address with that patch and see
how long it takes for the torches and pitchforks to be gathering in
front of your house…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 10:09 PM, Achim Gratz wrote:
>
> If you really want to know, leave your address with that patch and see
> how long it takes for the torches and pitchforks to be gathering in
> front of your house…

I'm sure the pitchfork wielders wouldn't stop at the lack of address and 
their best wishes would already be pouring into my inbox.

No such luck.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Tabs make file smaller.  I just did an experiment.  In lread.c, M-x
untabify changed 139702 characters into 155402 characters, which is
11% bigger.

For subr.el, it was smaller: 200817 characters became 209939, only
4.5% bigger.  However, files.el got 12% bigger.

If most of a git repository is text from various versions of files,
the repository is also likely to get around 10% bigger without tabs,
and now you're talking about 30 meg more.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/15/2015 05:33 AM, Richard Stallman wrote:

> Tabs make file smaller.  I just did an experiment.  In lread.c, M-x
> untabify changed 139702 characters into 155402 characters, which is
> 11% bigger.

Right, I suppose that made sense, back in the day. Thanks for the context.

> For subr.el, it was smaller: 200817 characters became 209939, only
> 4.5% bigger.  However, files.el got 12% bigger.
>
> If most of a git repository is text from various versions of files,
> the repository is also likely to get around 10% bigger without tabs,
> and now you're talking about 30 meg more.

Git compresses the file contents with zlib when storing them. Let's 
compare the compressed versions of files.el:

$ gzip --keep files.el
$ gzip --keep files-notabs.el
$ ls -l files.el.gz files-notabs.el.gz
-rw-rw-r-- 1 gutov gutov 85735 Apr 12 22:26 files.el.gz
-rw-rw-r-- 1 gutov gutov 87471 Apr 15 14:07 files-notabs.el.gz

That's only a 2% increase in compressed size for the file with the 
largest difference. For subr.el, as another example, the difference is 
0.56%.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Wed, 15 Apr 2015 14:18:43 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: 20322@debbugs.gnu.org
> 
> On 04/15/2015 05:33 AM, Richard Stallman wrote:
> 
> > Tabs make file smaller.  I just did an experiment.  In lread.c, M-x
> > untabify changed 139702 characters into 155402 characters, which is
> > 11% bigger.
> 
> Right, I suppose that made sense, back in the day. Thanks for the context.
> 
> > For subr.el, it was smaller: 200817 characters became 209939, only
> > 4.5% bigger.  However, files.el got 12% bigger.
> >
> > If most of a git repository is text from various versions of files,
> > the repository is also likely to get around 10% bigger without tabs,
> > and now you're talking about 30 meg more.
> 
> Git compresses the file contents with zlib when storing them.

Git compresses the objects under .git/, but it doesn't compress the
checked-out files.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/15/2015 07:17 PM, Eli Zaretskii wrote:

> Git compresses the objects under .git/, but it doesn't compress the
> checked-out files.

True, but I'm fairly sure we're not that worried about 30Mb of extra 
uncompressed size, with computers these days.

Extra network traffic would be more of a concern, since there are many 
places in the world with terrible Internet access.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Drew Adams]

> Tabs make file smaller.  I just did an experiment.  In lread.c, M-x
> untabify changed 139702 characters into 155402 characters, which is
> 11% bigger.
> 
> For subr.el, it was smaller: 200817 characters became 209939, only
> 4.5% bigger.  However, files.el got 12% bigger.
> 
> If most of a git repository is text from various versions of files,
> the repository is also likely to get around 10% bigger without tabs,
> and now you're talking about 30 meg more.

That's a consideration, certainly.  But there are others - which is
why we have an option for this. ;-)  (FWIW, I've long turned off
`indent-tabs-mode', personally.)

Note that a (minor) problem for users can arise regardless of how a
user sets the option value: copying and pasting existing code from
a buffer where the option value was non-nil and where tab chars are
thus used for indentation.

When you paste a code snippet that you copied from Emacs (and perhaps
modified) into a help question reply (email, StackExchange, whatever)
- that is, you paste it into a non-Emacs environment - you can find
that the receiving environment does not handle tab chars the way you
might hope.

I find myself "bitten" by this from time to time, even though I've
pretty much learned the habit of using `untabify' first.  (E.g,
copy+yank to another buffer, untabify, then paste to the non-Emacs
application.)

Admittedly, this inconvenience is only minor.  But it is also not
obvious to some users what is going on (i.e., why they see what
they see).

FWIW, whether the default value gets changed or not is not important
to me, as a user.  I just wanted to mention this because I imagine
that there is more and more use of snippets taken from Emacs buffers
and pasted into other environments.  If you forget to use `untabify'
then you can find yourself reformatting the code in the destination
environment - a bother, even if a minor one.

And of course there are some users who might not ever become aware
of `untabify' and who share code in non-Emacs media in order to help
others.  It is a (minor) annoyance to have to reformat pasted code,
and some users might never figure out what is going on (tab chars
are invisible).

If the Emacs source code used only space chars for indenting then,
yes, that code would occupy more space.  But users copying and
pasting it outside of Emacs would not be surprised by the strange
indentation they sometimes get.

And there is lots of 3rd-party code that is based on or derived
from core Emacs code.  Users copying 3rd-party code can thus be
bitten by this gotcha also, even if the 3rd-party maintainer
turns off `indent-tabs-mode' - if s?he does not use `untabify'.

Something to think about perhaps, in any case.	

[It is good that (emacs) `Just Space' mentions `untabify' along
with `indent-tabs-mode'.  It might be good for the Elisp manual
too to mention `untabify' where it documents `indent-tabs-mode'.]

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 14 Apr 2015 05:37:18 +0300
> 
> Is there a reason it's t by default?

History and custom.

> There are different personal preferences for indentation, but spaces are
> used quite a bit more often than tabs, in most languages I'm familiar with.

Each major mode can (and some already do) have its own default.

> Having it be nil by default (but set locally by modes that really need
> it, like makefile-mode) will mean that most users won't have to
> customize it.

If the customizations are due to language guidelines/culture, then
setting this to nil in the major mode is TRT.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 05:17 PM, Eli Zaretskii wrote:

> Each major mode can (and some already do) have its own default.

I can see ruby-mode and texinfo-mode set it to nil, which makes sense, 
but it also makes it harder for the user to configure everything in one 
place. Here's one complaint about it: 
http://emacs.stackexchange.com/a/9385/124

Personally, I'd only do that if the language can't handle the default 
value at all (like it's the case with Makefiles).

> If the customizations are due to language guidelines/culture, then
> setting this to nil in the major mode is TRT.

Maybe, but my point is that going by this logic most major modes would 
need to set it to nil. And then it'll just make sense to make it the 
default.

Note that doing that change in major modes will have pretty much the 
same problem as changing the default: users who got used to the current 
behavior. Only it'll make it harder to revert the change, because 
that'll need to happen in hooks now, or in file-local variables.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Tue, 14 Apr 2015 17:40:17 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> On 04/14/2015 05:17 PM, Eli Zaretskii wrote:
> 
> > Each major mode can (and some already do) have its own default.
> 
> I can see ruby-mode and texinfo-mode set it to nil, which makes sense, 
> but it also makes it harder for the user to configure everything in one 
> place.

But it's simply _wrong_ to configure everything in one place, because
different modes have different conventions.

> > If the customizations are due to language guidelines/culture, then
> > setting this to nil in the major mode is TRT.
> 
> Maybe, but my point is that going by this logic most major modes would 
> need to set it to nil.

I don't understand why.  Can you explain?

> Note that doing that change in major modes will have pretty much the 
> same problem as changing the default: users who got used to the current 
> behavior.

If you only change that in modes which really need that, this problem
won't exist, because, as you yourself said, everybody already
customized these modes to use that value.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/14/2015 06:29 PM, Eli Zaretskii wrote:

> But it's simply _wrong_ to configure everything in one place, because
> different modes have different conventions.

Configuring everything in one place is easy and nice, as long as that's 
what you want to do (and setting indent-tabs-mode for most modes is 
something that a lot of people would prefer).

As long as you can override it for different modes (e.g. in hooks), 
there's no downside.

>> Maybe, but my point is that going by this logic most major modes would
>> need to set it to nil.
>
> I don't understand why.  Can you explain?

Because spaces are more popular than tabs, in most language communities?

> If you only change that in modes which really need that, this problem
> won't exist, because, as you yourself said, everybody already
> customized these modes to use that value.

Yes, and that's not what I'm talking about. JavaScript (or Ruby, or 
Python) don't _really_ need that. They can work with tabs, but most 
users would want to disable tabs in indentation anyway, for cultural, 
personal or organizational reasons.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Eli Zaretskii]

> Date: Tue, 14 Apr 2015 18:48:30 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 20322@debbugs.gnu.org
> 
> >> Maybe, but my point is that going by this logic most major modes would
> >> need to set it to nil.
> >
> > I don't understand why.  Can you explain?
> 
> Because spaces are more popular than tabs, in most language communities?

Is the issue with the default for fundamental-mode or prog-mode, then?
I don't think I care about those, as long as the C/C++ defaults are
kept, and I don't care if the current C/C++ defaults are set in the
C/C++ major mode.

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Philipp Stephani]

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

Dmitry Gutov <dgutov@yandex.ru> schrieb am Di., 14. Apr. 2015 um 17:49 Uhr:

> Because spaces are more popular than tabs, in most language communities?
>

http://stackoverflow.com/research/developer-survey-2015#tech-tabsspaces

"After millennia of heated debate, mercifully, at long last, we have an
answer. Most developers prefer tabs to spaces."

Yes, the data also shows that experienced developers do prefer spaces over
tabs, but the matter is far from clear.

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

bug#20322: 25.0.50; indent-tabs-mode should default to nil

[Dmitry Gutov]

On 04/17/2015 08:22 PM, Philipp Stephani wrote:

> http://stackoverflow.com/research/developer-survey-2015#tech-tabsspaces
> "After millennia of heated debate, mercifully, at long last, we have an
> answer. Most developers prefer tabs to spaces."

Already seen this. I'm inclined to take it with a pound of salt, for 
several reasons:

- Have you participated in it? I'm a heavy SO user, and I've only found 
out about it after the results were published. So, a certain amount of 
bias has to be assumed.

- If the question was "what do you personally prefer", it doesn't 
necessarily reflect the state of the projects the surveyees are actually 
working on.

- For all we know, the majority of respondents came from PHP, VB.NET, or 
some other proprietary platforms which Emacs does not support directly.

> Yes, the data also shows that experienced developers do prefer spaces
> over tabs, but the matter is far from clear.

Some of the less experienced ones might also be answering a different 
question. Look at the subscript (in brackets) here: 
http://jarrodoverson.com/blog/spaces-vs-tabs/