From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Changes for emacs 28 Date: Thu, 10 Sep 2020 22:16:42 +0300 Message-ID: References: <20200906133719.cu6yaldvenxubcqq.ref@Ergus> <20200906133719.cu6yaldvenxubcqq@Ergus> <874ko8wu8k.fsf@blind.guru> <83eencmj3l.fsf@gnu.org> <83k0x3kpw6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33590"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: spacibba@aol.com, mlang@blind.guru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 10 21:17:25 2020 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 1kGS4S-0008cO-Ck for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Sep 2020 21:17:24 +0200 Original-Received: from localhost ([::1]:53456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGS4R-0004pf-FW for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Sep 2020 15:17:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGS3u-0004Ob-7k for emacs-devel@gnu.org; Thu, 10 Sep 2020 15:16:50 -0400 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:44114) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGS3r-0003y9-Mm; Thu, 10 Sep 2020 15:16:49 -0400 Original-Received: by mail-lj1-x233.google.com with SMTP id b19so9610560lji.11; Thu, 10 Sep 2020 12:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=H2q/F+xf+oJIT4MwqjsbSu7M3TlHFmsy3QtV1CSfeG0=; b=fuPu+3DXzmPZgwh2RnOajOP+pa9YJSTkNdCBojfHmzogR9s/YvzdKgJbHLuBtinPGa uDzb2ghcxHgx8Mfb7enLiyVKKRIQy1sXvqr/jkJdNVSAofDIPsp49+BaQjkCUcZ4FQK3 jfgQ+r6n81WU4Z2bUURV1X/QWKvagf/TbWQ6kLB9FMMw1VgW4e8+0c7ljIn+lkb13lOS 2K6XaX/HzsW1EdybkcA4+K+4pUhWO1qMRlAO6yhqUNJ/gx+tE4weLie9GSHSwbxAVBMI LCWl72TlBzsALOzaYxFzSLuC1R4RAU1zen2wPY2RgBCSX1TvlnzTfrWGwOXNangU8Doy 9KfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H2q/F+xf+oJIT4MwqjsbSu7M3TlHFmsy3QtV1CSfeG0=; b=B449d39ZjVLpFcHcRe4fFQ8EXxPXBOgN24vqDCkb5bAoYA8MfMYJubwxLq8BHxCU6x ffeEHlUj62DWAf4h+9VmJjZVfagOyZ6VDmnwbuFhKwJSXD5Y7o7zx39cFCm3sxU6uWpx RiySrtI0YuyziY9ep6A/r1Jl2PCSxfGBOilkvAlfB4nLiryIXVDYBVL3LzJpX0BMDGV9 ePu0vPe9efQdN7VVntznba8i543zDM94100+tvMPCe4WHvkqpgAjsln/h8dPcqPgV4OI dsxMklIFkeevqC/EkFWf156iW7fA7C1JgPxogYSxK2ZPEH4B0ErJiQ/tE5DQwvCGJQEE H1MA== X-Gm-Message-State: AOAM533Qyxvbx8NVksNE/jww5pjNey/bCB7iV9I+n+lVZYD1zV0ThklM r9YC7dGqtDnxbmdwRAcZh9YzVmgfkzs= X-Google-Smtp-Source: ABdhPJyzMrfBgIxibvr6SXvqB4GzeVXHhP5bj4T97143pYQ0sAXfTnywG9bIYlXNiM5X9f6XIakdmA== X-Received: by 2002:a2e:8006:: with SMTP id j6mr4424773ljg.43.1599765405267; Thu, 10 Sep 2020 12:16:45 -0700 (PDT) Original-Received: from [192.168.0.104] ([94.229.108.16]) by smtp.googlemail.com with ESMTPSA id j127sm1556867lfd.6.2020.09.10.12.16.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 12:16:44 -0700 (PDT) In-Reply-To: <83k0x3kpw6.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=raaahh@gmail.com; helo=mail-lj1-x233.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -50 X-Spam_score: -5.1 X-Spam_bar: ----- X-Spam_report: (-5.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-3.576, 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:255041 Archived-At: On 09.09.2020 17:04, Eli Zaretskii wrote: >> On 08.09.2020 17:35, Eli Zaretskii wrote: >>> See, that's exactly the crux of the difficulty in these matters: ask N >>> people about changing defaults to M options, and you get the number of >>> different "please do this and this, but not that" opinions almost as >>> large as the number of permutations. >> >> Honestly, I don't think that enabling (or not) display-line-numbers-mode >> is going to be a big deal either way: it's easy to enable or disable, >> and it has little far-reaching consequences otherwise. > > That was only an example. > > And anyway, isn't what you say above true for almost every optional > feature in Emacs? For a lot of them, yes. But of course there are also changes in behavior (that people also asked for) that can have farther-reaching consequences. So I do believe we shouldn't worry too much about making some existing users moderately unhappy if we have convincing data that a given change will make Emacs more useful or more approachable (without making it less useful) for a lot of users, current or future ones. Especially if said optional feature is easy to toggle, and we can document how to negate the change in NEWS. Repeat the same decision process M times. Since this way there is no goal of making every user 100% happy, there is no stalemate. >>> So either (1) we go for the lowest common denominator of features that >>> most people agree to (which can easily be an empty set); or (2) we >>> come up with groups of optional features which are turned on and off >>> together. >> >> Orthogonally, we could decide on a method for changing defaults which >> doesn't involve the impossible task of making everybody happy but still >> makes some effort to change with the times. > > If this can be done, why not? > But based on past experience, I'm > skeptical, to tell the truth. From my past experience, what was lacking is direction in leadership. Sorry to be blunt. There were cases where we had evidence that a change will be welcome by the majority of users, existing and potential ones, and would be easily reverted locally by anybody who didn't like it, and it still wasn't made. E.g. the simple case of indent-tabs-mode=>nil. Of course, not all cases are simple, and whether something is generally beneficial/user-friendly/etc is a matter of judgment. But at least we shouldn't be stopped by the sole concern that a given change can generate complaints because the option in question has held a certain value for a number of years. Or even decades.