From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Change default behavior of some commands that act on region? Date: Sun, 23 May 2021 15:12:58 +0000 Message-ID: References: <87mtsmbbms.fsf@gmail.com> <83bl91kjlr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7223"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , "theophilusx@gmail.com" , "monnier@iro.umontreal.ca" , "emacs-devel@gnu.org" To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 23 17:13:39 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 1lkpnP-0001m4-Lr for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 17:13:39 +0200 Original-Received: from localhost ([::1]:47630 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkpnO-0007hO-6T for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 11:13:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32792) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkpmu-0006zk-02 for emacs-devel@gnu.org; Sun, 23 May 2021 11:13:08 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:10525 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lkpmp-0006qg-OC for emacs-devel@gnu.org; Sun, 23 May 2021 11:13:07 -0400 Original-Received: (qmail 3787 invoked by uid 3782); 23 May 2021 15:12:59 -0000 Original-Received: from acm.muc.de (p4fe15fab.dip0.t-ipconnect.de [79.225.95.171]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 23 May 2021 17:12:59 +0200 Original-Received: (qmail 16150 invoked by uid 1000); 23 May 2021 15:12:59 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:269673 Archived-At: Hello, Drew. On Sun, May 23, 2021 at 14:28:35 +0000, Drew Adams wrote: > > > > Indeed, it is important to keep full support for configs > > > > where `transient-mark-mode` is disabled. Not only many > > > > users prefer such a config, but as you mention, there are > > > > also cases where such a config is not just a question of > > > > taste. > > > Yes, and this is irrelevant to this thread, as the > > > ^^^^^^^^^^^^^^ > > > proposed change has no effect on users who disable > > > `transient-mark-mode'. They continue to have "full > > > support". First of all, I haven't followed this thread in all its details, so far. That said, I think your above point is a little naive. I also have transient-mark-mode disabled, I run with "GUI disabled", and run with "minibuffer-only frames disabled". I am very wary of changes which balkanise Emacs. Every change which only works with some options, or which works differently depending on options which aren't specifically configuring that thing, makes Emacs more of a tangled mess. (Not that I'm saying it already is such a mess, but we want to avoid making it so.) > > The issue you consider "irrelevant" is actually quite relevant, > I didn't say that support for use of t-m-mode OFF is > irrelevant. It's very relevant to Emacs. But it's not > relevant to the proposal of this thread, which has NO > effect on that use case. That's the point. Please > don't twist what's been said. You're arguing against > a straw man. I think you're proposing to make some functions (have you said exactly which ones, yet?) behave differently in t-m-m. That _is_ of concern to everybody, including those who run with t-m-m disabled. > I've written carefully and clearly, from the outset, that > this proposal has NO effect on that use case. Yet you've > insisted on pursuing it for supposedly ignoring, or even > inflicting damage, on that case. Please stop. There's > nothing relevant about insisting on needing to protect > the t-m-mode OFF case against this proposal, as there's > no threat to it. There have been features in the past introduced as "optional" into Emacs, followed some time later by pressure to conform with these "optional" features. You can't blame people for feeling uneasy about this proposal. There might well have been an understanding in the past that t-m-m would not be forced any further into Emacs than it is already. If that is the case, your proposal would be a violation of that understanding and an example of the pressure I refer to above. > > because commands that behave differently depending on whether > > transient-mark-mode is on or off are a source of confusion and > > frustration. We shouldn't enlarge the number of such commands > > willy-nilly. > Every command that tests `use-region-p' and does something > different depending on the value does something different > depending on whether t-m-mode is on or off, simply because > when it's off there's no notion of active/inactive region > - there's just the region. > t-m-mode's raison d'etre is to be able to do something > when the user sees the selected text highlighted and not > otherwise. That distinction is what it's all about. Yes. But I think adding things into "something" to make it "something else as well" needs to be justified case by case. -- Alan Mackenzie (Nuremberg, Germany).