Re: visual-region-mode?

[hw]

Alan Mackenzie <address@hidden> writes:

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

Of course they do.  They're lurking hidden in the background, waiting
for me to make a mistake, and are making me feel uneasy all the time.

> 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 always know it's lurking.

> [...]
>> 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.

No, software has a design flaw when it doesn't protect the user from
making mistakes and makes mistakes even worse.  For that, it doesn't
matter how easy it is to make the mistake.  This doesn't have anything
to do with features.

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

I already looked in the manual and was surprised about the lack of
options.  Maybe I'll find some when I read more.

>> Disabling transient-mark-mode removes the possibility of highlighting
>> regions.  What is the purpose of that?
>
> For users who find this highlighting unhelpful.

That simply doesn't make any sense.

> [...]
>
>> >> > 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!

And how do I know where it is?  And why text before it and not after it?
When you set a mark in the middle of the buffer and delete something at
the end, the mark moves towards the end of the buffer.  And what happens
when you delete a place that contains a mark?

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

The mark is not for navigation, it's for making selections.  When I want
to select something, I go there and select it.  So why would these
messages tell me anything and why would I care?  I don't even need a
mark, I only need to select things.

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

No, the problem is that there is always something lurking hidden in the
background --- you call it a region.  If I was ignoring that, I might
make a mistake and do something with it I don't want to.

> [ .... ]
>
>> 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.

I don't know how to.  I might find it useful to use a mark for
navigation, but only when has nothing to do with making selections.

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

That is triple work because first I'd have to make a selection, second
I'd have to narrow the buffer and third I'd have to widen it again.

> Useful here is, for example, C-x n d, which narrows to the current
> source-code function.

Cases in which operations that need to be limited to a selection are as
wide as a whole function almost don't exist.

> [ .... ]
>
>> 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.

Why?  Move one key binding, and there will already be another key
binding in the way, so you first have to move that one, etc., and you
end up shuffling them all around a great deal until you might find
something that reasonably works --- or not.

> [ .... ]
>
>> 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.

I don't have any other uses for it --- actually, I don't have any.
Making selections doesn't have anything to do with navigation, and
overloading the navigational aid that is called a mark by involving it
into making selections is a very bad idea.  A constantly changing,
hidden selection which is being brought up by that is also a very bad
idea.

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

I might use it for navigation if it didn't do anything else.  Since
there is currently no other way to make a selection, I have to use it
for making selections.  There's nothing obvious about it other than that
it is a bad idea.

> [ .... ]
>
>> 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.

Apparently there are some modes that allow to use multiple selections :)

>
> [ .... ]
>
>> 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.

It could be used for navigation, how would that make anything less
convenient?

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

I don't know how to implement it.

> [ .... ]
>
>> 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.

It's no delight at all, it's a bad idea.