Re: visual-region-mode?

[hw]

address@hidden (Charles A. Roelli) writes:

>> From: hw <address@hidden>
>> Date: Mon, 10 Sep 2018 13:52:06 +0200
>>
>> >> How come it wasn't distinguished between the concept of a region being
>> >> active and the visual aid of marking a region?
>> >
>> > Separating these two concepts could be useful,
>> > but Emacs would then need some other way of showing the user that a
>> > region is active,
>> 
>> Whether regions can be active or not, and whether "active" means that
>> they limit or extend operations to themselves, or both, might depend on
>> settings and doesn't necessarily need to be shown all the time.
>
> Yes.  Ultimately the choice should be left to the user.
>  
>> > like a mode line indicator.
>> 
>> Such a mode line indicator would need to show which regions are active
>> when there several and in which way each one of them is active because
>> there are multiple ways of being active.
>
> Can you say how there can be multiple regions active, and how there
> can be "multiple ways of being active"?  The region is normally
> defined as "the text between point and mark", for one, and whether the
> mark is active depends on the value of the buffer-local variable
> 'mark-active'.

I don't think there can currently be multiple regions at the same time.
That doesn't mean this couldn't be implemented.

There are multiple ways for a region to be active because there are at
least three ways in which the activeness of a region can have an
influence on functions/commands.  Active can mean:


+ limit commands to a region (like query-replace)

+ extend commands to a region (like backward-delete-char)

