Re: visual-region-mode?

[hw]

address@hidden (Charles A. Roelli) writes:

>> From: hw <address@hidden>
>> Date: Tue, 11 Sep 2018 23:56:11 +0200
>>
>> [...]
>>
>> 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?
>
> 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?

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.

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

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

> The mark is a standard Emacs marker, as described in (info
> "(elisp) Markers"):
>
>     A “marker” is a Lisp object used to specify a position in a buffer
>     relative to the surrounding text.  A marker changes its offset from the
>     beginning of the buffer automatically whenever text is inserted or
>     deleted, so that it stays with the two characters on either side of it.

And there is no way to show the mark?

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

>> > 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.
>
> Again, that seems like the intention behind transient-mark-mode.  But
> the implementation is, then, in a way incomplete: C-w still kills the
> region, no matter whether it is active or not, in transient-mark-mode.

Yes, it is an inconsistency.

>> >> 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.
>
> Does ESC C-a not work for you?  Or C-[ C-a?

ESC C-a works.  [ is on AltGr+8.

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.

> [...]
>> > 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?
>
> The places where the mark has been set are places of interest to the
> user for some reason or another -- that's all.

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

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

>> 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.
>
> It's probably feasible to add a "type" field to the mark, indicating
> where it came from (i.e., if it was set explicitly by the user, by a
> certain command, from a mouse selection, ...).  Then we could offer
> commands that jump between previous selections, or between previous
> marks set by the user for navigation.

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

Some people like to make shift-selections.  They could be independent
from the mark stuff and simply allow to make selections something can be
done with.

>> > 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.
>
> Not possible yet, I think (at least, without making N indirect buffers
> for the N regions and running the replacement command in all of them).

Yes, that's what I thought, I'd have to make many indirect buffers.

> But if we had some way to record the "type" of a previous mark (as
> above), then we could offer a command to replace, for example, the
> last N "active regions" in the buffer.  I think that might fit the
> bill.

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

>> 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.
>
> I don't think that's possible yet.

Having multiple regions active would make this unnecessary :)