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

"Stephen J. Turnbull" <[email protected]> writes:
 
>     Brian> And that suggests (interactive "_") would be short work for
>     Brian> the emacs developers to add, should they choose to do so.
> 
> Really?  To make a compatible interface they'd have to fix all the
> functions that went the other way.  Not likely.  Not to mention that
> XEmacs compatibility is deprecated in GNU; that never seems to be an
> acceptable reason for doing anything.  Any feature imported from
> XEmacs has to justify itself, and they often tweak APIs and change
> names.

Well, right, I'm not saying it's likely, it's just that the two are
not that wildly divergent (yet). 
 
>     Brian> Nothing which suggests that the two approaches are not
>     Brian> mostly compatible except for names,
> 
> And the default case, which is the killer, no?

I don't see why. As long as things and people that care can easily
switch cases the same way, or take advantage of their existing
knowledge, I'd suspect the default is not tremendously important.
 
>     Brian> I suggested providing a transient-mark-mode
>     Brian> function which would toggle the variable.
> 
> I would veto that name for the primary function, although half-baked
> GNU compatibility suggests providing the alias would be a good idea.
> `transient-mark-mode' suggests that the mark evaporates, which it
> certainly does not.  It's not the mark's existence that changes, it's
> the region's.
> 
> How about `transient-region-mode'?

Hmm. That does seem a better name than transient-mark-mode. It'd be
good with me. 

As for gnu emacs compatibility, my google searching for fboundp and
boundp suggests some people ignore the function in their code and
simply set transient-mark-mode the variable directly. Would that be
supported?  ie., have

(defvaralias 'transient-region-mode 'zmacs-regions)

and in fsf-compat (or wherever):

(defalias 'transient-mark-mode 'transient-region-mode) 
(defvaralias 'transient-mark-mode 'zmacs-regions)  

?

Having 3 names for 1 variable seems overkill. 
 
>     Brian> To me, it doesn't make sense to pick a different name when
>     Brian> the two are so close in goal, approaches, and features.
> 
> FWIW, rms does so almost as a matter of principle.

Well, there're reasons I'd rather contribute to xemacs :-) 

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