unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Drew Adams <drew.adams@oracle.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	"theophilusx@gmail.com" <theophilusx@gmail.com>,
	"monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: [External] : Re: Change default behavior of some commands that act on region?
Date: Sun, 23 May 2021 15:12:58 +0000	[thread overview]
Message-ID: <YKpw+qOkdz8VYqbQ@ACM> (raw)
In-Reply-To: <SA2PR10MB447438D8630AE7F41B48D281F3279@SA2PR10MB4474.namprd10.prod.outlook.com>

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).



  reply	other threads:[~2021-05-23 15:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 20:58 Change default behavior of some commands that act on region? Drew Adams
2021-05-22  6:04 ` Eli Zaretskii
2021-05-22  6:19   ` Clément Pit-Claudel
2021-05-22  6:36     ` Emanuel Berg via Emacs development discussions.
2021-05-22  7:00       ` Clément Pit-Claudel
2021-05-22  6:45     ` Eli Zaretskii
2021-05-22  7:00       ` Clément Pit-Claudel
2021-05-22  7:23         ` Eli Zaretskii
2021-05-23  0:23         ` [External] : " Drew Adams
2021-05-23  0:23   ` Drew Adams
2021-05-22 14:03 ` Stefan Monnier
2021-05-22 14:14   ` Eli Zaretskii
2021-05-22 14:33     ` Stefan Monnier
2021-05-23  0:25     ` [External] : " Drew Adams
2021-05-22 19:26   ` Drew Adams
2021-05-22 21:16     ` Stefan Monnier
2021-05-23  0:25       ` Drew Adams
2021-05-23  6:39     ` Eli Zaretskii
2021-05-23 14:27       ` Drew Adams
2021-05-23 15:13         ` Eli Zaretskii
2021-05-23 17:50           ` Drew Adams
2021-05-23 18:08             ` Eli Zaretskii
2021-05-23 19:22               ` Drew Adams
2021-05-23 19:42                 ` Eli Zaretskii
2021-05-23 20:07                   ` Drew Adams
2021-05-22 23:07   ` Tim Cross
2021-05-23  0:24     ` [External] : " Drew Adams
2021-05-23  0:55     ` Stefan Monnier
2021-05-23  1:37       ` [External] : " Drew Adams
2021-05-23  7:14         ` Eli Zaretskii
2021-05-23 14:28           ` Drew Adams
2021-05-23 15:12             ` Alan Mackenzie [this message]
2021-05-23 17:48               ` Drew Adams
2021-05-23 18:44               ` T.V Raman
2021-05-22 20:48 ` Juri Linkov
2021-05-23  0:24   ` [External] : " Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YKpw+qOkdz8VYqbQ@ACM \
    --to=acm@muc.de \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=theophilusx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).