[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#20322: 25.0.50; indent-tabs-mode should default to nil
Date: Fri, 17 Apr 2015 10:26:44 +0300

> Date: Fri, 17 Apr 2015 05:48:08 +0300
> From: Dmitry Gutov <address@hidden>
> CC: address@hidden
> 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).

reply via email to

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