bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Stefan Kangas]

Severity: wishlist

The section '(emacs) Mark' starts with saying:

"Many Emacs commands operate on an arbitrary contiguous part of the
current buffer."

This makes it sound like this is an unusual, super advanced feature,
when in the rest of the world this is just known as "selecting text".
We should avoid the words "arbitrary" and "contiguous" which, while
accurate, comes off as extremely highbrow for such an extremely basic
feature.

We should re-work this section to contrast the unusual parts of point,
mark and region to the types of text selection that exists in other
editors.  We can safely assume that the latter is well known.

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 1 Oct 2021 21:31:22 +0200
> 
> Severity: wishlist
> 
> The section '(emacs) Mark' starts with saying:
> 
> "Many Emacs commands operate on an arbitrary contiguous part of the
> current buffer."
> 
> This makes it sound like this is an unusual, super advanced feature,
> when in the rest of the world this is just known as "selecting text".
> We should avoid the words "arbitrary" and "contiguous" which, while
> accurate, comes off as extremely highbrow for such an extremely basic
> feature.

I disagree that the region is a basic feature.  It may look
deceptively similar to text selections, but it isn't.  We have the
region, the active region, and the shift- and mouse-selected text,
which all look similar, and sometimes behave similarly, but they are
not identical.

> We should re-work this section to contrast the unusual parts of point,
> mark and region to the types of text selection that exists in other
> editors.  We can safely assume that the latter is well known.

The region and selected text are not identical.  The differences are
subtle and not easy to explain, but saying that they are the same is
worse than that, because it will trip users.

If anything, we should perhaps mention in this overview text that
Emacs has these 3 overlapping concepts (which are explained by the
sections of this chapter), because their addition to Emacs was
piecemeal and the overview was never updated to cover all of them.
But I don't think we should consider this a simple feature: that would
prevent us from explaining the subtleties that users should be aware
of.

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Stefan Kangas]

Den fre 1 okt. 2021 kl 21:44 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Fri, 1 Oct 2021 21:31:22 +0200
> >
> > Severity: wishlist
> >
> > The section '(emacs) Mark' starts with saying:
> >
> > "Many Emacs commands operate on an arbitrary contiguous part of the
> > current buffer."
> >
> > This makes it sound like this is an unusual, super advanced feature,
> > when in the rest of the world this is just known as "selecting text".
> > We should avoid the words "arbitrary" and "contiguous" which, while
> > accurate, comes off as extremely highbrow for such an extremely basic
> > feature.
>
> I disagree that the region is a basic feature.  It may look
> deceptively similar to text selections, but it isn't.  We have the
> region, the active region, and the shift- and mouse-selected text,
> which all look similar, and sometimes behave similarly, but they are
> not identical.

IMO, it is not an advanced feature, and on the most basic level it
really is just selecting text.  You want to copy it, make it bold,
indent it, or what have you.

It is of course precisely what makes it different that needs to be
explained.  But this can and IMO should be done by starting out from
what is already known.  For example, where we now have:

  Many Emacs commands operate on an arbitrary contiguous part of the
  current buffer.  To specify the text for such a command to operate on,
  you set “the mark” at one end of it, and move point to the other end.

it would be better to put something along these lines:

  In other text editors, you can select text to perform various
  operations on, such as copying or deleting it.  In Emacs, we say
  that such commands operate on the "region".

  The region starts at point, and ends at what in Emacs is known
  as "the mark" ...

  [Note: this a very quick write-up, and not a proposal.]

We don't need to talk about "arbitrary contiguous parts" or anything
like that.  There is no need to pretend as if the user don't already
have a very strong concept of what exactly is a text selection and how
it works: our job is to help the user see exactly where that intuition
fails.

> > We should re-work this section to contrast the unusual parts of point,
> > mark and region to the types of text selection that exists in other
> > editors.  We can safely assume that the latter is well known.
>
> The region and selected text are not identical.  The differences are
> subtle and not easy to explain, but saying that they are the same is
> worse than that, because it will trip users.

See above, this is not about saying that these things are the same.

