GNU bug report logs - #7196
24.0.50; NEWS item "Selection changes"

Previous Next

Full log

Message #20 received at 7196-done <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 7196-done <at> debbugs.gnu.org
Subject: RE: bug#7196: 24.0.50; NEWS item "Selection changes"
Date: Fri, 15 Oct 2010 11:45:51 -0700

> > For info, are the following statements correct?
> 
> Most of the time, but not always, depending on customizations.
> 
> Why is that important?

They are clear statements of things that users need to understand. They make
your explanation clearer. If they are not correct, then please correct them.
IOW, summarize the change by making some similar straightforward statements
(which are correct).

> > #1 needs to also say something about the other systems, 
> > which do not support a separate primary: e.g. do they put
> > the selection on the clipboard? the kill
> > ring? Where do they put it?
> 
> They do nothing and don't put the text anywhere outside Emacs.

Who said anything about outside Emacs?  When you select text on such a system,
where is it saved (conceptually), since there is no primary selection?  We're
talking about the case where it is not automatically sent to the kill ring and
clipboard.

Think of the user's mental model.  The selection is what s?he sees: selected
text. When the region is no longer active, there is no visible selection.  But
the text that was selected is saved somewhere and it will be pasted using
`mouse-2'.  That conceptual "somewhere" is given a name in the case of each type
of selection in Emacs - except for this one.  We could call it the "primary
selection" except that it doesn't act as such outside Emacs on systems that
don't have a primary.

> > >   Only commands that kill text or copy it to the
> > >   kill-ring (C-w, M-w, C-k, etc.) put the killed text into the
> > >   clipboard.  Selected text is put into the primary selection (on
> > >   systems, such as X, that support the primary selection 
> > >   separately from the clipboard).
> > 
> > Is it (a) "put into the primary selection" or (b) "becomes 
> > the primary selection"?
> 
> We use "put text into primary" and "set the primary with the text"
> interchangeably.

Then you are using English incorrectly. "Put into" suggests a container, and
that suggests that multiple things can be put there.  If you are allowed to use
them interchangeably, then use the latter, as it is unambiguous.

> > I.e., does it replace the existing primary or is it added
> > (prepended/appended) to it?  I'm guessing (b), and that 
> > this is different from the kill ring.
> 
> It replaces the old content.

Then say so unambiguously.  "Set" says that.  "Put into" does not.

> > I don't know about the clipboard - is it a list or ring, like the
> > kill ring?
> 
> It's a single buffer.

That doesn't tell me the answer. Can you put more than one piece of selected
text there? Can you access those pieces separately, as you can with the kill
ring?  Or is it a single piece of text, so that "putting into" the clipboard is
actually setting its value, replacing the previous value?

> > Anyway, if in some cases we replace what was in some location
> > and in other cases we add to it, those cases need to be 
> > distinguished.  "Put into" implies a container of a collection.
> 
> I believe every user nowadays knows what happens with text that is put
> into the clipboard or the primary selection.

Well, you are wrong. I'm a user, and I did not know that.

Even as a Windows user I am sometimes confused about the clipboard: you can have
multiple items on the Windows clipboard, but (AFAIK) that works only in some
contexts - in other contexts the clipboard seems to have only one item.

> Anyway, NEWS entries are not for explaining these issues.

It's up to you to decide how much you explain in NEWS and how much in the doc.
My point is that the NEWS text is not yet very clear.

NEWS should not need to explain more than what has changed.  But if in order to
do that you need to describe the behavior (before and after change), then at
least the behavior description should be clear.

There is nothing wrong with explaining it completely in the doc and then giving
a summary of what's changed in NEWS and point there to the doc section for more
info.

> > What happens to selected text on systems that do _not_ 
> > support a primary selection separate from the clipboard?
> 
> Nothing.  They stay Emacs selections.

But they are not just any old selections.  When you speak later about using
them, you need to distinguish selections that were made a certain way, or at
least the selections that were not copied to the kill ring or some such.  IOW,
you talk about these things, so you need to either give them a name or
unambiguously describe them each time.

> > Please add that info - don't just say what happens for X.
> 
> There's nothing to tell.  This functionality does not exist on non-X
> systems, so whatever happens on X does not happen elsewhere.

The functionality exists of selecting with the mouse and pasting that text,
without copying it to the kill ring.

> > >   Similarly, Emacs by default does not retrieve text from the 
> > >   clipboard when the mouse (e.g., mouse-2) is used for 
> > >   pasting text selected in another application.  
> 
> > Why "in another application"?  If not also true for text 
> > selected in Emacs, then state also what the case for that text is.
> 
> I set out to describe changes wrt exchange of text between Emacs and
> other applications.  This is what this NEWS entry is about; it is not
> about selected text in Emacs in general.

I think it's about both, or should be.  If mouse-selecting text used to add it
to the kill ring (as an example) or whatever and it no longer does that, then
that's about use within Emacs.

The default behavior has changed not only between Emacs and other apps.  It has
also changed within Emacs.  In fact, nearly all of the questions, discussions,
and bugs I (one user) have filed have been about the change in behavior within
Emacs itself.  This is not just about interactions between Emacs and other apps.

If you want to divide the behavior changes between those affecting interactions
with other apps and those affecting Emacs-only behavior, because you think that
will make the explanation clearer or simpler, fine.  But all behavior changes
need to be described.

Even a user who never leaves Emacs experiences important changes wrt selection
in Emacs 24.  To _not_ experience such changes, a user will need to change
option values (`mouse-drag-copy-region' on Windows, for instance).

