From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel] Date: Mon, 06 Sep 2021 18:13:17 +1000 Message-ID: <87lf4akq0k.fsf@gmail.com> References: <874kb1gjxs.fsf@yahoo.com> <87r1e4fueq.fsf@yahoo.com> <87a6krg8n5.fsf@yahoo.com> <1814c1e5-5085-bfee-9bc8-2cc66949e785@yandex.ru> <871r63g12g.fsf@yahoo.com> <87wnnveg30.fsf@yahoo.com> <10b4782c-ba2a-4d98-8934-258a1203055b@yandex.ru> <871r62ec1h.fsf@yahoo.com> <87y28al837.fsf@gmail.com> <87tuiycr5e.fsf@yahoo.com> <87tuiyl2w1.fsf@gmail.com> <87pmtmclds.fsf@yahoo.com> <87pmtmkwyb.fsf@gmail.com> <87lf4acf1c.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39219"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.0; emacs 27.2.50 Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 06 11:34:20 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mNB19-0009tn-D5 for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Sep 2021 11:34:19 +0200 Original-Received: from localhost ([::1]:54082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNB17-0002xK-Vw for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Sep 2021 05:34:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNAzz-0002IG-9R for emacs-devel@gnu.org; Mon, 06 Sep 2021 05:33:07 -0400 Original-Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]:33437) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mNAzx-0004gA-5G for emacs-devel@gnu.org; Mon, 06 Sep 2021 05:33:06 -0400 Original-Received: by mail-pg1-x534.google.com with SMTP id c17so6257092pgc.0 for ; Mon, 06 Sep 2021 02:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=/Iv/y07jBOj2+/6HOS5HmxZrZpcMMqHVqDPevbrSwW0=; b=ij5K3PHquaIwnDB+UB57d40W82WcTvw8WUUc16zEqZAsETmAJpYatStnkNZD2jApxp hwUDELhDjeJavoURjCJJVH+BsntJsskUeA9k+ku7zSXcwmcJ0WBS8u1IxCwfMCmVtyhy AILKrYSca9fK3PjaJeyQRBnz3IZOy/zyu2SQRUmBpXQ5dGKMWdxlaLbpBzeAvEJnk93H 1DjCgG0dJNybJfR2TfxNXBO/H/O2YcgSGsJUviAHYiAMFSGKItzyVyBF55FiPgB3Vkdg /45TfTVjSsCKS1zTN6jQ25dat75Zm++vLGsVDu9TxR3E7DLkndmeFwJjdFwfmuiCtQxZ SibA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=/Iv/y07jBOj2+/6HOS5HmxZrZpcMMqHVqDPevbrSwW0=; b=SRRad9+fBQnY7rZ3b7SFcVR4ydTElRalBvy74i0wxiic/vzgNIZgrhmjr2APapTnZN JVXekYhcfi3YgSCmqM9//YqPaEasF46eB3LzRa+BU67QVd+HTvPnMlTANaK3aCT3Kn/m kw0fmsTbH5QPMzp3AWIIuM1VBTzo6YxiUILdh5WeoJQM55uFNRLKGl9Je6xWbkGPQZ0n Sq//H+Q0FU6Pl+D2nDjVCI51RIS2YDLasybPFPsFtEP16aIbnqztdMThxTn9MX/4LTev BPHp++F0x57MtmAZtp78diKCOU/wUbjo68Wt/WCvNOG2w+qugiBNfUpB8TFYFz4WCO1s ISTw== X-Gm-Message-State: AOAM532SBXYlVQ3yhWiY3YLjzlOi3j0Q0N4sg1Rb/6nTT0tHk2eoMNaj msk/2v+pFlpvARn6oJjwQEC7ZAhfBdY= X-Google-Smtp-Source: ABdhPJx3wh0Zq5FZQR9kRUXMSUKXZNseI4KggvOpCKm0Me9+ZYxjUSzBBFbjVrN7kvuhiwtDrz7Vag== X-Received: by 2002:a63:1e0e:: with SMTP id e14mr11558737pge.5.1630920783291; Mon, 06 Sep 2021 02:33:03 -0700 (PDT) Original-Received: from tim-desktop (106-69-96-152.dyn.iinet.net.au. [106.69.96.152]) by smtp.gmail.com with ESMTPSA id i10sm7024988pfk.87.2021.09.06.02.33.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Sep 2021 02:33:02 -0700 (PDT) In-reply-to: <87lf4acf1c.fsf@yahoo.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::534; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x534.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274097 Archived-At: Po Lu writes: > Tim Cross 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.