In any case, AFAICT, the manual doesn't make much of an attempt to
explain this difference as it is, so I'm not sure it is very
important.  I could be wrong, but in that case I think the manual
should try to do a better job at explaining it.  (The only match I can
find for variations of "select" in the index is "mouse, selecting text
using" and that section is talking about the region.)

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 2 Oct 2021 01:01:21 +0200
> Cc: 50950@debbugs.gnu.org
> 
> > I disagree that the region is a basic feature.  It may look
> > deceptively similar to text selections, but it isn't.  We have the
> > region, the active region, and the shift- and mouse-selected text,
> > which all look similar, and sometimes behave similarly, but they are
> > not identical.
> 
> IMO, it is not an advanced feature, and on the most basic level it
> really is just selecting text.  You want to copy it, make it bold,
> indent it, or what have you.
> 
> It is of course precisely what makes it different that needs to be
> explained.  But this can and IMO should be done by starting out from
> what is already known.  For example, where we now have:
> 
>   Many Emacs commands operate on an arbitrary contiguous part of the
>   current buffer.  To specify the text for such a command to operate on,
>   you set “the mark” at one end of it, and move point to the other end.
> 
> it would be better to put something along these lines:
> 
>   In other text editors, you can select text to perform various
>   operations on, such as copying or deleting it.  In Emacs, we say
>   that such commands operate on the "region".
> 
>   The region starts at point, and ends at what in Emacs is known
>   as "the mark" ...
> 
>   [Note: this a very quick write-up, and not a proposal.]
> 
> We don't need to talk about "arbitrary contiguous parts" or anything
> like that.  There is no need to pretend as if the user don't already
> have a very strong concept of what exactly is a text selection and how
> it works: our job is to help the user see exactly where that intuition
> fails.

As I said, rewriting this overview text is probably a good idea, so no
argument here.  But the new text should still explain how our region
is different in subtle but important ways from what people see in
other editors.  Would you like to propose such a rewording?

> In any case, AFAICT, the manual doesn't make much of an attempt to
> explain this difference as it is, so I'm not sure it is very
> important.

I think it is important to explain; the fact that we don't is just
because once upon a time there was just one kind of region, and other
applications at that time didn't have anything even close.  Nowadays
things are different, so the way the overview is presented needs to be
rethought.

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Stefan Kangas]

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

tags 50950 + patch
thanks

Eli Zaretskii <eliz@gnu.org> writes:

> As I said, rewriting this overview text is probably a good idea, so no
> argument here.  But the new text should still explain how our region
> is different in subtle but important ways from what people see in
> other editors.  Would you like to propose such a rewording?

I have made an attempt in the attached patch.  I wrote this a week or
two ago, and returned to it again, and with fresh eyes I only find some
minor touch-ups to be made.  I'm interested to hear what you all think.

