Re: visual-region-mode?

[Charles A. Roelli]

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

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

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

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

Yes, these work too.
 
> > 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.

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

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

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