Transient Region Highlighting - an improvement over Transient Mark Mode.

Transient Region Highlighting - an improvement over Transient Mark Mode.

[Alan Mackenzie]

Hi, Emacs!

I've criticised Transient Mark Mode somewhat in the last few days.  I
therefore feel obliged to make a constructive suggestion as how to make
it better.  Here is that suggestion:

Analysing T-M-M, it seems to consist of 3 vaguely related features:
(i) Disabling functions which operate on the region;
(ii) Highlighting the region;
(iii) Restricting the operation of some commands (e.g. M-x occur) to the
  region when highlit, a sort of narrowing.

Just as an aside, I think that terms like "active mark" and "activating
the region" are unhelpful, and have caused confused thinking over the
years.  Neither the mark nor the region is an agent - they don't DO
anything, anymore than a milepost on a country road between two villages,
or the road itself, do.  So I suggest we purge these terms from the code
and manual.


Feature (i) above, the one for which "Transient Mark Mode" is named,
doesn't seem to be useful, so let's just remove it - the mark, once set,
remains set, ditto for the region.  The variable mark-even-if-inactive is
redundant, and can vanish (or be marked obsolete).


Feature (ii) seems to be what people really want.  So let's rename the
entire feature "Region Highlighting Mode".  The variable
`region-highlighting-mode' should take the values nil, t, and possibly
'always, should there be anybody who wants the region always to be
highlit.

Region highlighting is switched on when the user types C-<space>, (?C-u)
C-x C-x or M-@ or the like, or the "certain mouse commands".  There
should be a command to switch it off (Keybinding C-u C-g, perhaps?).  I
don't think a simple C-g should switch it off.  Highlighting should also
be removed (via a before-change-function, possibly) when the buffer is
changed.  I don't think it should be switched off on executing a random
command.  For example, if you do M-: region-highlit, and see "t", the t
should remain meaningful.

"Momentary Transient Mark Mode" (there's tautology there ;-) should stay,
but be renamed to "Explicit Region Highlighting", to indicated that the
region gets highlit only when the user explicitly requests it via
C-<space> C-<space> or C-u C-x C-x.


Feature (iii) should be construed as "Wide area commands are restricted
to the region when it is highlit", and should be an option independent of
Region Highlighting Mode.  How about calling it
`area-commands-on-highlit-region-flag'?  To use this feature when Region
Highlighting is switched off, a user needs to set explicit region
highlighting first.


I think something like this design would be logically coherent, simple to
document, implement and use, would have the features that people want,
and be a vast improvement over the current Transient Mark Mode.

What do others think?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Stefan Monnier]

> I think something like this design would be logically coherent, simple to
> document, implement and use, would have the features that people want,
> and be a vast improvement over the current Transient Mark Mode.

I must be missing something.  You seem to be describing the
current behavior.  Is your suggestion just another way to describe the
current behavior, which would be more appropriate for the manual?


        Stefan

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Andreas Röhler]

Am Dienstag, 1. April 2008 17:19 schrieb Alan Mackenzie:
> Hi, Emacs!
> 
> I've criticised Transient Mark Mode somewhat in the last few days.  I
> therefore feel obliged to make a constructive suggestion as how to make
> it better.  Here is that suggestion:
> 
> Analysing T-M-M, it seems to consist of 3 vaguely related features:
> (i) Disabling functions which operate on the region;
> (ii) Highlighting the region;
> (iii) Restricting the operation of some commands (e.g. M-x occur) to the
>   region when highlit, a sort of narrowing.


Thanks being initiative in that matter, which is
important IMO, even if my understanding differs
somehow.

Some weeks ago I suggested to take the XEmacs
terminology, which I still think is more
straightforward.

