emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Selection changes in revno 100822


From: Drew Adams
Subject: RE: Selection changes in revno 100822
Date: Sun, 15 Aug 2010 16:01:33 -0700

> > Express what will change for _users_, operationally, and 
> > why it is a good thing.  Don't just say that the change is
> > good and the traditional behavior is "bogus".
> 
> You seem to confuse me with Stephen.  I didn't say the old behavior
> was bogus.

No, I'm not confusing you with Stephen.  I was not replying only to you
personally.

The point is that this discussion has not expressed what will change for users,
in user terms.  Some general opinions have been expressed wrt
good/bad/ugly/bogus, without any clear expression of just what behavior changes
are proposed.  

> > State clearly what is to be gained by changing.
> 
> Consistency with other X apps, so it seems.

Yes, we've gathered that much.  But what will change, in operational terms, for
Emacs users?  Please tell us concretely and completely just what will change.
(Again, the request is not necessarily for you personally.)

> And I happen to agree that consistency with widely accepted
> GUI standards is a Good Thing, in general.

Probably everyone agrees that consistency is good, in general.  Mom & apple pie
- hoorah.

The question is what is the +/-/good/bad _for Emacs_, with emphasis on
specifics.  What behavior changes, and what are their advantages and
disadvantages.

Emacs has always been _more or less_ consistent with some outside standards.  It
has also always differed to some extent from some outside standards.

For the most part, any divergence from standards has not been accidental but
intentional - that is my impression, at least.  And over time, accidental
divergences that have little negative impact have been corrected.  IOW, other
things being equal, sure, let's go for consistency with the outside world.

What is most important wrt consistency is the _internal_ consistency within
Emacs.  And the devil is as always in the details: what changes and (for each
change) what advantages.

Complete consistency wrt an outside standard is not a necessary or sufficient
aim.  (Richard has expressed that elegantly on a number of occasions.)  It
should be only one consideration for us.

What any potential changes do to users inside Emacs is much more important.  So
far, we know little about what changes are in store here.  Lots of smoke and
noise, little fire and signal.

> > And say clearly and completely what the change is.
> 
> That was said already.  Let me repeat it (quoting David with slight
> changes):
> 
>   clipboards aren't overwritten when you merely select text.
>   clipboards are overwritten when you cut/copy (C-w/M-w)
>   clipboard text is not inserted (pasted) when you click mouse-2.
>   clipboard text is inserted when you paste (C-y)
> 
>   primary selections are overwritten when you merely select text.
>   primary selections are not overwritten when you cut/copy 
> (C-w/M-w) (but 
>     they've probably already just been overwritten because 
> you selected
>     text just before you cut/copied).
>   primary selections are inserted when you click mouse-2.
>   primary selections are not inserted when you paste (C-y)

Sorry, that means little to me.  Try saying something without referring to
"primary" or "clipboard".  Try describing the changes simply and
_operationally_, in terms of user actions.  See David's last mail replying to
you for how.

And please express them clearly as _changes_: Previously, when you did A and
then B, the result was C.  Now, the result will instead be D.  That will be
clear to all Emacs users, regardless of their knowledge of the X standard,
primary selection, and clipboard.

I repeat:

"AFAICS we haven't yet gotten a simple description of the proposed changes, in
terms of how they will affect users: use cases, pros & cons, what will change
and why."

> > That's my point: Make clear what the stakes are for users: What will
> > be changed _from a user point of view_.  And why it is a good thing:
> > advantages, disadvantages.
> 
> See this URL:
> http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt

I already saw it.

See above: Please describe the proposed changes in terms of Emacs user actions.

> It makes good sense wrt apps other than Emacs.  When applied to Emacs,
> IMO most of the reasons it gives for the above behavior are quite
> lame, because Emacs has features this document doesn't consider.  But
> there's one reason that made perfect sense to me even wrt Emacs,
> namely, that the "traditional" Emacs behavior with setting PRIMARY on
> C-w/M-w has this problem:
> 
>  - you should be able to select text, then paste the clipboard over
>    it, but that doesn't work if the selection and clipboard are the
>    same
> 
> IOW, if selecting text overwrites the clipboard, you cannot select and
> then paste from the clipboard over the selection, because selecting
> destroys the clipboard data.

Please express it in Emacs terms.  Give a recipe involving Emacs actions and not
mentioning "clipboard" or "selection".  For example:

1. Select some text with the mouse.

(If important, break that down, but I'm guessing it is insignificant here just
how selection is made using the mouse: drag, double-click, mouse-1 +
mouse-3,...)

2. Hit C-y on the keyboard.
... (whatever)

Show in that way what the problem is that you (pl) are trying to solve.
Apparently, today there is a problem that people are running into (which
involves trying to "paste the clipboard over selected text").  I'm not aware of
the problem.

Please describe it in simple terms.  Start with emacs -Q, so we'll know just
which modes are involved (e.g. delete-selection-mode? transient-mark-mode?...).

> (It is ironical that all the heated discussion regarding the reasons
> why the new behavior is "right" never brought up this reason, which
> IMO is the only one that hits the nail on the head.)

OK, so you have found a reason for the changes that convinces you.  If you
express it in Emacs terms (operationally), then perhaps some of the rest of us
will also be convinced.

Do I understand it?  Maybe I do, but I think you (someone) should express it wrt
Emacs actions.  Might as well be very clear to everyone.

What is the problem in practice?  Is it that you want to select some text A,
save that selection, select some other text B, and paste the saved text A to
replace text B?

Is that it?  Is that the only reason for all of these changes - the reason, at
least, that convinced you?  If so, then I really don't see it as a significant
problem.

I already do that everyday, using the secondary selection - which has always
been less ephemeral than and independent from the region/selection in Emacs.  I
often use that as a quick way to perform ad hoc replacements in Emacs.

Doing that using the secondary selection does not prevent interaction between
the mouse and the kill ring.  And selection of the region with the mouse is done
differently from selection of the secondary with the mouse (modifier keys), so
the mouse can be used for each independently.  And either can be used for
yanking, independently (I mentioned that I have a second kill ring for the
secondary).

You might argue that the secondary cannot be used outside Emacs very easily,
whereas the clipboard can.  That's true, but I don't miss it in practice.  I can
easily paste from the kill ring to other apps, and I can easily transfer the
secondary to the region in Emacs if I want to paste that outside Emacs.

[For me:
 `C-M-y' yanks the secondary.
 `C-0 C-M-y' selects the secondary as the region.
 `C-1 C-M-y' turns the region into the secondary.
   (IOW, it defines the secondary using the keyboard.)
 `C-- C-M-y' swaps the secondary with the region.
   (IOW it puts the secondary where the region is now.)
 http://www.emacswiki.org/emacs/SecondarySelection#secondary-sel.el]


In the few weeks that Emacs has been broken by the recent changes, I've already
tried unsuccessfully many times to paste/yank text that I had selected
previously, because mouse selection and pasting is now separate from keyboard
selection and yanking.  I cannot count the number of times that I've ended up
pasting/yanking nothing or text other than what was expected.  Including when
trying to paste Emacs text outside of Emacs.

> > It's amazing to me that we've gotten this far along with no 
> > proposal, discussion, and argument about pros & cons for users.
> 
> FWIW, the above URL was posted here long ago.  All the info you are
> looking for is there.

When it was posted long ago I read it.  I'm still waiting for a simple Emacs
recipe - a description in operational, user terms.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]