indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Drew Adams]

I'll just mention this reason that `indent-tabs-mode'
should be OFF by default "nowadays".  It's a reason
that wasn't so strong in past years, I think.

With it OFF, code copied from Emacs (vanilla, 3rd-party,
or just code someone tossed off in *scratch*) and pasted
into online forums (StackExchange, Reddit,... whatever),
or emails (not necessarily plain-text), or applications
won't have its apparent indentation changed.  That's a
good thing.

I see this gotcha a lot on emacs.StackExchange, for
instance.  A user copies and pastes some code, and the
indentation is broken (but maybe not super noticeably),
because TAB chars are used here & there for indentation.

That means the user (or someone else) needs to then
notice that apparent change (gotcha), and then edit the
code to give it reasonable indentation.

Even a user (such as myself) who's aware of the gotcha
needs to, e.g., use `M-x untabify' before copying, when
using `emacs -Q'.  Some users don't know `untabify',
and they end up doing the TAB-at-a-time editing outside
Emacs, in the paste destination.  That's a shame.

This is a small reason, perhaps.  But it is one more.
It's an unnecessary bother, IMO.

It's easy enough for some local use (e.g. following the
standards of some organization) to customize the option
to ON.  But that should no longer be the default, IMO.

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Kaushal Modi]

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

On Fri, Sep 3, 2021 at 2:14 PM Drew Adams <drew.adams@oracle.com> wrote:

> I'll just mention this reason that `indent-tabs-mode'
> should be OFF by default "nowadays".
>

+1!!!

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

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

> I'll just mention this reason that `indent-tabs-mode'
> should be OFF by default "nowadays".  It's a reason
> that wasn't so strong in past years, I think.

If that changes, and I miss it in NEWS, I think I'd be in some trouble
by now.

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> If that changes, and I miss it in NEWS, I think I'd be in some trouble
> by now.

Could you elaborate?

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:

> Could you elaborate?

I work in a (partially) Java shop that mandates the use of tabs as
indentation for all C-like languages (which is Java and C++, for the
most part.), where one can get in trouble for checking-in code with
inconsistent tabulation.

Many of us also use Emacs, and I'm sure it would be quite a disruption
for indent-tabs-mode to be made nil by default.

As of late, our superiors have also been trying to convince us to move
to NetBeans, from the current mix of Emacs and IntelliJ products.  If
Emacs were found to be the culprit behind a large influx of bad code, it
could potentially turn that from advice into a mandate, which doesn't
quite appeal to me.

RE: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Drew Adams]

> I work in a (partially) Java shop that mandates the use of tabs as
> indentation for all C-like languages (which is Java and C++, for the
> most part.), where one can get in trouble for checking-in code with
> inconsistent tabulation.
>
> Many of us also use Emacs, and I'm sure it would be quite a disruption
> for indent-tabs-mode to be made nil by default.

In my post that started this thread about
`indent-tabs-mode' default value, I said this:

  It's easy enough for some local use (e.g.
  following the standards of some organization)
  to customize the option to ON.  But that
  should no longer be the default, IMO.

Does that not apply to your context?

Not only an individual, but an organization
can have a need for either no-tabs, all-tabs,
or a mixture.  That is (should be, IIUC) easy
to do, no?

Likewise, for use in any particular context
(e.g. project, directory, etc.).

The default value for _Emacs itself_ is what
the current question is about.  It of course
needs to be easy for anyone and any group to
set the setting they need, for any context.

There's `site-lisp.el'.  There are individual
`custom.el' or init files.  There are mode
hooks.  There are (probably - not familiar)
project-wide hooks or settings via `project.el'
or Projectile or whatever.

Yes, if the Emacs default changed you or your
organization/project/site might need to add
a setting for it.



> As of late, our superiors have also been trying to convince us to move
> to NetBeans, from the current mix of Emacs and IntelliJ products.  If
> Emacs were found to be the culprit behind a large influx of bad code,
> it
> could potentially turn that from advice into a mandate, which doesn't
> quite appeal to me.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

> In my post that started this thread about
> `indent-tabs-mode' default value, I said this:
>
>   It's easy enough for some local use (e.g.
>   following the standards of some organization)
>   to customize the option to ON.  But that
>   should no longer be the default, IMO.
>
> Does that not apply to your context?

It doesn't, for reasons explained below.

> Not only an individual, but an organization
> can have a need for either no-tabs, all-tabs,
> or a mixture.  That is (should be, IIUC) easy
> to do, no?
>
> Likewise, for use in any particular context
> (e.g. project, directory, etc.).
>
> The default value for _Emacs itself_ is what
> the current question is about.  It of course
> needs to be easy for anyone and any group to
> set the setting they need, for any context.

The problem is that we have been relying on Emacs' defaults for a very
long time.  In fact, `indent-tabs-mode' has defaulted to t for as long
as I can remember -- it was that way in Emacs 18 and Epoch.

> There's `site-lisp.el'.  There are individual
> `custom.el' or init files.  There are mode
> hooks.  There are (probably - not familiar)
> project-wide hooks or settings via `project.el'
> or Projectile or whatever.

I don't use project.el or projectile, for the simple reason that I've
never needed to use them.

I don't think it would be simple to get my organization to provide
standard site init files or even dir-locals.  They would rather have us
switch to NetBeans.

> Yes, if the Emacs default changed you or your
> organization/project/site might need to add
> a setting for it.

And if it doesn't change, all this trouble will have been avoided
beforehand.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Dmitry Gutov]

On 05.09.2021 03:37, Po Lu wrote:
> I don't think it would be simple to get my organization to provide
> standard site init files or even dir-locals.  They would rather have us
> switch to NetBeans.

You cannot check in custom .dir-locals.el into the project(s)?

Surely other tools (like NetBeans) have some common configs in the 
repository already.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> You cannot check in custom .dir-locals.el into the project(s)?
> Surely other tools (like NetBeans) have some common configs in the
> repository already.

But NetBeans is NetBeans, and not Emacs.  If someone checks in
.dir-locals.el into a repository, someone reviewing code is sure to
search '.el', and when he finds that '.el' is a file extension for a
programming language named 'Emacs Lisp', whoever checked it in will have
some explaining to do with respect to checking in unapproved code in a
completely foreign language.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> > You cannot check in custom .dir-locals.el into the project(s)?
> > Surely other tools (like NetBeans) have some common configs in the
> > repository already.
>
> But NetBeans is NetBeans, and not Emacs.  If someone checks in
> .dir-locals.el into a repository, someone reviewing code is sure to
> search '.el', and when he finds that '.el' is a file extension for a
> programming language named 'Emacs Lisp', whoever checked it in will have
> some explaining to do with respect to checking in unapproved code in a
> completely foreign language.

