Re: visual-region-mode?

[hw]

address@hidden (Charles A. Roelli) writes:

>> From: hw <address@hidden>
>> Date: Thu, 13 Sep 2018 06:00:32 +0200
>>
>> What is efficient about hidden regions the way they are?
>
> The region has a simple definition,

Someone already pointed out that the definition isn't all that simple.

> and the commands using the region
> are well-marked (e.g. "kill-region", "fill-region", "eval-region",
> ...).

How does this make hidden regions efficient?

>>             When I want a region, i. e. a selection, I go where I want
>> it and select what I want.
>
> No need, you have the mark already. ;)

No, I don't.  What I select doesn't have anything to do with this mark.

>> And there is no way to show the mark?
>
> Besides the ways already mentioned, no.  As Alan has suggested, it
> becomes second nature to keep its position in your head.  And if you
> want to know how far away it is from point (as a reminder), there is
> the key M-= (or ESC =).

Sure, I'm going to remember the positions of marks in the 25 buffers or
so I have open at work in the main Emacs session over months, plus the
other 5 or 10 in every minor Emacs session plus the ones I have at home
--- as if I had nothing better to do than to burden me with irrelevant
stuff like that.

I'm simply not using the mark, and it shouldn't be there.  The hidden
regions they create are a source for errors.  Make it so they don't
create regions, and the mark might become usable, provided it can be
made visible.

>> The only purpose of the mark is to make a selection.  After the
>> selection has been used, editing moves on, and the location has become
>> irrelevant.
>
> Sometimes yes, sometimes no.  Better to err on the side of caution,
> than to forget all previous marks (as other programs do).

Wrong, leaving the mark lurking around to create a hidden region only
means to make mistakes a user might make much worse.  It is a design
flaw.

> [...]
>> > This would be a good use case for registers storing regions, I think.
>> > The mark ring is a useful tool, but it does not give easy, random
>> > access to all previous selections.  We need a bug report for this.
>> 
>> 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.
>
> I make a less ambitious suggestion: get registers to store regions
> (i.e., two markers).  Then we can add functions to highlight them, set
> one of them as the "active region", and otherwise operate on them,
> either individually or as a set -- a bit like the "zones" Drew has
> detailed.

Maybe it's better not to use "regions" but "selections".
Transient-mark-mode already shows that people don't care about regions
but about visible selections.

How multiple selections would be implemented wasn't my concern, though.
I wouldn't know the best way how to technically do that.