* bug#7196: 24.0.50; NEWS item "Selection changes"
@ 2010-10-12 14:56 Drew Adams
2010-10-12 15:52 ` Drew Adams
2010-10-15 11:36 ` Eli Zaretskii
0 siblings, 2 replies; 5+ messages in thread
From: Drew Adams @ 2010-10-12 14:56 UTC (permalink / raw)
To: 7196
The NEWS item is woefully incomplete. It doesn't explain much of
anything about the selection changes for Emacs 24 - and they are
radical changes.
Among other things, NEWS should detail the differences from the
previous behavior, and explain clearly how to return to the
previous behavior (exactly, completely).
It is not enough to just give one-liners for a few variables,
such as "`x-select-enable-primary' now defaults to nil."
This should be obvious. Users and user-level descriptions should
come first, before implementation changes are made.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2010-09-20 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7196: 24.0.50; NEWS item "Selection changes"
2010-10-12 14:56 bug#7196: 24.0.50; NEWS item "Selection changes" Drew Adams
@ 2010-10-12 15:52 ` Drew Adams
2010-10-15 11:36 ` Eli Zaretskii
1 sibling, 0 replies; 5+ messages in thread
From: Drew Adams @ 2010-10-12 15:52 UTC (permalink / raw)
To: 7196
1. Also, the NEWS item should make clear just what has changed for which
platforms. What it says currently is incomplete and inaccurate. For example:
* "`x-select-enable-clipboard' now defaults to t." That is _not_ a change for
Windows - nothing new.
* "`x-select-enable-primary' now defaults to nil." That variable does not even
exist on Windows. Clarify that this is specific to platforms ___.
2. When saying that the new value of something is ___, you need to also say what
the old value was. That's what describing a change means: saying what is new
includes saying what the difference is from what was old.
Users or libraries might have done something conditionally based on the old
value. They need to know about the change so they can decide what to do about
the new value. This is especially true for key bindings - for example,
"`mouse-2' is now bound to `mouse-yank-primary'". Yes, but what was `mouse-2'
bound to before?
Imagine that a user or a library remapped `mouse-yank-at-click', the old default
binding for `mouse-2'. If `mouse-yank-primary' is now the default binding, then
the remapping is longer effective. At least make the user aware of the change,
so s?he can decide whether to remap the new default command just as s?he
remapped the old default command.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7196: 24.0.50; NEWS item "Selection changes"
2010-10-12 14:56 bug#7196: 24.0.50; NEWS item "Selection changes" Drew Adams
2010-10-12 15:52 ` Drew Adams
@ 2010-10-15 11:36 ` Eli Zaretskii
2010-10-15 15:49 ` Drew Adams
1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2010-10-15 11:36 UTC (permalink / raw)
To: Drew Adams; +Cc: 7196
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 12 Oct 2010 07:56:40 -0700
> Cc:
>
> The NEWS item is woefully incomplete. It doesn't explain much of
> anything about the selection changes for Emacs 24 - and they are
> radical changes.
>
> Among other things, NEWS should detail the differences from the
> previous behavior, and explain clearly how to return to the
> previous behavior (exactly, completely).
The new text is reproduced below. If it is good enough, this bug
report can be closed.
** Selection changes.
The default handling of clipboard and primary selections has been
changed to conform with other X applications.
The new behavior is that by default Emacs does not put text into the
clipboard, and does not add it to kill-ring, merely because the text
was selected. 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).
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. Text from the clipboard is retrieved only by
C-y, M-y and other commands that yank text from the kill-ring. Mouse
commands that paste text retrieve text from the primary selection, on
systems that support it separately from the clipboard.
In other words, the default behavior is that mouse gestures that
select and paste text work with the primary selection, while keyboard
commands that kill/copy and paste text work with the clipboard.
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.
To get back the previous behavior, whereby mouse gestures set the
clipboard and retrieve text from there, customize the variables
`mouse-drag-copy-region' and (on X only) `x-select-enable-primary'.
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.
These changes in the default behavior are reflected in the default
values of several variables:
*** `select-active-regions' now defaults to t, so active regions set
the primary selection. It was nil in previous versions.
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).
*** `mouse-2' is now bound to `mouse-yank-primary'.
Previously, it was bound to `mouse-yank-at-click' (which is now
unbound by default.
*** `x-select-enable-clipboard' now defaults to t on all platforms.
Thus, killing and yanking now use the clipboard (in addition to the
kill ring). Note that this variable was already non-nil by default on
MS-Windows, which does not support the primary selection between
applications.
*** `x-select-enable-primary' now defaults to nil.
This variable exists only on X; its default value was t in previous
versions.
*** `mouse-drag-copy-region' now defaults to nil.
Its previous default value was t.
*** Support for X cut buffers has been removed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7196: 24.0.50; NEWS item "Selection changes"
2010-10-15 11:36 ` Eli Zaretskii
@ 2010-10-15 15:49 ` Drew Adams
2010-10-15 17:02 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2010-10-15 15:49 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 7196
> > The NEWS item is woefully incomplete. It doesn't explain much of
> > anything about the selection changes for Emacs 24 - and they are
> > radical changes.
> >
> > Among other things, NEWS should detail the differences from the
> > previous behavior, and explain clearly how to return to the
> > previous behavior (exactly, completely).
>
> The new text is reproduced below. If it is good enough, this bug
> report can be closed.
Thanks for taking a stab at it. Some suggestions and questions below.
For info, are the following statements correct?
1. Anything you select becomes the primary selection (on systems that
support...).
2. Everything that is put on the kill ring is also put on the clipboard.
3. Everything put on the clipboard by Emacs was also first put on the kill ring.
4. Other apps may put additional stuff on the clipboard. The kill ring is
Emacs-specific, but the clipboard is not.
5. Not everything that is selected is put on the kill ring or the clipboard.
If so, consider saying this explicitly.
There seems to be a gap between #1 and #2. What's the relation between the
primary and the clipboard? What do users need to know about it?
#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?
> ** Selection changes.
>
> The default handling of clipboard and primary selections has been
> changed to conform with other X applications.
>
> The new behavior is that by default Emacs does not put text
you select
> into the clipboard, and does not add it to kill-ring
.
> 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"? 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. I don't know about the clipboard - is it a list or ring, like
the kill ring? 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.
What happens to selected text on systems that do _not_ support a primary
selection separate from the clipboard? Please add that info - don't just say
what happens for X. This is important for understanding the rest of what you
write, below. It's not clear where mouse-selected text is put on non-X and it's
not clear, when you paste with the mouse, where the pasted text comes from (on
non-X). It's not enough to keep saying that the primary is used for this on X -
what's used on non-X? If it doesn't have a name, then give it one - something
that you can refer to for the non-X case. At least make it clear, however you do
it.
And when you say "for systems that support the primary selection separate from
the clipboard" one can get the impression (but be unsure) that the other systems
use the clipboard here, since they have no separate primary. We need to state
what happens for each scenario/system.
> 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.
Say here where it _is_ retrieved from for the mouse, before going on to talk
about retrieval from the clipboard.
Why "in another application"? If not also true for text selected in Emacs, then
state also what the case for that text is.
> Text from the clipboard is retrieved only by C-y, M-y and other
> commands that yank text from the kill-ring.
> 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? This is confusing, especially since
we've said that mouse-selected text does not get sent to the clipboard/kill ring
by default.
> In other words, the default behavior is that mouse gestures that
Mouse actions - mouse gestures are typically thought of as something different.
> select and paste text work with the primary selection,
On X (you said). But you haven't said what they work with on non-X.
> 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 kind you
mean here is copy to the kill ring.
> 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. Is that the right thing (dunno)? It's
worth pointing that out, in any case.
> To get back the previous behavior, whereby mouse gestures
Just mouse _selection_, no? Not also mouse-2 (paste).
> set the clipboard
Does it set the clipboard or add to it (I don't know). The vocabulary needs to
be consistent, whatever the case might be: replacement or addition. When you
say "put into" it implies adding, not replacemnt. "Put onto" is ambiguous, but
it also suggests that more than one thing can be put onto (so can be on) the
clipboard at a time.
> and retrieve text from there, customize the variables
> `mouse-drag-copy-region' and (on X only) `x-select-enable-primary'.
Be clear - to get back the previous behavior, _set them to_ t (or whatever the
value is). Don't just say customize them; say what to customize them to.
> 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. You just said that selection does not now, by default, put text
on the clipboard. And you can restore "the previous behavior", which presumably
was putting the selection on the clipboard, by setting "`mouse-drag-copy-region'
and (on X only) `x-select-enable-primary'" to t.
It's not clear, to start out with, what "the previous behavior" was. 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.
I'm hoping that this helps you. Im not trying to confuse you, though it might
seem like that. This is not clear to a reader, IMO. It's not completely clear
even to me.
> These changes in the default behavior are reflected in the default
> values of several variables:
Maybe it would help to start with that. If the variables and their previous
values express the previous behavior, and if their new values express the new
behavior, then their descriptions should provide a clear way to say what you
were trying to say above (where you left out certain info/cases).
> *** `select-active-regions' now defaults to t, so active regions set
> the primary selection. It was nil in previous versions.
Good. (Nit: there is only one active region.)
> 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 know, this is not primarily a doc problem.)
> *** `mouse-2' is now bound to `mouse-yank-primary'.
> Previously, it was bound to `mouse-yank-at-click' (which is now
> unbound by default.
^
)
What's the difference in _behavior_? Why make readers look up each of those
commands in order to understand what's changed?
Why not state all of the options together, before describing any binding
changes?
> *** `x-select-enable-clipboard' now defaults to t on all platforms.
> Thus, killing and yanking now use the clipboard (in addition to the
> kill ring). Note that this variable was already non-nil by
> default on MS-Windows, which does not support the primary selection
> between applications.
Speaking about the "primary selection between applications" is maybe a good way
to characterize some of the missing info above: we could call the place where a
mouse selection is saved the "primary within Emacs" or some such, as opposed to
the real primary, which is between apps. Dunno; maybe it would be confusing to
reuse "primary" that way.
But some way needs to be found to talk clearly about this - about each: the real
primary, which can be between apps, and the other, unnamed holding place, which
is Emacs-specific (for non-X).
> *** `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?
> *** `mouse-drag-copy-region' now defaults to nil.
> Its previous default value was t.
What does it do?
> *** Support for X cut buffers has been removed.
What's the consequence for user-visible behavior?
HTH - Drew
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7196: 24.0.50; NEWS item "Selection changes"
2010-10-15 15:49 ` Drew Adams
@ 2010-10-15 17:02 ` Eli Zaretskii
0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2010-10-15 17:02 UTC (permalink / raw)
To: Drew Adams; +Cc: 7196-done
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <7196@debbugs.gnu.org>
> Date: Fri, 15 Oct 2010 08:49:06 -0700
>
> > > The NEWS item is woefully incomplete. It doesn't explain much of
> > > anything about the selection changes for Emacs 24 - and they are
> > > radical changes.
> > >
> > > Among other things, NEWS should detail the differences from the
> > > previous behavior, and explain clearly how to return to the
> > > previous behavior (exactly, completely).
> >
> > The new text is reproduced below. If it is good enough, this bug
> > report can be closed.
>
> Thanks for taking a stab at it. Some suggestions and questions below.
>
> For info, are the following statements correct?
Most of the time, but not always, depending on customizations.
Why is that important?
> #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.
> > 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.
> 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.
> I don't know about the clipboard - is it a list or ring, like the
> kill ring?
It's a single buffer.
> 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. Anyway, NEWS entries are
not for explaining these issues.
> What happens to selected text on systems that do _not_ support a primary
> selection separate from the clipboard?
Nothing. They stay Emacs selections.
> 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.
> > 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.
>
> Say here where it _is_ retrieved from for the mouse, before going on to talk
> about retrieval from the clipboard.
I transposed the two sentences, although I don't think a distance of
one sentence obfuscates the meaning enough to be confusing.
> 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.
> > 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.
> > 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.
> > 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.
> > 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.
> > 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.
> Be clear - to get back the previous behavior, _set them to_ t (or whatever the
> value is). Don't just say customize them; say what to customize them to.
I added non-nil.
> > 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.
> 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.
> > 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.
> > 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?
I don't know why, I just documented it.
> > *** `mouse-2' is now bound to `mouse-yank-primary'.
> > Previously, it was bound to `mouse-yank-at-click' (which is now
> > unbound by default.
> ^
> )
>
> 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.
> > *** `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.
I fixed the typos you pointed out, thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-10-15 17:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-12 14:56 bug#7196: 24.0.50; NEWS item "Selection changes" Drew Adams
2010-10-12 15:52 ` Drew Adams
2010-10-15 11:36 ` Eli Zaretskii
2010-10-15 15:49 ` Drew Adams
2010-10-15 17:02 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).