Would the situation be improved if we supported editorconfig
configuration files?[1]

Footnotes:
[1]  https://editorconfig.org/

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:

> Would the situation be improved if we supported editorconfig
> configuration files?

Interesting.  I did not previously know about Editorconfig.  I will have
to bring the subject up with my organization sometime, and see how it
goes.

I suppose that means the answer is "no, it wouldn't be improved".
Thanks anyhow.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Interesting.  I did not previously know about Editorconfig.  I will have
> to bring the subject up with my organization sometime, and see how it
> goes.

It seems like someone wrote an Emacs library for it:

    https://github.com/editorconfig/editorconfig-emacs

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Dmitry Gutov]

On 05.09.2021 10:09, Stefan Kangas wrote:
> Po Lu<luangruo@yahoo.com>  writes:
> 
>> Interesting.  I did not previously know about Editorconfig.  I will have
>> to bring the subject up with my organization sometime, and see how it
>> goes.
> It seems like someone wrote an Emacs library for it:
> 
>      https://github.com/editorconfig/editorconfig-emacs

I considered suggesting this, but installing it on every user 
configuration *and* putting an editorconfig file in every project's repo 
seems like more work than simply having every user customize 
indent-tabs-mode to t.

BTW, Po Lu, what do you think of the latter option? If you have a 
company-wide "Emacs Users" channel, on IRC/Slack or whatever, that 
shouldn't take too much effort.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> BTW, Po Lu, what do you think of the latter option? If you have a
> company-wide "Emacs Users" channel, on IRC/Slack or whatever, that
> shouldn't take too much effort.

Well it would certainly be possible, but still an annoyance, compared to
leaving it as-is.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> BTW, Po Lu, what do you think of the latter option? If you have a
>> company-wide "Emacs Users" channel, on IRC/Slack or whatever, that
>> shouldn't take too much effort.
>
> Well it would certainly be possible, but still an annoyance, compared to
> leaving it as-is.

Changing defaults is going to be annoying for some, just as leaving them
as is will continue to be annoying for others. In this case, it would
appear the two groups are about evenly distributed, so either way, some
proportion of users will be annoyed and using it as a reason to change
or not change adds little.

The question is really what would be the expected behaviour for new
users? I don't know how to determine the right answer to that question
or even if there is a right answer.

The only thing which seems important really is how easily the new user
can discover the right setting to get the behaviour they want and how
easily that behaviour can be configured. From memory, that was not as
straight-forward for a new user as it could be (but then again, for me,
that was nearly 30 years ago and things have changed, so perhaps it is
now easier than it once was. I clearly recall it taking some effort to
get the behaviour I wanted when first starting with emacs wrt tabs v
spaces).

I also don't think all defaults are equal and should not be treated as
such. Some defaults feel somewhat arbitrary - indent-tab-mode feels like
one of these. However, other defaults are more critical as they can
impact on more subtle or advanced behaviour and selecting the right
default may impact on how easily users discover the benefits of that
advanced behaviour. 

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Changing defaults is going to be annoying for some, just as leaving them
> as is will continue to be annoying for others. In this case, it would
> appear the two groups are about evenly distributed, so either way, some
> proportion of users will be annoyed and using it as a reason to change
> or not change adds little.
>
> The question is really what would be the expected behaviour for new
> users? I don't know how to determine the right answer to that question
> or even if there is a right answer.
>
> The only thing which seems important really is how easily the new user
> can discover the right setting to get the behaviour they want and how
> easily that behaviour can be configured. From memory, that was not as
> straight-forward for a new user as it could be (but then again, for me,
> that was nearly 30 years ago and things have changed, so perhaps it is
> now easier than it once was. I clearly recall it taking some effort to
> get the behaviour I wanted when first starting with emacs wrt tabs v
> spaces).
>
> I also don't think all defaults are equal and should not be treated as
> such. Some defaults feel somewhat arbitrary - indent-tab-mode feels like
> one of these. However, other defaults are more critical as they can
> impact on more subtle or advanced behaviour and selecting the right
> default may impact on how easily users discover the benefits of that
> advanced behaviour. 

I think the difference between "new users" and "old users" is that old
users already exist, while the "new users" alluded to here do not exist.
An "annoyance" to these "new users" is an annoyance to ghosts -- to
people who have never seen, heard of, or used Emacs.

Further, for as long as I can remember, there has been a section in the
Emacs manual named "Tabs vs. Spaces".  Any Emacs user, who has
presumably read the manual before using Emacs, should know about the
option indent-tabs-mode.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Changing defaults is going to be annoying for some, just as leaving them
>> as is will continue to be annoying for others. In this case, it would
>> appear the two groups are about evenly distributed, so either way, some
>> proportion of users will be annoyed and using it as a reason to change
>> or not change adds little.
>>
>> The question is really what would be the expected behaviour for new
>> users? I don't know how to determine the right answer to that question
>> or even if there is a right answer.
>>
>> The only thing which seems important really is how easily the new user
>> can discover the right setting to get the behaviour they want and how
>> easily that behaviour can be configured. From memory, that was not as
>> straight-forward for a new user as it could be (but then again, for me,
>> that was nearly 30 years ago and things have changed, so perhaps it is
>> now easier than it once was. I clearly recall it taking some effort to
>> get the behaviour I wanted when first starting with emacs wrt tabs v
>> spaces).
>>
>> I also don't think all defaults are equal and should not be treated as
>> such. Some defaults feel somewhat arbitrary - indent-tab-mode feels like
>> one of these. However, other defaults are more critical as they can
>> impact on more subtle or advanced behaviour and selecting the right
>> default may impact on how easily users discover the benefits of that
>> advanced behaviour. 
>
> I think the difference between "new users" and "old users" is that old
> users already exist, while the "new users" alluded to here do not exist.
> An "annoyance" to these "new users" is an annoyance to ghosts -- to
> people who have never seen, heard of, or used Emacs.
>

Regardless of debate on whether there are new users or not, evidence
indicates those who want spaces and those who want tabs are roughly
equally divided. Therefore, half those 'old' users are required to
change the setting regardless of what the default is. All your argument
seems to come down to is that your happy with the status quo and don't
want it to change because that is in-line with your preference. That is
fine, but is no stronger an argument than arguing for the default to be
changed - in this case, changing or not changing based solely on level
of annoyance is simply insufficient. 

> Further, for as long as I can remember, there has been a section in the
> Emacs manual named "Tabs vs. Spaces".  Any Emacs user, who has
> presumably read the manual before using Emacs, should know about the
> option indent-tabs-mode.