(unless (featurep 'xemacs)
  (defun region-active-p ()
    (and mark-active transient-mark-mode
	 (not (eq (region-beginning) (region-end))))))


> 
> Just as an aside, I think that terms like "active mark" and "activating
> the region" are unhelpful, and have caused confused thinking over the
> years.  Neither the mark nor the region is an agent - they don't DO
> anything, 



Yes, but their state is important: 

- if a mark exists at all
- if it's at a different point from cursor
- if the user will be aware of it

The first and the second are meaningful for programms,
the last for interactive mode.

The second condition has no own terminus at the moment
AFAIU, and probably don't need it. 

The third (which includes the others) is expressed by 
`region-active-p' in XEmacs,
which IMO is more precise than `transient-mark-mode',
which doesn't really reports the state. Because it might be
t without any region...



Andreas Röhler




> anymore than a milepost on a country road between two villages, 
> or the road itself, do.  So I suggest we purge these terms from the code
> and manual.
> 
> 
> Feature (i) above, the one for which "Transient Mark Mode" is named,
> doesn't seem to be useful, so let's just remove it - the mark, once set,
> remains set, ditto for the region.  The variable mark-even-if-inactive is
> redundant, and can vanish (or be marked obsolete).
> 
> 
> Feature (ii) seems to be what people really want.  So let's rename the
> entire feature "Region Highlighting Mode".  The variable
> `region-highlighting-mode' should take the values nil, t, and possibly
> 'always, should there be anybody who wants the region always to be
> highlit.
> 
> Region highlighting is switched on when the user types C-<space>, (?C-u)
> C-x C-x or M-@ or the like, or the "certain mouse commands".  There
> should be a command to switch it off (Keybinding C-u C-g, perhaps?).  I
> don't think a simple C-g should switch it off.  Highlighting should also
> be removed (via a before-change-function, possibly) when the buffer is
> changed.  I don't think it should be switched off on executing a random
> command.  For example, if you do M-: region-highlit, and see "t", the t
> should remain meaningful.
> 
> "Momentary Transient Mark Mode" (there's tautology there ;-) should stay,
> but be renamed to "Explicit Region Highlighting", to indicated that the
> region gets highlit only when the user explicitly requests it via
> C-<space> C-<space> or C-u C-x C-x.
> 
> 
> Feature (iii) should be construed as "Wide area commands are restricted
> to the region when it is highlit", and should be an option independent of
> Region Highlighting Mode.  How about calling it
> `area-commands-on-highlit-region-flag'?  To use this feature when Region
> Highlighting is switched off, a user needs to set explicit region
> highlighting first.
> 
> 
> I think something like this design would be logically coherent, simple to
> document, implement and use, would have the features that people want,
> and be a vast improvement over the current Transient Mark Mode.
> 
> What do others think?
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).
> 
> 
> 

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Vincent Belaïche]

Dear all,

Sorry to step into a discussion connected to a development I am not 
involved in. Just a few suggestions, hoping that that they can be useful :

1) There are already commands to narrow commands' scope  to the region 
and to widen it to the whole buffer (C-x n n, C-x n w, etc... see *info* 
node Narrowing) , but they are not transient. I think that narrowing 
whether it is permanent or transient (one-shot) should be accessible 
independently from indicating it. So there should be
1.1) three narrowing states = permanent, one-shot, inactive
1.2) a number of command scope narrowing targets (e.g. region, page, 
paragraph, Lisp defun, C-function, sentence, whole buffer) one of which 
is used when the narrowing state is not inactive (ie is permanent or 
one-shot), and that may be accessible depending on buffer mode (e.g. 
Lisp defun has no meaning in text mode)
1.3) one default command scope to be used when the narrowing state is 
inactive (default command scope  should be whole-buffer by default)
1.4) after each command operating on a narrowed portion of buffer, the 
narrowing state should transit as follows:

        +----------+
           V           !
   +----------+       !
   |permanent |----+
   +----------+

   +---------+
   |one-shot |
   +---------+
     !
     !
     !  +----------+
     V     V           !
   +--------+       !
   |inactive|------+
   +--------+


2) Highlighting the region as such is not the relevant thing to the 
user. What the user is really interested in is to have an indication of 
what the narrowed portion is for commands, and what is the narrowing 
state (permanent, one-shot, or inactive).
This indication may be done with reverse video like for TMM, or it may 
be done otherwise, notably by displaying only the narrowed portion as 
with command C-x n n.

Note  for instance that with this approach "C-x n n" would set:
- the narrowing state to "permanent",
- the narrowing target to region
- and the method of indication to "displaying narrowed portion only"


Method of indication should be configurable independently from narrowing 
command scope, and it should be configurable in a way that indication is 
dependent on the narrowing target (whole buffer, page, region, etc...) 
and on the narrowing state (permanent, one-shot, or inactive). The state 
is important because for instance reverse video could be a good idea for 
one-shot state, but it would be painful for permanent.

This independence between the mode of operation itself, and indications 
to the user of what is the mode of operation is crucial for 
futureproofnew / flexibility w.r.t. different platforms. For instance 
some people may think in the future that this indication would be better 
by some letters in the Mode Line, or by some prompt in the Minibuffer.

Best regards,
          Vincent.


