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