Re: visual-region-mode?

[Alan Mackenzie]

Hello, hw.

On Thu, Sep 13, 2018 at 06:00:32 +0200, hw wrote:
> address@hidden (Charles A. Roelli) writes:

> >> From: hw <address@hidden>
> >> Date: Tue, 11 Sep 2018 23:56:11 +0200

> >> [...]

> > This is where Emacs differs from other programs, I suppose.  It's
> > optimized for efficient use, even when the result can be a surprise to
> > the user.  Otherwise, in this case, C-w and M-w would do nothing with
> > no "active region".

> What is efficient about hidden regions the way they are?

They don't get in your way.  A lot of the time, you won't be
conceptualising the buffer portion between mark and point as "the
region" - it's just point, and there's mark hanging around somewhere,
possibly at somewhere significant.

I think at some stage somebody tried having the region constantly
highlighted, and it proved annoying, with the highlighting continually
moving as you type stuff in, or even just move point.

> If killing or copying a region didn't happen to be bound to keys that
> are rather unlikely to get pressed by mistake, the design flaw of being
> able to do something with a non-highlighted region while
> transient-mark-mode is enabled might be more obvious.

What seems like a design flaw to you is a feature to somebody else.
That's why Emacs is so customisable.  As Juri has already pointed out,
there's an option you can set so that this "design flaw" won't affect
you.  I suggest you spending a couple of hours reading through the
chapter "The Mark and the Region" (also known simply as "Mark") in the
Emacs manual to see if there're any other options which would be useful
to you at a non-default setting.

> Disabling transient-mark-mode removes the possibility of highlighting
> regions.  What is the purpose of that?

For users who find this highlighting unhelpful.  As stated above, it was
found in the distant past that constantly highlighting the region was
counter-productive.  If you disagree with that, then implement an option
to have such highlighting.  If you genuinely find it useful, then ask for
your new option to be incorporated into the Emacs master.  You might be
surprised just how open the project leadership is to such innovations.

> >> > C-SPC (without a prefix argument) always pushes a mark, so it always
> >> > alters the region (unless point is already at the mark).  C-u C-SPC
> >> > sets point where the mark is, and pops the mark ring, effectively
> >> > restoring the previous region.  We should keep this behavior.

> >> How am I supposed to know where a mark was?  Why would I try to confuse
> >> myself with C-u C-spc?  In which way is the position of the mark
> >> adjusted so that it sticks with the same contents of the buffer, which
> >> it would need to do to be of any use?

Mark does get adjusted so that it stays at the "same" position in the
buffer, even if you insert or delete text before it.  Try it!

> > Various commands set the mark, as documented in the manual.  When you
> > use them, normally a message appears in the echo area saying "Mark
> > set".

> Yes, and they never told me anything because I don't use the mark for
> navigation.

An interesting question: why not?  The mark is one of the concepts which
distinguish Emacs from lesser editors, and with it you can do things
like:
(i) You search for something, and find it.  You want to go back to your
starting point.  No problem in Emacs!  C-u C-<space>.
(ii) You're editing something, and you want to read the massive comment
that often appears near the beginning of source files.  You do M-<, read
that comment, then C-u C-<space> to get back to where you were editing.

Personally, I use the mark all the time for navigation, and would not
want to go back to an editor without one.

> When I want a region, i. e. a selection, I go where I want it and
> select what I want.  The mark is irrelevant with this kind of usage,
> and so are these messages.

You can ignore both of them, surely, for this kind of usage.

[ .... ]

> And there is no way to show the mark?

Not really, no.  Highlighting the region when transient-mark-mode is
enabled is sort of a way, but that's not really what you meant.

When I use the mark, my subconsciousness retains a map of where the mark
is for an appreciable time.  I don't need the mark to be visible.  I
don't think most users do, either.

If you want the mark to be visible, implement it.  Others might find it
useful, too.

> >> >> What would the advantage of hidden regions be?  When something is within
> >> >> a region, it should be highlighted, and when it is no longer
> >> >> highlighted, it should no longer be within a region.

> >> > Again, in Emacs, as long there is a mark in the current buffer, there
> >> > is always a "region".

> >> How would that make sense?  I expect the mark to be gone once I used the
> >> region.

> > That's what transient-mark-mode tries to implement, I think.

> It doesn't remove the mark after a highlighted region has been used.
> The idea was apparently to limit functions to a selection by
> highlighting a region and then calling it particularly "active".

> Highlighting and calling a region "active" would not be necessary if
> functions could otherwise be limited to the region.  Combining these
> three things and not allowing another way to limit functions to the
> region make a mess.

There is another way: narrow to the region (e.g. with C-x n n).  Standard
editing function are then restricted to this portion of the buffer.
Useful here is, for example, C-x n d, which narrows to the current
source-code function.

[ .... ]

> Emacs would have to have all key bindings re-defined to work well with
> keyboards for different languages, leading to a definition for each
> language.

That's a bit of an exaggeration.

[ .... ]

> The only purpose of the mark is to make a selection.

No.  That's how _your_ use of it is currently restricted.  I earnestly
recommend you to spend time learning other uses of the mark.  It will
ease your editing.

> After the selection has been used, editing moves on, and the location
> has become irrelevant.  Places of interest are those where navigational
> aids are being placed, like bookmarks and registers.

> If it was possible to make a selection without using the mark, I might
> never use the mark.  However, I might get used to using the mark for
> navigation if it was like a default register that can be easily set and
> moved back to. The way it currently is is merely dangerous because it
> may influence hidden and highlighted regions without that being my
> intention.

Repeat: in an Emacs buffer there is exactly one region at any time.  I
can't suppress the feeling that sometime soon, something in your brain is
going to click, you're going to shout "Eureka!", and suddenly the Emacs
mark will be obvious and natural to you (as it is to so many users).

[ .... ]

> A feature request for the possibility of having multiple regions that
> can be highlighted, first decoupling making selections from navigation,
> might be an option.  I'm not sure if further discussion before making
> such a request is better because there might be pretty strong resistance
> against this from everyone used to and using things the way they have
> been for a long time --- and maybe we're missing something.

There would indeed be resistance.  Somehow, you've got to set up a
multiple region.  That will need key sequences (of which there are very
few spare).  Then you've got to modify lots of commands to work on a
multiple region.  Indeed you've got to decide what they will do.  This is
not a task for the faint-hearted.

[ .... ]

> Why not let the mark be mark and find a way of making selections
> independently from it?

Because that would lead to a general loss of convenience in the use of
the mark.  Still, if you have a solid idea of how this could work (and it
would have to be optional), implement it and ask for it to be
incorporated into Emacs.

[ .... ]

> That would overload the mark even more than it already is.

I don't agree the mark is overloaded.  Using it's several features
together is one of the delights of Emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).