> > >   Mouse commands that paste text retrieve text from the primary 
> > >   selection, on systems that support it separately from 
> > >   the clipboard.
> > 
> > And retrieved from where on other systems?
> 
> Not retrieved at all.

That's obviously not true. If you select text with the mouse, then click mouse-1
somewhere or hit C-g, so the region is no longer active, then you do some stuff
- move the cursor around and call a few commands or whatever, move to another
buffer etc. - and then you hit `mouse-2', the selection is pasted.  The
selection you made was saved somewhere, and then it was retrieved.

And this saved selection probably should be called some name: "Emacs-only
primary selection" "mouse selection" (but I think this applies also to Shift
selection), or maybe just "selection".  I'd suggest calling it the "primary
selection" anyway and just explain that Emacs copies the notion of a primary
selection from systems such as X Window for systems that don't have such a
notion.

The behavior needs to be described, and that means either descibing this critter
each time, umambiguously, or describing it once and giving a name.  Other
selections have names and definitions outside Emacs: secondary, primary,
clipboard.  Emacs uses those same names as appropriate, and Emacs adds the kill
ring (and kills, or kill-ring entries), which is Emacs-specific.  This
mouse/Shift selection is another kind of selection, which needs to be
distinguished.  It's like the primary, but it is Emacs-specific for systems that
do not have a notion of primary.

> > >   In other words, the default behavior is that mouse gestures that
> > 
> > Mouse actions - mouse gestures are typically thought of as 
> something different.
> 
> "Mouse gestures" is frequently used terminology.

Yes, but typically for something different.  It is most often used to stand for
specific mouse movements traced out, which act as distinguishable UI symbols.
Here you mean just any action you can perform with a mouse.  That is sometimes
called a mouse gesture, but that term usually has a narrower connotation.

You apparently just want to argue and defend your existing text.  Use what you
want (you will anyway).  I'm just trying to help you.  If you don't want to hear
about things that are not very clear, fine.

> > >   while keyboard commands that kill/copy and paste text 
> > >   work with the clipboard.
> > 
> > I wouldn't say "copy", since there are different kinds of copy.
> 
> The "text" part in "kill/copy text" should disambiguate that.

I don't see how.  A user can easily think s?he is copying text by selecting it
with the mouse.  And in a sense s?he is copying it.

> > >   This change also means that the "Copy", "Cut", and 
> > >   "Paste" items of the menu-bar "Edit" menu are now exactly
> > >   equivalent to, respectively M-w, C-w, and C-y.
> > 
> > I didn't realize that BTW.  That means that on Windows they 
> > are _not_ equivalent to the Windows menus of the same names.
> 
> Why not?  I think they are.

My bad.  Dunno what I was thinking.

> > >   To get back the previous behavior, whereby mouse gestures
> > 
> > Just mouse _selection_, no?  Not also mouse-2 (paste).
> 
> The part after "whereby" describes what behavior I had in mind.

Then you don't want a comma after "behavior".  Without a comma, what follows is
an essential, or defining clause - it narrows the meaning of what precedes.
With a comma, what follows is an inessential, or non-defining clause - it gives
independent info.  It's similar to the use of "that" and "which" (where "which"
takes a comma).

IOW, if you are narrowing the topic to only the part of the previous behavior
that involves setting the clipboard, then do not use a comma.  If you use a
comma you are suggesting that the second clause stands for the same thing as the
first: the previous behavior (all of it) involves setting the clipboard.

And because many readers are not masters at such subtleties, it's best to not
make the meaning depend on the simple presence/absence of a comma.  Instead,
rephrase it to make clear that you are only talking about that part of the
previous behavior that involves setting the clipboard.

> > >   If you don't want Emacs to put the text into the 
> > >   clipboard, only to the primary selection, additionally customize
> > >   `x-select-enable-clipboard' to nil.
> > 
> > I'm lost now.
> 
> Not clear why.
> 
> > It's not clear, to start out with, what "the previous behavior" was.
> 
> The "whereby..." part says what it was.

