[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: The Copy/Paste Problem
From:       "Steven D'Aprano" <dippy () mikka ! net ! au>
Date:       2001-03-11 15:39:56
[Download RAW message or body]

Sergej Malinovski wrote:
> 
> If I cut/copy something, *no*matter*how*, I want to be able paste that,
> *no*matter*how*. Is this too much to ask for? I don't think so. Now that's my
> main point, and that's what you are allowed to argue ;-)

I think this means you are unneccessarily limiting yourself.

By your plan, you only have one single buffer -- as soon as you select
some text, it *automatically* over-writes what was in the buffer, so you
can't replace text by pasting. You can't even select text, copy it (*no
matter how*), then select some more text, without losing what was in the
buffer.

By having two different buffers, one is only over-written by an explicit
Cut or Copy command, and so will always be there *until you choose to
change it*. The other buffer is implicitly changed by any selection or
any deletion, as is standard under emacs, and so is easier to use but
not persistant.

> What this "no matter how" means, from my point of view, is that a user can
> choose the most convenient way to cut/copy and the most convenient way to
> paste, and that these two chooses *should not* effect (cannot find a better
> word) each other in any way.

But they will, because under your plan, there is only one buffer! So any
selection will change the Copy/Paste buffer, and any Cut/Copy will
change the selection buffer.

This is why having two buffers is better -- because there are two
buffers, the user can be confident that any selection they make *will
not effect* the text they copied using Cut or Copy. But at the same
time, they can get the benefits of emacs style
copy-on-selection/paste-on-MMB as well. The best of both worlds.



> > The point is, if you are a writer, you will frequently want to be
> > editing text, which means adding, replacing and changing lots of
> > different things all at once. You DON'T want to be scrolling backwards
> > and forwards copying and re-copying and re-copying again the same text
> > over and over again.
> 
> The current version of Klipper allows "multiple buffers", so again we have
> overlapping, unneeded functionality.

I've just given an example where multiple buffers *aren't* unneeded
functionality, but are very important, even vital. If you don't want to
use multiple buffers, don't use them -- just use the one. But don't take
them away from people who do!


> > But this shouldn't be a hidden feature. If you have it, you should also
> > make a menu command for it, for those who don't have a middle mouse
> > button, and also so that ordinary users can discover it and become
> > expert users.
> 
> Heh, two paste menu commands. See what this leads to? I mean, it won't be
> like the "Paste Special" command from MS Word, because in reality, there is
> nothing special about this middle-button paste -- the result is the same as
> if you where using keyboard alone -- so it would be like "Yank" from Emacs.
> That is what is confusing -- the so called special paste that isn't special!

Then don't call it paste. Call it yank.

On further thought, I don't think the MMB yank is amenable to a menu
command. Since the yank buffer is automatically updated every time a
selection is made, and is automatically yanked when the MMB is used to
click or drag on the text, the user has no opportunity or need to give
an explicit copy/paste commands.

I guess the yank command is something that users will learn by word of
mouth or by reading the manual :-)
(or by migrating from emacs)


-- 
Steven D'Aprano

[prev in list] [next in list] [prev in thread] [next in thread]