Alan Mackenzie a écrit :
> Hi, Emacs!
>
> I've criticised Transient Mark Mode somewhat in the last few days.  I
> therefore feel obliged to make a constructive suggestion as how to make
> it better.  Here is that suggestion:
>
> Analysing T-M-M, it seems to consist of 3 vaguely related features:
> (i) Disabling functions which operate on the region;
> (ii) Highlighting the region;
> (iii) Restricting the operation of some commands (e.g. M-x occur) to the
>   region when highlit, a sort of narrowing.
>
> Just as an aside, I think that terms like "active mark" and "activating
> the region" are unhelpful, and have caused confused thinking over the
> years.  Neither the mark nor the region is an agent - they don't DO
> anything, anymore than a milepost on a country road between two villages,
> or the road itself, do.  So I suggest we purge these terms from the code
> and manual.
>
>
> Feature (i) above, the one for which "Transient Mark Mode" is named,
> doesn't seem to be useful, so let's just remove it - the mark, once set,
> remains set, ditto for the region.  The variable mark-even-if-inactive is
> redundant, and can vanish (or be marked obsolete).
>
>
> Feature (ii) seems to be what people really want.  So let's rename the
> entire feature "Region Highlighting Mode".  The variable
> `region-highlighting-mode' should take the values nil, t, and possibly
> 'always, should there be anybody who wants the region always to be
> highlit.
>
> Region highlighting is switched on when the user types C-<space>, (?C-u)
> C-x C-x or M-@ or the like, or the "certain mouse commands".  There
> should be a command to switch it off (Keybinding C-u C-g, perhaps?).  I
> don't think a simple C-g should switch it off.  Highlighting should also
> be removed (via a before-change-function, possibly) when the buffer is
> changed.  I don't think it should be switched off on executing a random
> command.  For example, if you do M-: region-highlit, and see "t", the t
> should remain meaningful.
>
> "Momentary Transient Mark Mode" (there's tautology there ;-) should stay,
> but be renamed to "Explicit Region Highlighting", to indicated that the
> region gets highlit only when the user explicitly requests it via
> C-<space> C-<space> or C-u C-x C-x.
>
>
> Feature (iii) should be construed as "Wide area commands are restricted
> to the region when it is highlit", and should be an option independent of
> Region Highlighting Mode.  How about calling it
> `area-commands-on-highlit-region-flag'?  To use this feature when Region
> Highlighting is switched off, a user needs to set explicit region
> highlighting first.
>
>
> I think something like this design would be logically coherent, simple to
> document, implement and use, would have the features that people want,
> and be a vast improvement over the current Transient Mark Mode.
>
> What do others think?
>
>   

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Alan Mackenzie]

Hi, Stefan,

On Tue, Apr 01, 2008 at 12:06:23PM -0400, Stefan Monnier wrote:
> > I think something like this design would be logically coherent, simple to
> > document, implement and use, would have the features that people want,
> > and be a vast improvement over the current Transient Mark Mode.

> I must be missing something.  You seem to be describing the
> current behavior.

In that case, it stands a reasonable chance of being adopted, perhaps?
;-)

But I'm suggesting that the (eq mark-even-if-inactive nil) case be
removed, since it's not useful.

> Is your suggestion just another way to describe the current behavior,
> which would be more appropriate for the manual?

It is partly that, because I think the words currently used are too
confusing.

The other main thing is to identify and separate out the various bits of
T-M-M, since they are easier to describe, (and probably to use)
separately.

>         Stefan

-- 
Alan.

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Luc Teirlinck]

Alan Mackenzie wrote:

   But I'm suggesting that the (eq mark-even-if-inactive nil) case be
   removed, since it's not useful.

I have not followed this discussion, so I am not sure I understand the
above correctly.  I hope that it does _not_ mean that you are
suggesting eliminating mark-even-if-inactive completely.

Setting mark-even-if-inactive to t by default was a decision made to
make transient-mark-mode less annoying to people who do not use it,
are not going to use it ever and have no idea whatsoever about why
and how people use it.  I hope that not to many other changes have
been made to t-m-m for that same purpose in this seemingly endless
discussion.

I have used t-m-m ever since I used Emacs and if I use commands like
C-w and friends without having a region highlighted, so without being
able to verify what is going to be deleted, there is 100% certainty
that I typed C-w inadvertently, so the nice thing to do is to give me
an error message rather than to make me pay for my mistyping.

So it is bad enough that mark-even-if-inactive was made t by default
(a decision I am not going to fight, because I do not have the time
to enter in some endless discussion), it should _certainly_ not be
_eliminated_.

