Re: Aliasing zmacs-regions, providing a transient-mark-mode

Hrvoje Niksic <[email protected]> writes:

> Brian Palmer <[email protected]> writes:
> 
> >> The problem is that we do *not* support transient-mark-mode, which
> >> is in many ways subtly difference from zmacs-regions.
> >
> > Could you expand on those subtleties at all?
> 
> For one, there are behavioral differences I noticed while trying to
> use FSF Emacs, but which I can't remember right now.
> 
> They support features that we don't, such as mark-even-if-inactive.
> We support features that they don't, such as (interactive "_") and
> `zmacs-region-stays'.

As far as I can tell, their deactivate-mark is almost the same thing,
except from the other direction.
,----
| If an editing command sets this to t, deactivate the mark afterward.
| The command loop sets this to nil before each command,
| and tests the value when the command returns.
| Buffer modification stores t in this variable.
`----

And that suggests (interactive "_") would be short work for the emacs
developers to add, should they choose to do so. mark-even-if-inactive
doesn't look like it'd be too bad to add to xemacs, and in fact could
be a nice feature (mostly a matter of changing zmacs-activate-region
and zmacs-deactive-region to still do the highlighting even if
zmacs-regions is nil). Nothing which suggests that the two approaches
are not mostly compatible except for names, or that there's any real
advantage to one approach over the other.

Clearly we don't want to encourage or promise too much compatibility
with the gnu emacs approach unless we're willing to go whole hog and
conform to behavior differences, but I don't think the approach I
outlined goes too far in that direction. It provides a better name as
an alternative to the historical name (that is, the defvaralias),
changes the docstring, and I suggested providing a transient-mark-mode
function which would toggle the variable. Again, a user friendly
convenience; if a user wants to try out both behaviours, why not
provide them have an interactive function to do so? 

I suppose providing a transient-mark-mode function might be too far;
would those packages that do depend on the subtle differences only
apply an 
(if (fboundp 'transient-mark-mode) ... ) ?
Googling shows that this is relatively common now, although often it's
simply a 
(if (fboundp 'transient-mark-mode) (transient-mark-mode 1))
or 
(if (boundp 'transient-mark-mode) (setq transient-mark-mode 1))


> The two are simply not synonyms.  What's wrong with having different
> variable names for different features?  After all, zmacs-regions are
> on by default, and the kind of user who is annoyed by that feature is
> likely to understand how to get rid of it.

My answer is in two parts.  

1. zmacs-regions is a really horrible name for this feature. It's not
mnemonic, it's not intuitive, and it's got a confusing docstring. I'm
not suggesting to get rid of it, however; but to improve its docstring
and give it a better alias. It's pretty bad user interface to punt and
claim that the people who would want to use a function will find it
(when there's a better alternative, that is). 

2. GNU Emacs has almost the exact same feature, with a decent name for
it. (I outlined the reasons t-m-m is a good name in
<[email protected]>). Regardless of subtle behavior
differences, the overriding behaviour is the same (if a user asks to
change the default behaviour, if they're on gnu emacs, they'll be
pointed to transient-mark-mode and if xemacs, zmacs-regions, no?)
There are many other rough areas of compatibility between gnu emacs
and xemacs.

To me, it doesn't make sense to pick a different name when the two are
so close in goal, approaches, and features.

-- 
I'm awfully glad I'm a Beta, because I don't work so hard.