[-- Attachment #2: 0001-Rewrite-section-on-mark-to-feel-more-contemporary.patch --]
[-- Type: text/x-diff, Size: 3960 bytes --]

From f3a0d70a07ec622f8660d965f10885bdce8170db Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Sat, 16 Oct 2021 14:49:13 +0200
Subject: [PATCH] Rewrite section on mark to feel more contemporary

* doc/emacs/mark.texi (Mark): Rewrite section to hopefully feel
more relevant to a contemporary reader.  (Bug#50950)
---
 doc/emacs/mark.texi | 47 +++++++++++++++++++++++++--------------------
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/doc/emacs/mark.texi b/doc/emacs/mark.texi
index 2461cb0f6a..88888adea9 100644
--- a/doc/emacs/mark.texi
+++ b/doc/emacs/mark.texi
@@ -7,39 +7,44 @@ Mark
 @cindex mark
 @cindex setting a mark
 @cindex region
+@cindex selecting text
 
-  Many Emacs commands operate on an arbitrary contiguous part of the
-current buffer.  To specify the text for such a command to operate on,
-you set @dfn{the mark} at one end of it, and move point to the other
-end.  The text between point and the mark is called @dfn{the region}.
-The region always extends between point and the mark, no matter which
-one comes earlier in the text; each time you move point, the region
-changes.
+  In Emacs, selected text is called the @dfn{region}.  The region is
+roughly analogous to ``selected text'' in other software, but there
+are some differences.  One important such difference is that there is
+not just a name for the selection itself, but also for the positions
+where it starts and where it ends.
+
+  The region always starts at point, and ends at what is called
+@dfn{the mark}.  You move point with the normal movement commands, but
+you can also move the mark to any position in a buffer; we call this
+@dfn{setting the mark}.  The region always extends between point and
+the mark, no matter which of them comes earlier in the text; each time
+you move point, the region changes.
 
 @cindex active region
 @cindex activating the mark
-  Setting the mark at a position in the text also @dfn{activates} it.
-When the mark is active, we say also that the region is active; Emacs
-indicates its extent by highlighting the text within it, using the
-@code{region} face (@pxref{Face Customization}).
-
-This is one of the few faces that has the @code{:extend t} attribute
-by default, which implies that the same face is used to highlight the
-text and space between end of line and the window border.  To
-highlight only the text you could set this attribute to @code{nil}.
+  Setting the mark also @dfn{activates} it.  When the mark is active,
+we say also that the region is active.  The active region is
+highlighted with the @code{region} face (@pxref{Face Customization}).
 
 @cindex deactivating the mark
-  After certain non-motion commands, including any command that
-changes the text in the buffer, Emacs automatically @dfn{deactivates}
-the mark; this turns off the highlighting.  You can also explicitly
-deactivate the mark at any time, by typing @kbd{C-g}
-(@pxref{Quitting}).
+  After some commands, including any command that changes the text in
+the buffer, Emacs automatically @dfn{deactivates} the mark.  When the
+mark is deactivated, the region is no longer active, and consequently
+any highlighting of it is removed.  You can explicitly deactivate the
+mark at any time by @kbd{C-g} (@pxref{Quitting}).
 
   The above default behavior is known as Transient Mark mode.
 Disabling Transient Mark mode switches Emacs to an alternative
 behavior, in which the region is usually not highlighted.
 @xref{Disabled Transient Mark}.
 
+  The mark is useful even if it is not active.  For example, you can
+move to previous mark locations using the mark ring.  @xref{Mark
+Ring}.  Additionally, some commands will have an effect even on an
+inactive region (for example @dfn{upcase-region}).
+
 @vindex highlight-nonselected-windows
   Setting the mark in one buffer has no effect on the marks in other
 buffers.  When you return to a buffer with an active mark, the mark is
-- 
2.30.2

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 16 Oct 2021 09:04:38 -0400
> Cc: 50950@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > As I said, rewriting this overview text is probably a good idea, so no
> > argument here.  But the new text should still explain how our region
> > is different in subtle but important ways from what people see in
> > other editors.  Would you like to propose such a rewording?
> 
> I have made an attempt in the attached patch.  I wrote this a week or
> two ago, and returned to it again, and with fresh eyes I only find some
> minor touch-ups to be made.  I'm interested to hear what you all think.

Are you happy with the result?

My main problem with this text is that it says there are important
differences, but with a single exception leaves it to the reader to
deduce or guess which parts of the description are about these
differences and which ones just describe related issues and features.

Another, more minor problem is that the text starts under the
assumption that when you say "selected text", the reader immediately
understands what you mean, and that is neither a given nor a good
style, IME: it is always better to have some introductory sentence
that provides context.  For example:

  Emacs, like many other applications, lets you select some arbitrary
  part of the buffer text and invoke commands that operate on such
  @dfn{selected text}.  In Emacs, we call the selected text @dfn{the
  region}; its handling is very similar to that of selected text in
  other programs, but there are also important differences.

As for differences themselves, I'd suggest an explicit itemized list,
first naming them and then explaining each difference in some detail,
including cross-references to sections which describe them in more
detail.  The differences I think we should describe here are:

  . the "mark" and its relation to region (after all, the chapter is
    called "The Mark and the Region")
  . the fact that region can be active or inactive, and the basic
    difference between these two
  . the fact that some commands operate on region if it's active, and
    some even if it's inactive (the main difference here is that in
    Emacs many more commands are region-sensitive than in other
    programs, where it basically only supports copy/paste)
  . maybe also that we have some unusual ways of extending the region

The main challenge in describing these is how to describe enough, but
not too much (because the full details are elsewhere, and this is just
an introduction).

Thanks.

bug#50950: [External] : bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Drew Adams]

FWIW -

I generally agree with Eli's feedback.  Some comments
on the text:

1. "In Emacs, selected text is called the @dfn{region}."

No, not really, and this should be gotten across at
the outset.

I guess you could say that in transient-mark-mode
selected text is the _active_ region.  But then
you'll need to distinguish active from inactive in
t-m-mode etc.

The region is simply the buffer expanse between
point and mark, and the region's text is the text
in that expanse (region).  It's point and mark that
are basic concepts to talking about (and defining)
the region.

I know that you're just trying, in this intro text,
to connect the region with what users already know
about, namely selected, highlighted text.  The
problem I see with the text is that it seems to be 
defining the region as the same thing as selected
text.

This is probably just a problem of wording.  E.g.,
if you want to introduce the region by saying that
it's _somewhat_ like XYZ, that could be OK.  And
you do that by saying it's "roughly analogous..."
Just don't say that selected text "is called the
region".

Care needs to be taken to clearly distinguish it
- it's _not_ XYZ - and to explain about t-m-mode
and  the "active" region, and that some Emacs
commands act on the text in the region even when
it's inactive (and when t-m-mode is off).

2. It's not just that there are names for point
and mark.  They are important concepts and things
you use.  Command can do things at point or mark,
for instance.

3. I think it's a mistake to speak of "moving
point" and saying "you move point".

Point is just the current cursor position.  You
move the cursor, not point.  (Yes, the value of
point changes when you move the cursor, but the
user POV is moving the cursor.)

4. "The region always starts at point...ends at...
the mark."  I wouldn't say that.  It's important
that users understand from the outset that point
and mark are at the ends of the region (or rather
that the region is defined by those positions as
its limits).  But neither point nor mark is the
start (or the end).

Start and end are anyway unclear.  We have
`region-beginning|end', for start and end; we
don't have point and mark for start and end.

Yes, you try to explain this later.  But the
text you're starting with can misguide, IMO, by
talking about point as the start and mark as the
end.

5. "normal movement commands" is unclear, to me.
I'd speak in terms of movement of the _cursor_.
There are also window, frame, text, etc. movements.

I think it's important (perhaps after making some
nod to what users might already have experienced
in other editors) to start with the concepts of
cursor and buffer, then move to point and mark,
and then move to region, active region, etc.

6. "move the mark"..."we call this setting the
mark".  I wouldn't say that.  I'd say that you
can (and Emacs can) set the mark to any buffer
position.  Just as for point (another buffer
position), it can mislead to speak of moving the
mark.  There's nothing analogous to the cursor
for the mark - no visual thingy that you move.
But when the mark is set to a new position you
can see that the region limit has changed.

7. "Setting the mark also @dfn{activates} it."
Only in t-m-mode.  When t-m-mode is off there's
no notion of an active/inactive mark or region.

8. "After some commands, including any command
that changes the text in the buffer, Emacs
automatically @dfn{deactivates} the mark."

It's not about "some commands".  It's about
most commands.  More precisely, this is the
_default_ behavior: after a command the mark
is deactivated.

9. "the region is no longer active, and
consequently any highlighting of it is removed."
Yes, but there's another important consequence
- one that's perhaps even more important: many
commands no longer act on the region (namely
those that act on it only when it's active).

10. (You can tell that I think the existing
text already has some of the same problems.
In particular, t-m-mode is introduced late,
which means readers need to then wonder just
what parts of what the read before that are no
longer true - that's not obvious.)

11. "The mark is useful even if it is not
active.  For example, you can move to previous
mark locations using the mark ring.  Mark Ring.  Additionally, some commands will have an
effect even on an inactive region (for example
upcase-region)."

This is important, and should be said earlier.
I'd say "mark and region" are useful, not mark.
I'd move the example of the mark being useful
on its own (e.g. mark-ring) earlier.  (I'd
start, as I said, with cursor, then point and
mark, then region, then active/inactive and
t-m-mode.)

HTH.  Feel free to ignore, of course.

bug#50950: [External] : bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "50950@debbugs.gnu.org" <50950@debbugs.gnu.org>
> Date: Sat, 16 Oct 2021 18:14:29 +0000
> 
> 3. I think it's a mistake to speak of "moving
> point" and saying "you move point".
> 
> Point is just the current cursor position.  You
> move the cursor, not point.

Not in Emacs.  In Emacs, commands move point, and the cursor is then
drawn to show where point is.

bug#50950: [External] : bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Drew Adams]

> > 3. I think it's a mistake to speak of "moving
> > point" and saying "you move point".
> >
> > Point is just the current cursor position.  You
> > move the cursor, not point.
> 
> Not in Emacs.  In Emacs, commands move point, and the cursor is then
> drawn to show where point is.

Yes, in Emacs.  In Emacs, users move the cursor,
which means that point changes.  You don't see
point; you see the cursor.  Point is a position:
the position of the cursor.

We're talking to users, and we should use a user
point of view.  That starts with the things you
see and act on.  What takes place under the covers
to enable you to act on those things is something
else.  Yes, users need to know about some of those
things too.  But start with what's user-visible.

We'll have to agree to disagree about this one,
I'm afraid.  I offered my suggestions; ignore
them as you like.

bug#50950: [External] : bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "stefan@marxist.se" <stefan@marxist.se>,
>         "50950@debbugs.gnu.org"
> 	<50950@debbugs.gnu.org>
> Date: Sat, 16 Oct 2021 18:33:45 +0000
> 
> > > Point is just the current cursor position.  You
> > > move the cursor, not point.
> > 
> > Not in Emacs.  In Emacs, commands move point, and the cursor is then
> > drawn to show where point is.
> 
> Yes, in Emacs.  In Emacs, users move the cursor,
> which means that point changes.  You don't see
> point; you see the cursor.  Point is a position:
> the position of the cursor.
> 
> We're talking to users, and we should use a user
> point of view.

User's point of view will not be served if we distort the reality
while presenting it to the user.  The notion of point and its movement
is central to understanding Emacs, and realizing that changes like
point motion come first, while display of the cursor comes later, is
important to being able to extend Emacs and write Emacs Lisp programs.

bug#50950: [External] : bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Drew Adams]

> > > > Point is just the current cursor position.
> > > > You move the cursor, not point.
> > >
> > > Not in Emacs.  In Emacs, commands move point,
> > > and the cursor is then drawn to show where point is.
> >
> > Yes, in Emacs.  In Emacs, users move the cursor,
> > which means that point changes.  You don't see
> > point; you see the cursor.  Point is a position:
> > the position of the cursor.
> >
> > We're talking to users, and we should use a user
> > point of view.
> 
> User's point of view will not be served if we 
> distort the reality while presenting it to the user.

Agreed 100%.  I haven't distorted it.

A position doesn't "move".  Something changes
its position by moving.  If _you move_ then
_your_ position changes.

The X-coordinate 1.3 (a position) does not move.
A point whose X-coordinate is 1.3 can move to
a different position, with an X-coordinate of,
say, 2.9.

Understanding is not served by distorting
things to ignore this distinction.

> The notion of point and its movement
> is central to understanding Emacs,

The notion of _point_ is central.  That's clear
in all that I wrote.

Try reading again this part of what I wrote (and
the rest):

  a user point of view ... starts with the things
                           ^^^^^^
  you see and act on.

  Yes, users need to know about some of those
  things too [such as what you mention: display
  reflects changed point value].  But start
                                      ^^^^^
  with what's user-visible.

The _presentation_, to users, of concepts about a
software product does not necessarily follow the
order/mechanics of its underlying implementation.

But yes, of course, fuller understanding of Emacs
requires understanding of what happens under the
covers - how Emacs does what it does.  And that's
precisely because Emacs users/takers are, at the
end of the day, also Emacs implementers/makers.
___

Usefully related to presentation not necessarily
following implementation directly (but not the
_same_ distinction):

 "Of course the method of presentation must
  differ in form from that of inquiry.

  The latter has to appropriate the material
  in detail, to analyse its different forms of
  development, to trace out their inner connexion.
  Only after this work is done, can the actual
  movement be adequately described.

  If this is done successfully, if the life of
  the subject-matter is ideally reflected as in
  a mirror, then it may appear as if we had
  before us a mere a priori construction."

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> Date: Sat, 16 Oct 2021 17:11:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 50950@debbugs.gnu.org
> 
> As for differences themselves, I'd suggest an explicit itemized list,
> first naming them and then explaining each difference in some detail,
> including cross-references to sections which describe them in more
> detail.  The differences I think we should describe here are:
> 
>   . the "mark" and its relation to region (after all, the chapter is
>     called "The Mark and the Region")
>   . the fact that region can be active or inactive, and the basic
>     difference between these two
>   . the fact that some commands operate on region if it's active, and
>     some even if it's inactive (the main difference here is that in
>     Emacs many more commands are region-sensitive than in other
>     programs, where it basically only supports copy/paste)
>   . maybe also that we have some unusual ways of extending the region

And one more difference to consider: Emacs commands that move far
enough away usually set the mark at the original position, thus
implicitly setting the region.  That region is by default inactive,
but can be activated by a single command.

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[martin rudalics]

 > And one more difference to consider: Emacs commands that move far
 > enough away usually set the mark at the original position, thus
 > implicitly setting the region.  That region is by default inactive,
 > but can be activated by a single command.

The most significant difference IMHO is that the region may change when
scrolling a window.

martin

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> Cc: 50950@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 17 Oct 2021 10:34:53 +0200
> 
>  > And one more difference to consider: Emacs commands that move far
>  > enough away usually set the mark at the original position, thus
>  > implicitly setting the region.  That region is by default inactive,
>  > but can be activated by a single command.
> 
> The most significant difference IMHO is that the region may change when
> scrolling a window.

The region changes whenever point changes, so there are many other
situations where it changes.  But the one you mention above is not
something that will surprise users, because it happens in other apps
as well, right?

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[martin rudalics]

 > The region changes whenever point changes, so there are many other
 > situations where it changes.  But the one you mention above is not
 > something that will surprise users, because it happens in other apps
 > as well, right?

I have never seen another application change the highlighted region when
scrolling a window.  Can you name one?

martin

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Eli Zaretskii]

> Cc: stefan@marxist.se, 50950@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 17 Oct 2021 13:15:30 +0200
> 
>  > The region changes whenever point changes, so there are many other
>  > situations where it changes.  But the one you mention above is not
>  > something that will surprise users, because it happens in other apps
>  > as well, right?
> 
> I have never seen another application change the highlighted region when
> scrolling a window.  Can you name one?

Depends on how you scroll, I guess.  Applications where "point" stays
put when it goes out of the viewport need to be scrolled by moving
"point".

But if you have in mind the automatic movement of point when the
window is scrolled, then yes, it's quite unique to Emacs, but it isn't
about scrolling, it's about the fact that any movement of point
modifies the region.

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[martin rudalics]

 > Depends on how you scroll, I guess.

Using the mouse wheel, the mouse on the scroll bar or the <prior>,
<next>, <home> or <end> keys.  I guess these are the most common ones
for people trying to find out why Emacs does not behave like other
editors or applications like Firefox.

 > Applications where "point" stays
 > put when it goes out of the viewport need to be scrolled by moving
 > "point".
 >
 > But if you have in mind the automatic movement of point when the
 > window is scrolled, then yes, it's quite unique to Emacs, but it isn't
 > about scrolling, it's about the fact that any movement of point
 > modifies the region.

It's merely about the fact that "scrolling" as sketched above may move
point and consequently alter or simply discard the "selected text".

martin

bug#50950: "(emacs) Mark" should contrast to "selecting" text in other editors

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The main challenge in describing these is how to describe enough, but
> not too much (because the full details are elsewhere, and this is just
> an introduction).

I've now taken a stab at this in Emacs 29, incorporating text both from
Stefan and Eli.  Do feel free to adjust further.