Sincerely,

Luc.

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Luc Teirlinck]

From my previous message:

   I have not followed this discussion, so I am not sure I understand the
   above correctly.  I hope that it does _not_ mean that you are
   suggesting eliminating mark-even-if-inactive completely.

To avoid confusion, I of course meant eliminating the "nil" behavior
completely (by eliminating the variable, hardcoding t).

Sincerely,

Luc.

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[paul r]

2008/4/1, Luc Teirlinck <teirllm@dms.auburn.edu>:
> Alan Mackenzie wrote:

>  Setting mark-even-if-inactive to t by default was a decision made to
>  make transient-mark-mode less annoying to people who do not use it,
>  are not going to use it ever and have no idea whatsoever about why
>  and how people use it.  I hope that not to many other changes have
>  been made to t-m-m for that same purpose in this seemingly endless
>  discussion.

After more thoughts, I also think it is not a newbie-friendly choice
to turn on mark-even-if-inactive. It is maybe even more confusing than
no tmm at all.
So if tmm is on by default in a move to make defaults easier for
newbies, mark-even-if-inactive should be let off.

>
>  I have used t-m-m ever since I used Emacs and if I use commands like
>  C-w and friends without having a region highlighted, so without being
>  able to verify what is going to be deleted, there is 100% certainty
>  that I typed C-w inadvertently, so the nice thing to do is to give me
>  an error message rather than to make me pay for my mistyping.

Yes, I agree.

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Alan Mackenzie]

Hi, Luc!

On Tue, Apr 01, 2008 at 01:10:42PM -0500, Luc Teirlinck wrote:
> Alan Mackenzie wrote:

>    But I'm suggesting that the (eq mark-even-if-inactive nil) case be
>    removed, since it's not useful.

> I have not followed this discussion, so I am not sure I understand the
> above correctly.  I hope that it does _not_ mean that you are
> suggesting eliminating mark-even-if-inactive completely.

That was indeed what I was suggesting.

[ .... ]

> I have used t-m-m ever since I used Emacs and if I use commands like
> C-w and friends without having a region highlighted, so without being
> able to verify what is going to be deleted, there is 100% certainty
> that I typed C-w inadvertently, so the nice thing to do is to give me
> an error message rather than to make me pay for my mistyping.

> So it is bad enough that mark-even-if-inactive was made t by default
> (a decision I am not going to fight, because I do not have the time
> to enter in some endless discussion), it should _certainly_ not be
> _eliminated_.

OK, I withdraw the assertion that this option is useless and should be
eliminated.

I would, however, still suggest it be renamed to reflect the thinking in
your second last paragraph above, and my opening post.  How about
`region-op-only-when-highlit' (with an alias for the old name, of
course)?

> Sincerely,

> Luc.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Mathias Dahl]

>  2) Highlighting the region as such is not the relevant thing to the
>  user.

I might misunderstand you, but I do not agree -- the highlighted
region is what I like most about Transient Mark Mode. It is nice to
see exactly how the region looks like (the last couple of years I have
turned it off for other reasons but when I do use it I like seeing
that highlight.) I sometimes make use of the feature where certain
commands are restricted to the region, but for me that isn't critical
(it's "nice to have"), I could always use narrowing if I wanted that.

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Manoj Srivastava]

On Tue, 01 Apr 2008 12:06:23 -0400, Stefan Monnier
<monnier@IRO.UMontreal.CA> said:  

>> I think something like this design would be logically coherent,
>> simple to document, implement and use, would have the features that
>> people want, and be a vast improvement over the current Transient
>> Mark Mode.

> I must be missing something.  You seem to be describing the current
> behavior.  Is your suggestion just another way to describe the current
> behavior, which would be more appropriate for the manual?

        If these three different effects are indeed separable, they can
 be made independently activatable -- I personally  am only interested in
 the visual highlight of the region.

        manoj
-- 
A parade should have bands or horse, but not both.  -- Nancy M. Wells
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Tue, 1 Apr 2008 19:04:55 +0000
Alan Mackenzie <acm@muc.de> wrote:

> Hi, Luc!
> 
> On Tue, Apr 01, 2008 at 01:10:42PM -0500, Luc Teirlinck wrote:
> > Alan Mackenzie wrote:
> 
> >    But I'm suggesting that the (eq mark-even-if-inactive nil) case
> > be removed, since it's not useful.
> 
> > I have not followed this discussion, so I am not sure I understand
> > the above correctly.  I hope that it does _not_ mean that you are
> > suggesting eliminating mark-even-if-inactive completely.
> 
> That was indeed what I was suggesting.
> 
> [ .... ]
> 
> > I have used t-m-m ever since I used Emacs and if I use commands like
> > C-w and friends without having a region highlighted, so without
> > being able to verify what is going to be deleted, there is 100%
> > certainty that I typed C-w inadvertently, so the nice thing to do
> > is to give me an error message rather than to make me pay for my
> > mistyping.
> 
> > So it is bad enough that mark-even-if-inactive was made t by default
> > (a decision I am not going to fight, because I do not have the time
> > to enter in some endless discussion), it should _certainly_ not be
> > _eliminated_.
> 
> OK, I withdraw the assertion that this option is useless and should be
> eliminated.
> 
> I would, however, still suggest it be renamed to reflect the thinking
> in your second last paragraph above, and my opening post.  How about
> `region-op-only-when-highlit' (with an alias for the old name, of
> course)?