I would suggest very few people have ever fully read the manual before
using Emacs. Besides, the best way to read the manual is with Emacs, so
you already have a 'chicken and egg' situations. Furthermore, the fact
the default was already at the setting you wanted would indicate you
never needed to find this information and therefore are not in a strong
position to argue whether that is easy or not. On the other hand, when I
started using Emacs I did need to change the default and I do recall it
took some effort to work out how to do that - enough effort to be
annoying. As already stated, annoyance is an insufficient criteria in
this case because the two sides are roughly equal. Understanding the
expectations of new users may change that balance and is therefore worth
considering.

You will find it annoying if the default changes, I find it annoying if
it doesn't - we cancel each other out. Arguing for either case based
solely on level of annoyance is pointless. 

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Regardless of debate on whether there are new users or not, evidence
> indicates those who want spaces and those who want tabs are roughly
> equally divided. Therefore, half those 'old' users are required to
> change the setting regardless of what the default is. All your
> argument seems to come down to is that your happy with the status quo
> and don't want it to change because that is in-line with your
> preference. That is fine, but is no stronger an argument than arguing
> for the default to be changed - in this case, changing or not changing
> based solely on level of annoyance is simply insufficient.

So, if the default is changed, the other half of the "roughly equally
divided" portion of the userbase will also have to change their
settings, which means the entire userbase will have changed that
settings.

Which is more pleasant?  To have the half of the userbase who have, for
the most part, already done so, change their settings, or to have the
other half of the userbase who have mostly not done so change their
settings?

> I would suggest very few people have ever fully read the manual before
> using Emacs. Besides, the best way to read the manual is with Emacs,
> so you already have a 'chicken and egg' situations. Furthermore, the
> fact the default was already at the setting you wanted would indicate
> you never needed to find this information and therefore are not in a
> strong position to argue whether that is easy or not. On the other
> hand, when I started using Emacs I did need to change the default and
> I do recall it took some effort to work out how to do that - enough
> effort to be annoying. As already stated, annoyance is an insufficient
> criteria in this case because the two sides are roughly
> equal. Understanding the expectations of new users may change that
> balance and is therefore worth considering.

The manual is available in print, and downloadable online in HTML,
PostScript and PDF format.  While the Emacs Info reader may be
convenient, there is nothing preventing users from reading the manual in
any of those other formats, or even an alternative Info reader, before
reading the manual in Emacs, so I don't see how that is a problem.

Emacs also has an Easy Customization interface.  Even without reading
the manual, one can simply search "indent tabs" inside the Easy
Customization interface, and reach the option.

If that fails, an apropos for 'indent tabs' turns up indent-tabs-mode as
the first result.

And if ignorance of the manual really is a problem, then how about
finding a way to publicize the manual?  For instance, a weekly post
about the manual in comp.emacs, or r/emacs, or whatever happens to be
popular ATM.

There also seem to be cross-editor solutions for configuring these
options on a per-file or a per-project basis, such as editor-config.  If
Emacs gains support for these solutions, they could potentially
alleviate these problems in their entirety.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Regardless of debate on whether there are new users or not, evidence
>> indicates those who want spaces and those who want tabs are roughly
>> equally divided. Therefore, half those 'old' users are required to
>> change the setting regardless of what the default is. All your
>> argument seems to come down to is that your happy with the status quo
>> and don't want it to change because that is in-line with your
>> preference. That is fine, but is no stronger an argument than arguing
>> for the default to be changed - in this case, changing or not changing
>> based solely on level of annoyance is simply insufficient.
>
> So, if the default is changed, the other half of the "roughly equally
> divided" portion of the userbase will also have to change their
> settings, which means the entire userbase will have changed that
> settings.
>
> Which is more pleasant?  To have the half of the userbase who have, for
> the most part, already done so, change their settings, or to have the
> other half of the userbase who have mostly not done so change their
> settings?
>

Flawed argument. Those who have set it don't have to do anything. They
could remove it to slightly reduce their config size, but they could
just as easily do nothing with no impact. 

>> I would suggest very few people have ever fully read the manual before
>> using Emacs. Besides, the best way to read the manual is with Emacs,
>> so you already have a 'chicken and egg' situations. Furthermore, the
>> fact the default was already at the setting you wanted would indicate
>> you never needed to find this information and therefore are not in a
>> strong position to argue whether that is easy or not. On the other
>> hand, when I started using Emacs I did need to change the default and
>> I do recall it took some effort to work out how to do that - enough
>> effort to be annoying. As already stated, annoyance is an insufficient
>> criteria in this case because the two sides are roughly
>> equal. Understanding the expectations of new users may change that
>> balance and is therefore worth considering.
>
> The manual is available in print, and downloadable online in HTML,
> PostScript and PDF format.  While the Emacs Info reader may be
> convenient, there is nothing preventing users from reading the manual in
> any of those other formats, or even an alternative Info reader, before
> reading the manual in Emacs, so I don't see how that is a problem.
>

The real problem is that people simply don't read the manual before
using the editor. If you did, that makes you quite unusual. What most
people will do is use the editor and then turn to the manual when they
have problems. 

> Emacs also has an Easy Customization interface.  Even without reading
> the manual, one can simply search "indent tabs" inside the Easy
> Customization interface, and reach the option.
>
> If that fails, an apropos for 'indent tabs' turns up indent-tabs-mode as
> the first result.
>
> And if ignorance of the manual really is a problem, then how about
> finding a way to publicize the manual?  For instance, a weekly post
> about the manual in comp.emacs, or r/emacs, or whatever happens to be
> popular ATM.
>

All the above paragraphs tell me is that changing the setting is
trivial. this also means that whatever the default is really doesn't
matter as the level of annoyance associated with having to change it is
minimal regardless of what the default is. Again, staying with the
current default based on a argument of annoyance is irrelevant. Other
criteria are needed in order to make the decision anything more than
arbitrary.

There is also the problem of familiarity with all of the above. If you
are use to Emacs and know all of this, yes it is easy and fairly
trivial. If your not, it can be hard. The defaults are primarily for
this category, not for experienced users IMO. I have little sympathy for
arguments against change based solely on annoyance for experienced
users. As you point out, once you know about the customization
interface, appropos etc, making the change is trivial. For new users,
not so much.  

I think it is also difficult to argue not to change a default and at the
same time argue that it is easy for the user to change it if they don't
like the default. 

> There also seem to be cross-editor solutions for configuring these
> options on a per-file or a per-project basis, such as editor-config.  If
> Emacs gains support for these solutions, they could potentially
> alleviate these problems in their entirety.


Things like support for editorconfig are a good idea. To what extent
editorconfig will support the more subtle interplay between how options
are defined for different editors is another issue. In theory, I think
it could be a useful addition/extension. I guess there could be some
subtle issues to consider though - for example, an editorconfig which is
changing things which the user does not want changed and being able to
efficiently track that source of change.  

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Flawed argument.  Those who have set it don't have to do
> anything. They could remove it to slightly reduce their config size,
> but they could just as easily do nothing with no impact.

