emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: visual-region-mode?


From: Charles A. Roelli
Subject: Re: visual-region-mode?
Date: Thu, 13 Sep 2018 22:42:24 +0200

> 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, and the commands using the region
are well-marked (e.g. "kill-region", "fill-region", "eval-region",
...).

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

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

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

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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]