Sorry, but I'm lost.  Perhaps your next version will seem clearer.

> > You made it clear that now selecting with the mouse sets the primary 
> > but not also the clipboard or the kill ring.  What's not clear is
> > what the previous behavior was (all its aspects) and therefore what
> > each of the options is for - which part(s) of the previous behavior
> > each restores.
> 
> Detailed description of the previous behavior is outside the scope of
> NEWS entries.  Especially since the previous behavior was confusingly
> inconsistent on X.

How much detail you give is up to you.  But NEWS needs to let users know what
has changed in the user-visible behavior.  If you want to give just a summary
that refers to complete descriptions in the doc, that's OK, but then the doc
needs to cover it completely.

One way or the other, users should get complete info on what the behavior is,
how it has changed, and how to get back the previous behavior.

> > >   These changes in the default behavior are reflected in 
> > >   the default values of several variables:
> > 
> > Maybe it would help to start with that.
> 
> We will risk losing the reader before she gets to the important parts.

Suit yourself, but I think you are already losing readers in the important
parts.

> > >   It also accepts a new value, `only', which means to only set the
> > >   primary selection for temporarily active regions 
> > >   (usually made by mouse-dragging or shift-selection).
> > 
> > BTW, why `only' and not `temporarily' or `immediate' or 
> > `on-the-fly' or some such? Only what?
> 
> I don't know why, I just documented it.

That's why I said "BTW" and "(I know, this is not primarily a doc problem.)"

But if the name were improved then the doc could be simpler.  That's the
connection to doc.

> > What's the difference in _behavior_? Why make readers look 
> > up each of those commands in order to understand what's changed?
> 
> Because that's what we do in general in NEWS: give the reader enough
> info to go and find the details by using documentation commands.
> Anything else would bloat NEWS to unreasonable proportions.

`mouse-yank-primary' is NEW.  NEWS is the place to describe such a change
(including why it was made).  NEWS is not just a code change log.

The point here - for users - is not so much which command is bound to `mouse-2'
but what the difference is between the commands.  One yanks the primary and the
other yanks the last kill.  Stating that (one sentence) does not bloat NEWS.

Users can easily determine on their own that `mouse-2' is bound to
`mouse-yank-primary', and they need not necessarily know what the previously
bound command was - because if they want `mouse-2' to yank a kill then they
should customize that using options, not key bindings.  So telling them the
behavior change instead of what the current binding is would actually reduce the
size of NEWS.

> > >   *** `x-select-enable-primary' now defaults to nil.
> > >   This variable exists only on X; its default value was t 
> > >   in previous versions.
> > 
> > What does it do?
> 
> The doc string tells the whole story.
> 
> > >   *** Support for X cut buffers has been removed.
> > 
> > What's the consequence for user-visible behavior?
> 
> I don't know.  And neither do others, I think -- this functionality is
> long obsolete and unused.

Maybe say that, so people don't wonder what behavior change they might be
missing.

> I fixed the typos you pointed out, thanks.

Thanks for working on this bug.  This change is confusing and involves lots of
pieces.  It might be clear to the Emacs developers but it will not necessarily
be clear to a user without some help.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.