The point is, if you had your way, those who have not set it will have
to set it, which means the entire userbase will have to have set it at
some point.  How is that advantageous over leaving the status quo
intact?

How about this: create a new option `indent-tabs-mode-use-new-default',
which changes the default value of indent-tabs-mode, and can be enabled
by those who wish to have the new default value?

> The real problem is that people simply don't read the manual before
> using the editor.  If you did, that makes you quite unusual. What most
> people will do is use the editor and then turn to the manual when they
> have problems.

Perhaps you did not, but what most people do when confronted by a new
tool used for a certain task is to look up the relevant documentation on
the tool, and to give it a thorough reading, before actually using the
tool.

> All the above paragraphs tell me is that changing the setting is
> trivial.

Changing most settings in Emacs is trivial, but that is really outside
the scope of this discussion.

> This also means that whatever the default is really doesn't matter as
> the level of annoyance associated with having to change it is minimal
> regardless of what the default is.  Again, staying with the current
> default based on a argument of annoyance is irrelevant.  Other
> criteria are needed in order to make the decision anything more than
> arbitrary.

The question here is not primarily one of annoyance, but benefit.  And
strong wording will not change the fact that annoying existing users is
not beneficiary to a piece of software, as a fantastic example of how
not to develop software.

> There is also the problem of familiarity with all of the above. If you
> are use to Emacs and know all of this, yes it is easy and fairly
> trivial.  If your not, it can be hard.  The defaults are primarily for
> this category, not for experienced users IMO.

I wouldn't agree with categorizing the defaults this way.  IMO, the
defaults are intended for the people who value their time and energy,
and do actual work with their tools, which is a task that cannot
tolerate interruptions from changes made at a whim.  Especially a change
to an option as fundamental as indent-tabs-mode.

They also make for a welcome change from some of the absurdities at
present.  For example, there is a third-party package archive named
"MELPA", which ships packages up-to-date by the hour.  After struggling
with the sheer amount of effort required to keep Emacs usable with
packages from that archive, and failing, removing it from the package
archive list has turned out to be quite refreshing.

> As you point out, once you know about the customization interface,
> appropos etc, making the change is trivial.  For new users, not so
> much.

Apropos and Easy Customization are concepts very wide-spread in the real
world and other software, and are hardly specific to Emacs.  If someone
is confronted with a problem, and even if he has not actually read the
manual (which I doubt is usually the case), he will select "Help" from
the menu bar, and see options presented to him in a familiar manner.  As
a matter of fact, "apropos" as a word first appeared in 1668.

> I think it is also difficult to argue not to change a default and at
> the same time argue that it is easy for the user to change it if they
> don't like the default.

It is not difficult to argue for that position, because that position
means it is ensured that only people who have an actual need to change
the option have to change it.

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Flawed argument.  Those who have set it don't have to do
>> anything. They could remove it to slightly reduce their config size,
>> but they could just as easily do nothing with no impact.
>
> The point is, if you had your way, those who have not set it will have
> to set it, which means the entire userbase will have to have set it at
> some point.  How is that advantageous over leaving the status quo
> intact?
>

first off, I'm not arguing to have it change. I'm arguing against the
argument that changing it is too annoying for those who like the status
quo. Your argument was that it would be annoying if it was changed. Fair
enough, but that is not sufficient reason to consider changing it should
there be other arguments to support the change (such as perhaps being
more in-line with expectations of the next generation of users). 

As to the advantage, well that will depend on the arguments in support
of changing it. If it does change, yes, initially you will have a user
base where most have had to set it one way or the other at some point.
However, that will change over time and if the new default is the
correct change, over time it will likely be less people requiring to
make the change than is the case with the current situation. 

> How about this: create a new option `indent-tabs-mode-use-new-default',
> which changes the default value of indent-tabs-mode, and can be enabled
> by those who wish to have the new default value?

By definition, that would mean it isn't the default value. That would be
a pointless additional option which would further confuse the situation.
Worst idea yet!

>
>> The real problem is that people simply don't read the manual before
>> using the editor.  If you did, that makes you quite unusual. What most
>> people will do is use the editor and then turn to the manual when they
>> have problems.
>
> Perhaps you did not, but what most people do when confronted by a new
> tool used for a certain task is to look up the relevant documentation on
> the tool, and to give it a thorough reading, before actually using the
> tool.
>

Definitely not my experience and I expect if that was the norm, we would
never have coined RTFM.

>> All the above paragraphs tell me is that changing the setting is
>> trivial.
>
> Changing most settings in Emacs is trivial, but that is really outside
> the scope of this discussion.
>

I disagree. The premise of your argument was that changing the default
would be annoying for you. surely how easy it is to configure to the
previous behaviour has baring on that level of annoyance. 

>> This also means that whatever the default is really doesn't matter as
>> the level of annoyance associated with having to change it is minimal
>> regardless of what the default is.  Again, staying with the current
>> default based on a argument of annoyance is irrelevant.  Other
>> criteria are needed in order to make the decision anything more than
>> arbitrary.
>
> The question here is not primarily one of annoyance, but benefit.  And
> strong wording will not change the fact that annoying existing users is
> not beneficiary to a piece of software, as a fantastic example of how
> not to develop software.

However, continued growth with new users is fundamental to keeping the
project viable. Anything which can reduce friction for new users and
which does not have a detrimental impact on functionality is beneficial.

I think the annoyance level from this change is being vastly over
stated. As already agreed, changing the value is trivial, especially for
an experienced user. I would agree changing a default is not something
which should be done lightly - it needs to be a considered change. At
the same time, things do change and not changing a default because some
users will be annoyed is not sufficient justification in itself. If user
expectations have evolved and a particular default is no longer
appropriate, then it should be changed. It is up to those who want the
change to present their arguments for change and for those who want the
status quo to argue the contrary. My position is that not changing it
solely because of annoyance and because that is the way it has always
been is not sufficient. 

>
>> There is also the problem of familiarity with all of the above. If you
>> are use to Emacs and know all of this, yes it is easy and fairly
>> trivial.  If your not, it can be hard.  The defaults are primarily for
>> this category, not for experienced users IMO.
>
> I wouldn't agree with categorizing the defaults this way.  IMO, the
> defaults are intended for the people who value their time and energy,
> and do actual work with their tools, which is a task that cannot
> tolerate interruptions from changes made at a whim.  Especially a change
> to an option as fundamental as indent-tabs-mode.
>