+ both of the above (I don't have a good example)


The first one was probably the original intention, the second one seems
like a bug.  The last one is probably questionable.  You may see
delete-selection-mode as an example in that otherwise harmless
keystrokes suddenly operate on a whole region.

I can understand the original intention.  I don't understand how
disabling transient-mark-mode could have an advantage --- unless, for
some reason, you have a bad habit of abusing the mark for naviation ---
and I don't understand why regions are not always highlighted regardless
if are active or not.  That means that something not highlighted as such
is not a region.

As to the definition of the region:  I've never seen it that way.  The
region is what is currently highlighted.  I don't use and don't like
hidden regions.  They are a design flaw because when I press C-w,
something of unknown extend is being deleted, and when press M-w,
something of unknown extend is being copied and replaces what I kept on
the clipboard.

These hidden regions always make me feel uneasy.  It's like you're being
forced to walk around with a loaded gun, safety off, once you only even
touched the trigger without firing a shot because that sets a mark.  The
only way to get rid of this gun is to kill the buffer --- or is there
another way?

I expect the mark to be forgotten, or at least to disappear, right away
after doing something with a region.

As to multiple regions, it might be nice to have them.

>> Perhaps it could generally show if any region is active and change when
>> point is within a region to show more of its details.
>
> Point always delimits the region, so I'm not sure what more details we
> could show about it.

That would be different if there were multiple regions.

>> > We would then also need bindings for activating and deactivating the
>> > region, and for turning the visual aid on and off.
>> 
>> Another C-spc after starting to mark a region might do to end the
>> marking.
>
> 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?

I expect the mark to be gone once I used the region.

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

> The user might want it highlighted for various reasons, possibly not
> covered by the current implementation, where Emacs highlights the
> region only when 'mark-active' is non-nil.

Yes, and that leads to misunderstandings, like d-s-m.  It doesn't make
any sense to claim that there is a region when there is none highlighted
and only creates the inconsistency that an arbitrary part of a buffer
can be deleted or copied, accidentally or intentionally, i. e. that
something can be done with a region while the region is not active and
nothing should possibly be done with it.

>> Are these hidden regions a remnant of technical limitations that made it
>> advisable not to highlight the selection?
>
> No, they stem from convenience.  For example, typing C-M-a in a source

That key binding only works when you can use Alt instead of ESC.

> code buffer moves point to the beginning of the current defun, pushing
> a mark where point was.  Afterwards, typing C-u C-SPC restores point
> and mark (i.e. the region) to where they were before you typed
> C-M-a. During editing this is very helpful.

This is only sometimes helpful, provided that the Alt key works.  When
it doesn't, you'd have to bind the function to another key.  All in all,
even with the Alt key working, these key bindings are so awkward that I
would never use this.  It's far easier to just scroll up and to use
bookmarks or registers.

> Highlighting the region at any of these steps might be helpful for the
> user, but Emacs can't know exactly when -- which is one argument for
> allowing to toggle the highlighting dynamically as necessary,
> independently of whether the mark is ever "active".

This is a problem of navigating source code (or other files) and has
nothing to do with regions or highlighting.

Or what has navigating between a current location and the beginning of a
function to do with selecting and highlighting parts of the contents of
a buffer in order to copy or to delete them, or to do something with
them like query-replace?

>> Perhaps region selections could be remembered in registers to make it
>> easier to re-create them once they were disabled to suppress the
>> highlighting.
>
> As seen above, use of C-u C-SPC effectively restores the region at
> some previous point in editing.

That I move around in a file as I see fit while reading or editing it
doesn't have anything to do with regions I might select to do something
with.  I might highlight a selection to make parts of source code stick
out as a reminder because they need to be fixed or worked upon in some
particular order.  I could use registers and/or bookmarks instead, but
it would be much more convenient to use highlighting and perhaps to be
able to jump through the selections.

Why would I want a region I have selected and highlighted to become
undone when I move around?

> Certainly, it would be nice to have some register key to push (cons
> (point-marker) (mark-marker)) into a register to come back to it
> later.  Until we have that, "C-x 4 c C-x n n C-x r SPC <register>"
> also works, via an indirect buffer, though it's a mouthful.

yeah

>> >> I think for the strict-selection-mode I'd prefer, it would help to
>> >> disable transient-mark-mode.  But how can I see what I have selected?
>> >
>> > The most common answer to that is to use "C-u C-x C-x", which
>> > temporarily activates the region (thus highlighting it) and exchanges
>> > the point and the mark.  But there is no command to turn on the
>> > highlighting of the region directly.
>> 
>> Doesn't that enable transient-mark-mode?  If I wanted t-m-m, I could
>> just leave it enabled to begin with.
>
> Yes, it is enabled temporarily.

Then what's the use of disabling t-m-m?

>> I tried with t-m-m disabled, and I don't see what the point of having it
>> disabled is.  Regions are not protected any better, and I'd have to be
>> stupid to select a region to do something I want to affect the whole
>> buffer.
>
> With t-m-m off, you can make use of the mark without randomly
> activating it and causing certain commands to respond differently.

The mark is only for setting the begin of a selection, nothing else.  I
expect it to be gone once I did something with the selection.

It doesn't even matter to me if there is a mark.  All I do is start
selecting somewhere and when it's selected, I do something with it, and
that's all there is to it.

Don't mix up a mark for navigational purposes with making and
highlighting selections.

> However, there are tradeoffs: commands like "query-replace" will do
> their work on the region only when the mark is "active", so to use
> that capability, you need "C-u C-x C-x" to temporarily activate the
> mark.

I'm really never using the mark.  When I want to do a query-replace
limited to a selection, I make the selection and then do the
query-replace.  With t-m-m disabled, I can't limit the query-replace to
a selection, so it's only a disadvantage to have it disabled --- and the
other disadvantage is that I can never see what I have selected.

>> >> It would even be possible to leave the visual markers active while the
>> >> user is doing something else if transient-mark-mode didn't insist on the
>> >> region being active when it's visually highlighted.  
>> >
>> > I'd like this too.
>> 
>> It could be accompanied by a region-mode in which nothing can be done to
>> and with anything outside of the regions.
>
> Working on a specific region can often be done conveniently from an
> indirect buffer, as in the earlier example.

It's quite inconvenient because with that, the source tends to occupy
both frames I have on screen because I'd narrow the indirect buffer to
what I'm working on --- which is already another inconvenience --- and
need the other frame to look up things I can't see in the indirect
buffer because it's narrowed.  I've given up on it, it's just too
awkward.

As for doing other things, like replacing text in multiple parts of a
buffer, is that something that could be usefully done with indirect
buffers?  With multiple regions, I'd highlight some parts of the buffer,
do the replacement limited to these parts and would be done with it.
I'd be able to see all of the buffer while doing this.

Indirect buffers still hold all of the text, so instead of marking what
I want to work with, I'd have to narrow out what I'm not working with,
and IIRC, it's not possible to narrow a buffer "the other way round" so
that the parts I want to work with remain and all the rest of the buffer
is narrowed away.


So maybe you see how I'm saying that the concept of regions could use an
overhaul and how a visual-region-mode could be useful :)