Transient mark mode (was Re: How to replace string for a block?)

[Barry Margolin <barmar@alum.mit.edu>]

In article <mailman.7922.1243439002.31690.help-gnu-emacs@gnu.org>,
 Alan Mackenzie <acm@muc.de> wrote:

> Hi, Barry!
> 
> On Wed, May 27, 2009 at 08:51:12AM -0400, Barry Margolin wrote:
> > In article <mailman.7904.1243427777.31690.help-gnu-emacs@gnu.org>,
> >  Alan Mackenzie <acm@muc.de> wrote:
> 
> > > transient-mark-mode is an ill thought out conflation of several
> > > logically unrelated features, some of which have names which can only
> > > have been thought up when their namers were smoking something
> > > soothing, complicated to use, and utterly at variance with Emacs's
> > > ethos of elegant simplicity and keeping out of the user's way.
> 
> > > Some people seem to like it, though.  ;-)
> 
> > I've been an Emacs user for almost 30 years.  For at least half that
> > time transient-mark-mode didn't even exist, and after it was added (for
> > the benefit of converts from PC word processors, I believe) I resisted
> > enabling it for a long time, it seemed like sacrilege.  But I finally
> > gave in a couple of years ago when I started using Emacs in GUI mode
> > heavily at work, and I'm happy I did.  I particularly like when
> > commands automatically operate on either the buffer or region depending
> > on whether it's enabled.  I installed shell-command.el, which makes
> > shell-command-on-region do this automagically.
> 
> I could probably cope with transient-mark-mode if had been systematically
> thought out and its entities called unconfusing things.  The mark ISN'T
> transient - once created, it exists until the buffer is killed.  The mark
> and the region are never active - they aren't the sort of things that
> ever actively DO anything, they never become agents.  "Receptive" would
> have been a better word than "active", even if not very good.  This
> confusion has given rise to bewildering names like
> `mark-even-if-inactive', which is short for "mark is active even if it's
> inactive".

I think that the closest, simple phrase would be that the region is 
active, enabled, or visible.  But you're correct that it's wrong to 
apply the modifier to the mark.

Emacs has long had a problem with its terminology; I think its use of 
the word "point" has its heritage in TECO (and other CLI text editors), 
which used "." to refer to the current location.  It was written by and 
for computer geeks, who could pick up jargon like this easily.

> 
> The whole topic is such a cesspit of confusion and sloppy thinking, that
> I decline to sully myself by even touching it.  t-m-m conflates three
> logically unrelated things: (i) highlighting the region; (ii) "narrowing"
> the effect of certain commands to the region; (iii) enabling/disabling
> certain commands which work on the region (like C-w).  I can see the
> benefit of (i) (though I dislike it strongly), and I suppose (ii) might
> be handy, though given that C-x n n is so simple, I'm not exacly sure

Yes, C-x n n is imple, I used it for many years.  But I'm a sucker for 
DWIM features.  It's handy not having to narrow, M-x replace-string, 
widen.  And with shell-command.el loaded, I don't have to C-x h when I 
want to pipe the entire buffer to a shell command, which I think is more 
common than just piping a smaller region.

> what for.  As for (iii) - well, I don't need some fascist telling me when
> I can delete my region, thank you very much!  That's actually what
> `mark-even-if-inactive' means - it would be more accurately called
> `region-commands-never-disabled'.  As to why (i) and (ii) aren't
> available separately, I suppose lack of clear thinking in the hacker who
> created it is the most plausible explanation.

I think all of these problems are due to the fact that it was tacked 
onto an editor that had decades of use without this style of editing.  
When Emacs was extended to support GUIs, it seemed natural to try to 
incorporate many of the editing styles that were common there, such as 
marking text with the mouse and highlighting the region as you go.  In 
GUI editors, the Cut and Copy commands are disabled unless you've 
explicitly marked some text, and this was designed to emulate that style.

I think they were trying to keep things relatively simple, by not 
introducing lots of separate concepts for (i), (ii), and (iii).  I admit 
that I occasionally find it frustrating when I type a command and it 
beeps at me, because the region wasn't activated, but I don't think this 
happens very often (not enough to annoy me).  The simplicity of 
conflating all these concepts does indeed result in less flexibility.

> The classical mark was so elegantly simple (it can be described in a
> single concise sentence), yet also subtle and economical, the newbie
> could grasp it in a few minutes of concentrated thinking.  Which of us
> didn't get a "Eureka moment" on seeing how all the various uses of the
> mark complemented eachother and jelled so well together?  All that is now
> lost.  The imposition of transient mark mode on the newbie burdens him
> with a random ragbag of complexity, and I have no good answer to the
> anticipated newbie question "what do I have to go through all this stuff
> for?".

The main problem that the classical mark has for the newbie is that they 
can't tell where it is!  On the other hand, that's not usually a 
problem, since you rarely perform commands that operate on the region 
unless you've just set the mark a moment ago.  But visual clues are 
important for many non-expert users.


> Still, you like it.  :-)  Would you fancy fixing the documentation for
> all this?  The Emacs manual page "The Mark and the Region" decends into
> the "if you don't know what I mean by 'widget' you must be an idiot"
> style of documentation.  It doesn't have a @dfn{active}.  (I can think of
> a good reason. ;-)  It's also unsettling that it says that the text in a
> region vanishes when you do something ("The region persists only until
> you use it.", where @dfn{region} is THE TEXT between point and mark).
> There are probably more confusing things in it.

I don't think I have the time or energy for that much work on it.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***