I think categorising the suggestion to change this default as a whim is
unreasonable. Emacs has a long tradition of being very conservative when
it comes to changing defaults and does not make changes 'on a whim'.
Your statement implies those who do want the change don't value their
time and energy or don't do real work with the tool, which I think is
unreasonable. From the data we do have, we know the division is fairly
evenly divided. This mean just as many people who are using the tool for
real work are forced to use their time and energy to change the default.
This is the big weakness in the status quo argument. As many people
disadvantaged by the change will be advantaged by it. 

> They also make for a welcome change from some of the absurdities at
> present.  For example, there is a third-party package archive named
> "MELPA", which ships packages up-to-date by the hour.  After struggling
> with the sheer amount of effort required to keep Emacs usable with
> packages from that archive, and failing, removing it from the package
> archive list has turned out to be quite refreshing.
>

and yet many people are able to use it just fine. It all depends on what
you need and how you use it. I use Emacs daily - it is my main interface
and as a blind programmer, if it stops working, it is a big problem. I
rely heavily on Emacspeak as that is what provides my speech feedback.
This also means my Emacs configuration is fairly large and complex. I do
prefer packages from ELPA and nonGNU ELPA, but I do also use packages
from MELPA and have had no significant problems. I write code for a
living and cannot afford to have a non-working Emacs, even for a short
time, so I've developed strategies which deal with the risks associated
with upgrades and updates - whether that be with Emacs, Emacspeak, ELPA,
MELPA or whatever. However, this is totally different from the proposal
to change the default of indent-tab-mode.  

>> As you point out, once you know about the customization interface,
>> appropos etc, making the change is trivial.  For new users, not so
>> much.
>
> Apropos and Easy Customization are concepts very wide-spread in the real
> world and other software, and are hardly specific to Emacs.  If someone
> is confronted with a problem, and even if he has not actually read the
> manual (which I doubt is usually the case), he will select "Help" from
> the menu bar, and see options presented to him in a familiar manner.  As
> a matter of fact, "apropos" as a word first appeared in 1668.
>
>> I think it is also difficult to argue not to change a default and at
>> the same time argue that it is easy for the user to change it if they
>> don't like the default.
>
> It is not difficult to argue for that position, because that position
> means it is ensured that only people who have an actual need to change
> the option have to change it.

Which is about as many as those who don't. If the numbers were more
skewed towards one value or the other, selecting the default would be
straight-forward. From the data we have, we know it is pretty evenly
split - possibly leaning slightly more towards spaces rather than tabs.
Based solely on that, the default is somewhat arbitrary - no matter
which value is selected as the default, as many will need to change it
as don't. To identify what is the most appropriate setting needs to
consider broader perspectives. For example, considering what the
expectation is for new users or comparing to what other editors have as
default as this may inform what expectations new users would have.

I don't see any benefit in continuing this thread. My position is pretty
simple - I don't think in this case it matters because the two sides are
about evenly split and changing from whatever default is trivial. It
will have next to no impact on me if it changes or if it doesn't.
Provided the change is clearly communicated, I don't think most uses
will have an issue with the change.

I acknowledge your against the change and are unlikely to alter your
position. This is the nature of religious wars. It certainly isn't an
issue worth dying in the gutter over. 

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> I don't see any benefit in continuing this thread. My position is pretty
> simple - I don't think in this case it matters because the two sides are
> about evenly split and changing from whatever default is trivial. It
> will have next to no impact on me if it changes or if it doesn't.
> Provided the change is clearly communicated, I don't think most uses
> will have an issue with the change.
>
> I acknowledge your against the change and are unlikely to alter your
> position. This is the nature of religious wars. It certainly isn't an
> issue worth dying in the gutter over. 

Fair enough.  Let's agree to disagree :D

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[chad]

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

On Mon, Sep 6, 2021 at 2:33 AM Tim Cross <theophilusx@gmail.com> wrote:

> > Perhaps you did not, but what most people do when confronted by a new
> > tool used for a certain task is to look up the relevant documentation on
> > the tool, and to give it a thorough reading, before actually using the
> > tool.
> >
>
> Definitely not my experience and I expect if that was the norm, we would
> never have coined RTFM.
>

This particular experience is quite old at this point, but I had occasion
to both support Emacs and also be part of the user support system for MIT
students for well over a decade. During that time I helped many hundreds of
people use emacs without reading the manual, much less a thorough reading.
My loose contacts there suggest that the situation is still pretty much the
same.

Hope that helps,
~Chad

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

RE: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Drew Adams]

> a section in the Emacs manual named "Tabs vs. Spaces".

FWIW, there's also this Emacs Wiki page, which includes
some discussion about this topic.  (I had nothing to do
with this page, BTW - just mentioning it.)

https://www.emacswiki.org/emacs/TabsAreEvil

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Tim Cross]

Drew Adams <drew.adams@oracle.com> writes:

> I'll just mention this reason that `indent-tabs-mode'
> should be OFF by default "nowadays".  It's a reason
> that wasn't so strong in past years, I think.
>
> With it OFF, code copied from Emacs (vanilla, 3rd-party,
> or just code someone tossed off in *scratch*) and pasted
> into online forums (StackExchange, Reddit,... whatever),
> or emails (not necessarily plain-text), or applications
> won't have its apparent indentation changed.  That's a
> good thing.
>
> I see this gotcha a lot on emacs.StackExchange, for
> instance.  A user copies and pastes some code, and the
> indentation is broken (but maybe not super noticeably),
> because TAB chars are used here & there for indentation.
>
> That means the user (or someone else) needs to then
> notice that apparent change (gotcha), and then edit the
> code to give it reasonable indentation.
>
> Even a user (such as myself) who's aware of the gotcha
> needs to, e.g., use `M-x untabify' before copying, when
> using `emacs -Q'.  Some users don't know `untabify',
> and they end up doing the TAB-at-a-time editing outside
> Emacs, in the paste destination.  That's a shame.
>
> This is a small reason, perhaps.  But it is one more.
> It's an unnecessary bother, IMO.
>
> It's easy enough for some local use (e.g. following the
> standards of some organization) to customize the option
> to ON.  But that should no longer be the default, IMO.

Yes, I would agree. I also find it a much less common setting these
days. The only time I come across the need to use tabs instead of spaces
tends to be with older projects and as you point out, it is simple to
set the default to tabs for those on a per project basis. 

Gitlab Migration

[Daniel Fleischer]

[-- Attachment #1: Type: text/html, Size: 4341 bytes --]

Re: Gitlab Migration

[Philip Kaludercic]

Hi,

Daniel Fleischer <danflscr@gmail.com> writes:

> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab. I started reading the relevant threads and I'm not sure
> where the issue stands today. Let me recap the benefits:
>
> 1 The need for new people to join the community and help. Newer
>  (younger) people will be more familiar with the newer VC platforms
>  (github/lab and similar). These are not only developers but regular
>  users who want to report an issue (bug) or suggest a feature.

Shouldn't it be easier to send an email than create an account, navigate
some web UI and fill in some form? The same goes for
patches. Git{Lab,Hub} usually requires leaving the development context,
to prepare a patch online, that requires "forking", more navigation and
more fora. Just today I tried preparing a "pull request" on GitLab and
didn't manage to do so, because it insisted on merging the commit into
my own repository, no matter what I did. Just attaching a git patch
seems much easier.

>  Lowering the bar for participation is the key to growing Emacs and
>  the community.

I think that showing people that they biases against mailing list
development might be illegitimate would be a viable alternative.

> 2 Having the code + issues + discussions in the same place as opposed
>  to now, where the code and discussions (lists) are in 3 different
>  places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
>  modern VC system, one can jump easily between issues, discussions,
>  code commits back and forth easily as opposed to now, where if it's a
>  bug you can use its number to search lists and commits messages but
>  if it's a discussion, it's not "connected" to anything.

Correct me if I am wrong, but all the discussions are at least mirrored
on the mailing lists. Savannah is just for project management and the
GNU bug tracker uses the mailing list too. It is more uniform too, as
everything is just a mail-message, not part of a forcefully linearized
thread. Commenting on a issue, "pull request" or a patch is always just
responding to a message.

That being said, I wouldn't mind prettier web interface for the mailing
list (I think that the Guix project is doing well on that front).

> Possible issue:
>
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website. Another approach is using the wonderful
>  Magit and Forge packages. Forge currently is lacking the discussions
>  feature but has a very good git + pull-requests + org-mode
>  integration abilities.

I remember Sourceforge being suggested as an alternative to Gitlab, but
the software is currently still in a beta stage (AFAIR).

> 2 Changing processes, how people operate. Whether it's the technical
>  aspect of a pull-request approval vs. patch submission to the more
>  conceptual change of dealing with "issues" representing bugs, ideas,
>  feature requests or general discussions instead of mailing lists.
>  These changes shouldn't be too disruptive. However I do believe a
>  small price has to be paid in order to go from one local minima of
>  effort in a given practice to another, hopefully better local minima.
>
> Does this describe well the current situation?
> What areas need attention in order to facilitate the change?
>
> Thanks for any feedback.
>
> Daniel Fleischer
>

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Daniel Fleischer]

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

Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:

> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.

I explicitly don't want to get into questions of what is easier because
we can't answer these objectively. Each person is used to something else
which they consider easier, where the getting used to is a long
mental process depending on personal preference and outside influence.

I can say objectively that one form of workflow is more popular than
another so people would be more familiar with it.

*Daniel Fleischer*

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Fri, 27 Aug 2021 10:00:10 +0300
> Cc: emacs-devel@gnu.org
> 
> Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:
> 
> > Shouldn't it be easier to send an email than create an account, navigate
> > some web UI and fill in some form? The same goes for
> > patches. Git{Lab,Hub} usually requires leaving the development context,
> > to prepare a patch online, that requires "forking", more navigation and
> > more fora. Just today I tried preparing a "pull request" on GitLab and
> > didn't manage to do so, because it insisted on merging the commit into
> > my own repository, no matter what I did. Just attaching a git patch
> > seems much easier.
> 
> I explicitly don't want to get into questions of what is easier because
> we can't answer these objectively. Each person is used to something else
> which they consider easier, where the getting used to is a long
> mental process depending on personal preference and outside influence.

Agreed.  We don't need to force everyone to use a single workflow.  We
should have a platform that supports reasonably well the different
popular workflows.

Re: Gitlab Migration

[Stefan Monnier]

> Agreed.  We don't need to force everyone to use a single workflow.
> We should have a platform that supports reasonably well the different
> popular workflows.

AFAIK SourceHut is the only project which explicitly aims to provide
full and convenient support for both web and email control, which makes
it the obvious&natural choice for Emacs, IMO.


        Stefan

Re: Gitlab Migration

[Dmitry Gutov]

On 27.08.2021 17:33, Stefan Monnier wrote:
>> Agreed.  We don't need to force everyone to use a single workflow.
>> We should have a platform that supports reasonably well the different
>> popular workflows.
> 
> AFAIK SourceHut is the only project which explicitly aims to provide
> full and convenient support for both web and email control, which makes
> it the obvious&natural choice for Emacs, IMO.

 From what I have seen of it, it's email-first, and far from "full and 
convenient support for ... web".

For example, those quality-of-life features that Gitlab has in the 
browser which I previously figured would be difficult to translate  to 
email (the code review workflow, with inline comments and updates from 
the branch; automatically updated CI indicators and links to builds; 
editing of messages) are predictably absent.

Of course, it should still be a significant step forward compared to the 
current situation.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Aug 2021 00:09:41 +0300
> 
>  From what I have seen of it, it's email-first, and far from "full and 
> convenient support for ... web".
> 
> For example, those quality-of-life features that Gitlab has in the 
> browser which I previously figured would be difficult to translate  to 
> email (the code review workflow, with inline comments and updates from 
> the branch; automatically updated CI indicators and links to builds; 
> editing of messages) are predictably absent.

That sounds worrisome.

Can you tell how did you see what SourceHut offers in this department,
so others (myself included) could have a look?  I cannot find any
documentation of the features.

> Of course, it should still be a significant step forward compared to the 
> current situation.

Can you elaborate why you think so, given the lack of the above
features?

Re: Gitlab Migration

[Dmitry Gutov]

On 28.08.2021 09:00, Eli Zaretskii wrote:
>> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 28 Aug 2021 00:09:41 +0300
>>
>>   From what I have seen of it, it's email-first, and far from "full and
>> convenient support for ... web".
>>
>> For example, those quality-of-life features that Gitlab has in the
>> browser which I previously figured would be difficult to translate  to
>> email (the code review workflow, with inline comments and updates from
>> the branch; automatically updated CI indicators and links to builds;
>> editing of messages) are predictably absent.
> 
> That sounds worrisome.
> 
> Can you tell how did you see what SourceHut offers in this department,
> so others (myself included) could have a look?  I cannot find any
> documentation of the features.

I used my web browser, mostly following the links others submitted in 
this discussion (and then followed some links from there), also did some 
educated guessing (and turned out to be wrong on the subject of CI 
indicators and links to builds).

The video Drew posted yesterday (see the response to it I sent just now) 
has also been illuminating.

I haven't looked too deeply or tried to work with it personally, so my 
impressions are of course superficial and biased. Perhaps somebody wants 
to create a test project on sr.ht and invite a bunch of us to 
collaborate? Or set up a private installation like emba.gnu.org, with 
the same end goal.

>> Of course, it should still be a significant step forward compared to the
>> current situation.
> 
> Can you elaborate why you think so, given the lack of the above
> features?

It seems to provide a nicer/better bug tracker and mailing list archive 
viewers than the ones we already have. With unified views, better 
searching, tagging and perhaps even an ability to write messages from 
the browser (which is certain to appeal to some newcomers). Maybe also 
features like subscribe/unsubscribe to a discussion, though that looks 
less certain.

We have generally routed around those problems (by doing extra manual 
work, usually; or asking others to do it), but that haven't made them go 
away. E.g. recall at the beginning of this thread you suggested the 
author would do a search for the previous thread on the subject and then 
find the gitlab issue there. I'm guessing it was, at least in part, due 
to the search on lists.gnu.org being not that great.

Of course, whether this promise will hold up (with good performance and 
few bugs) remain to be seen, but Drew has a good track record.

Overall, if we finally accept that neither UI familiarity (for new 
users) nor workflow familiarity (for new contributors) are a priority 
for the Emacs project, this might a reasonable option to migrate to. I 
just wonder whether we'd have to do another migration in 5-10 years, 
with the natural change in Emacs contributor base.

Re: Gitlab Migration

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

  >  perhaps even an ability to write messages from 
  > the browser (which is certain to appeal to some newcomers).

It is fine to offer this feature, provided the message turns into
email so that we can receive it in our inboxes.  Is that the case?

  > Overall, if we finally accept that neither UI familiarity (for new 
  > users) nor workflow familiarity (for new contributors) are a priority 
  > for the Emacs project, this might a reasonable option to migrate to.

They count for something, but less than many other countervaling values.
This is meaningful at the "all else being equal" level.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Gitlab Migration

[Dmitry Gutov]

On 30.08.2021 05:58, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    >  perhaps even an ability to write messages from
>    > the browser (which is certain to appeal to some newcomers).
> 
> It is fine to offer this feature, provided the message turns into
> email so that we can receive it in our inboxes.  Is that the case?

That's the idea.

>    > Overall, if we finally accept that neither UI familiarity (for new
>    > users) nor workflow familiarity (for new contributors) are a priority
>    > for the Emacs project, this might a reasonable option to migrate to.
> 
> They count for something, but less than many other countervaling values.
> This is meaningful at the "all else being equal" level.

Yes, as is now apparent from multiple arguments around the subject, 
appealing to newcomers (and/or trying to adopt contemporary usability 
practices) is of much lesser priority than, say, making sure that each 
key binding that has been with us for a number of years, is left 
unchanged for ever. We hate to risk inconveniencing existing users.

Re: Gitlab Migration

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

  > Yes, as is now apparent from multiple arguments around the subject, 
  > appealing to newcomers (and/or trying to adopt contemporary usability 
  > practices) is of much lesser priority than, say, making sure that each 
  > key binding that has been with us for a number of years, is left 
  > unchanged for ever. We hate to risk inconveniencing existing users.

Please don't bring sarcasm into our discussions.  It tends to make the
discussion more acrimonious and make agreement more difficult.
Any point can be made without sarcasm, and it's likely to arouse
less resistance that way.

See https://gnu.org/philosophy/kind-communication.html.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Gitlab Migration

[Dmitry Gutov]

On 31.08.2021 06:09, Richard Stallman wrote:
>    > Yes, as is now apparent from multiple arguments around the subject,
>    > appealing to newcomers (and/or trying to adopt contemporary usability
>    > practices) is of much lesser priority than, say, making sure that each
>    > key binding that has been with us for a number of years, is left
>    > unchanged for ever. We hate to risk inconveniencing existing users.
> 
> Please don't bring sarcasm into our discussions.  It tends to make the
> discussion more acrimonious and make agreement more difficult.
> Any point can be made without sarcasm, and it's likely to arouse
> less resistance that way.

I wasn't really that sarcastic. The above is literally my observations 
on our decision-making in the area.

Re: Gitlab Migration

[John Yates]

On Tue, Aug 31, 2021 at 7:50 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> appealing to newcomers (and/or trying to adopt contemporary usability
> practices) is of much lesser priority than, say, making sure that each
> key binding that has been with us for a number of years, is left
> unchanged for ever. We hate to risk inconveniencing existing users.

I agree with Dmitry.  I would love to see the community be
more open to change, be it key bindings or new workflows.

I have been using Emacs since Lucid-Emacs at Apollo
Computer in the mid-1980s.  I have a massive .init file.
Still, I welcome change and evolution.  Other technologies
that I use on a daily basis evolve, even those for which I
develop muscle memory (e.g. my smart phone).  I accept
such change and can even acknowledge that some of it
represents progress over time.  Other changes I put up
with just to track the herd and not be left behind.

I wish that we were not so determined to proudly go it alone.
Our stances often remind me of this ditty:

    Here lies the body of William Jay,
    who died maintaining his right of way.
    He was right as he sped along—
    but he's just as dead as if he'd been wrong.

Any changes that can attract new blood have my vote.

Re: Gitlab Migration

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Tue, 31 Aug 2021 12:21:40 -0400
> Cc: Richard Stallman <rms@gnu.org>, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com, 
> 	Philip Kaludercic <philipk@posteo.net>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I have been using Emacs since Lucid-Emacs at Apollo
> Computer in the mid-1980s.  I have a massive .init file.
> Still, I welcome change and evolution.  Other technologies
> that I use on a daily basis evolve, even those for which I
> develop muscle memory (e.g. my smart phone).  I accept
> such change and can even acknowledge that some of it
> represents progress over time.  Other changes I put up
> with just to track the herd and not be left behind.
> 
> I wish that we were not so determined to proudly go it alone.

Please don't exaggerate.  Representing Emacs development as something
that didn't change since the 1980s is factually incorrect and
practically not helpful.

> Any changes that can attract new blood have my vote.

Everyone agrees with general principles, the disagreements begin when
we consider the details.  E.g., "any changes" is definitely a
generalization that is not very useful in practice.

Re: Gitlab Migration

[Dmitry Gutov]

On 31.08.2021 19:37, Eli Zaretskii wrote:

>> Any changes that can attract new blood have my vote.
> 
> Everyone agrees with general principles,

With "any changes that can attract new blood", really?

> the disagreements begin when
> we consider the details.  E.g., "any changes" is definitely a
> generalization that is not very useful in practice.

FWIW, I mentioned particular categories of changes.

Or as I've been saying, we love additions but hate changes. This is a 
distinction that's easy to conceptualize, and we could start a 
discussion into changing this, or at least instituting some procedures 
for making important non-backward-compatible changes. Nobody with power 
to make decisions has shown any interest, however.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: rms@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 31 Aug 2021 22:17:10 +0300
> 
> Or as I've been saying, we love additions but hate changes.

Emacs is an old and _stable_ package.  "Stable" means just that:
features burned into users' muscle memory don't just change every
weekend.  So we do it slowly, cautiously, and preferably via opt-in
features, because we respect our users and their habits.  It is
maddening to have to re-learn your editor just because you've
upgraded.

> we could start a discussion into changing this, or at least
> instituting some procedures for making important
> non-backward-compatible changes.

We _have_ procedures for making backward-incompatible changes, and we
use those procedures all the time.

> Nobody with power to make decisions has shown any interest, however.

Please forgive me the lecture that you don't need: talking never moves
anything in Emacs, never did, never will.  Change in Emacs comes when
motivated individuals sit down and do the work.  If someone presents
the code to make some backward-incompatible change in a way that
leaves it opt-in, the resistance is likely to be much lower than it
may seem when such changes are just "discussed".  For the same reason,
it is hard to show interest in an Nth theoretical discussion that
never results in any code; by contrast, having a code presented to us
_requires_ "The Powers That Be" to make decisions, whether they want
it or not.

Backward-incompatible changes in the _defaults_ take much longer and
might be met with more resistance, that's true.  But this is a feature
in Emacs; see above.  My advice is not to insist on having each
incompatible change to become the default the moment it is coded: it
will in the long run make such changes much easier to introduce, and
everyone wins.

Re: Gitlab Migration

[John Yates]

On Tue, Aug 31, 2021 at 3:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Emacs is an old and _stable_ package.  "Stable" means just that:
> features burned into users' muscle memory don't just change every
> weekend.

At 70, I still count myself as an "early adopter".  I am unlikely to
accept having my world and habits disrupted every weekend.  But
with somewhat longer time scales (e.g. Ubuntu's six month and
Android yearly cadences) I am quite comfortable.

> So we do it slowly, cautiously, and preferably via opt-in
> features, because we respect our users and their habits.

Ah, but the model is opt-in to change, not opt-out.  Thus
opponents of change start off with an advantage and set
the terms of debate.

Other models are possible:
* Long term releases with sunset dates
* Previews of features that will become defaults with opt-out
* ?

Anyway, thank you, Eli, for your long, thoughtful reply and
for your project leadership.

/john

Re: Gitlab Migration

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

  > Ah, but the model is opt-in to change, not opt-out.  Thus
  > opponents of change start off with an advantage 

That's ok.  We don't have any obligation to be "fair" to 
wishes for changes that other users don't like.

  > * Previews of features that will become defaults with opt-out

It is useful to offer previews of changed interfaces, but whether
to make the other interface the default some day is a question we
should decide after seeing users' reaction -- not in advance.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Gitlab Migration

[Dmitry Gutov]

On 02.09.2021 06:38, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    > Ah, but the model is opt-in to change, not opt-out.  Thus
>    > opponents of change start off with an advantage
> 
> That's ok.  We don't have any obligation to be "fair" to
> wishes for changes that other users don't like.

We're literally under no "obligation" to anything. But is it a good outcome?

Under the current system a sufficiently loud single user can effectively 
veto any change. Or at least 3-4 such users.

But even 5 or 10 users are in no way representative of our entire user base.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: eliz@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 2 Sep 2021 22:02:25 +0300
> 
> >    > Ah, but the model is opt-in to change, not opt-out.  Thus
> >    > opponents of change start off with an advantage
> > 
> > That's ok.  We don't have any obligation to be "fair" to
> > wishes for changes that other users don't like.
> 
> We're literally under no "obligation" to anything. But is it a good outcome?
> 
> Under the current system a sufficiently loud single user can effectively 
> veto any change. Or at least 3-4 such users.
> 
> But even 5 or 10 users are in no way representative of our entire user base.

Opt-in changes are an effective way of dealing with such resistance.
They cannot be easily vetoed.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Opt-in changes are an effective way of dealing with such resistance.
> They cannot be easily vetoed.

We have previously discussed extending the concept of a "theme", which
is currently basically just visual.  I think the way forward here is to
allow people to create opinionated views on how Emacs should work (from
keystrokes on up to basically...  anything), and include these in Emacs.

New users, when starting Emacs, would then be able to choose between,
say, five of these mega-themes on the start-up screen by just clicking
them.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 09:12, Lars Ingebrigtsen wrote:
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.

A key bindings theme is a nice enough concept (for example, to create a 
native set of key bindings that follows the CUA convention). For that, 
indeed what's left is for someone to do the work.

Which is significant -- moving all current default bindings around to 
free up C-x, C-c, C-v, C-a and C-z is a big task, especially if one 
wants to interoperate with bindings made by third-party modes as well.

But I don't really want to migrate to CUA, personally. Do we not want 
our other users to enjoy undo-redo? Having a separate theme for every 
little proposed change seems silly.

And having a theme to just make indent-tabs-mode behavior sane, that 
would just be ridiculous.

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

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

  > And having a theme to just make indent-tabs-mode behavior sane, that 
  > would just be ridiculous.

I've been using indent-tabs-mode = nil for enough time to conclude
I personally would not object to making that the default.

Would someone like to look up who objected to it before, and
ask them to try setting it to nil for a month and see what cases
actually cause them trouble?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Dmitry Gutov]

On 06.09.2021 06:06, Richard Stallman wrote:
>    > And having a theme to just make indent-tabs-mode behavior sane, that
>    > would just be ridiculous.
> 
> I've been using indent-tabs-mode = nil for enough time to conclude
> I personally would not object to making that the default.
> 
> Would someone like to look up who objected to it before, and
> ask them to try setting it to nil for a month and see what cases
> actually cause them trouble?

I'm afraid it's not a good question.

If you look at bug#20322 or the latest discussion, people usually talk 
about inconveniencing *others* (all users that are not present in the 
discussion). Because every one who objected can personally easily 
customize indent-tabs-mode to t locally, and that will endure for a long 
time, without being affected by any changes in the default value in any 
future Emacs version.

But as far as customizing it to nil goes, that's not generally a good 
suggestion because people who use tabs for indentation often do that due 
to coding style required at their current place of employment (and they 
often do not get a say in that).

RE: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Drew Adams]

> But as far as customizing it to nil goes, that's not generally a good
> suggestion because people who use tabs for indentation often do that
> due to coding style required at their current place of employment
> (and they often do not get a say in that).

I don't understand.  Can't they customize it to t?
That will only affect their own use, but any Emacs
users in their org can do that.  What am I missing?

(FWIW, I'm in favor of changing the default to nil,
which is why I started this thread, breaking it off
from your wishlist of default changes.)

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Dmitry Gutov]

On 07.09.2021 02:32, Drew Adams wrote:
> I don't understand.  Can't they customize it to t?

Yes. That was in the paragraph before the one you quoted.