the naming implies constraint, what benefit is an artificial limitation ?

> > Sincerely,
> 
> > Luc.
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Jan Djärv]

Mathias Dahl skrev:
>>  2) Highlighting the region as such is not the relevant thing to the
>>  user.
> 
> I might misunderstand you, but I do not agree -- the highlighted
> region is what I like most about Transient Mark Mode. It is nice to
> see exactly how the region looks like (the last couple of years I have
> turned it off for other reasons but when I do use it I like seeing
> that highlight.)

I agree, the highlighted region is the reason I use t-m-m.

	Jan D.

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Stefan Monnier]

>>> I think something like this design would be logically coherent,
>>> simple to document, implement and use, would have the features that
>>> people want, and be a vast improvement over the current Transient
>>> Mark Mode.

>> I must be missing something.  You seem to be describing the current
>> behavior.  Is your suggestion just another way to describe the current
>> behavior, which would be more appropriate for the manual?

>         If these three different effects are indeed separable, they can
>  be made independently activatable -- I personally  am only interested in
>  the visual highlight of the region.

Actually, they are not independent: the fact that the mark gets
"deactivated" every once in a while in TMM is crucial to making the
highlight bearable.  Otherwise, it would *always* be highlighted.


        Stefan

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[Manoj Srivastava]

On Wed, 02 Apr 2008 10:04:51 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said: 

>>>> I think something like this design would be logically coherent,
>>>> simple to document, implement and use, would have the features that
>>>> people want, and be a vast improvement over the current Transient
>>>> Mark Mode.

>>> I must be missing something.  You seem to be describing the current
>>> behavior.  Is your suggestion just another way to describe the
>>> current behavior, which would be more appropriate for the manual?

>> If these three different effects are indeed separable, they can be
>> made independently activatable -- I personally am only interested in
>> the visual highlight of the region.

> Actually, they are not independent: the fact that the mark gets
> "deactivated" every once in a while in TMM is crucial to making the
> highlight bearable.  Otherwise, it would *always* be highlighted.

        But then we go around and make the mark active again even when
 it is not. I think what we want is that the highlight is either on or
 not (having it on all the time will indeed make me want scratch my eyes
 out).  I think we have conflated the highlight being visible and mark
 being active: we want the highlight to go on and off based on some
 actions. 

        Even though newbies want to see the region visible, they are
 very confused about things like query replace not working like they do
 when there is no region highlight.

        manoj
-- 
Love is not enough, but it sure helps.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Transient Region Highlighting - an improvement over Transient Mark Mode.

[David Kastrup]

Manoj Srivastava <srivasta@ieee.org> writes:

> On Wed, 02 Apr 2008 10:04:51 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said: 
>
>> Actually, they are not independent: the fact that the mark gets
>> "deactivated" every once in a while in TMM is crucial to making the
>> highlight bearable.  Otherwise, it would *always* be highlighted.
>
>         But then we go around and make the mark active again even when
>  it is not. I think what we want is that the highlight is either on or
>  not (having it on all the time will indeed make me want scratch my
>  eyes out).  I think we have conflated the highlight being visible and
>  mark being active: we want the highlight to go on and off based on
>  some actions.
>
>         Even though newbies want to see the region visible, they are
>  very confused about things like query replace not working like they
>  do when there is no region highlight.

You are confusing an active mark with an active region.  The latter
causes both highlighting and region-specific action.  The former just
means that the region is _usable_, not that it is _active_.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum