[wplug] multiple clipboard buffers & log (formerly of "Re: win4lin?")

David Tessitor dttessitor at home.com
Fri Dec 22 18:31:55 EST 2000


Beth Skwarecki asks:

> What are the programs that you've seen implement multiple
clipboards? I
> haven't come across any myself.

> David Tessitor wrote:
> > (While we're at it, it would be nice to have several layers of
clipboard
> > buffering to hold multiple cuts without losing them.  I've come
across a
> > couple programs which allow that and it's a nice feature.  I've
more than
> > once wished it was in place when I've absentmindedly cut twice
before
> > pasting out the buffer and lost some recent writing before it
was saved; it
> > always seems to be from seeing a quick one or two word edit move
and
> > making it while in the middle of figuring just where I'm
supposed to paste
> > down the numerous paragraph move I've already cut -- ouch!)


Luquilla Hughes mentions that Emacs has 8 such buffers.  I'm not
sure where I saw it, but the number 8 was in my mind when I wrote of
it so maybe that is what I was thinking of.   However, I don't use
Emacs at all, so I would have had to have noticed it on a very
cursory glance through a how-to or something.  I also seem to
remember that I may have seen it before I started fooling around
with Linux.  If so it was probably not a big name program and could
be as far back as one of the CPM programs (PerfectWriter was one
that I used).

It's nice to know Emacs has that function.  The question is, does it
work when cutting from and/or pasting to other program windows?  It
would be nice to have something that could  be used between any
program or window.  An automatic multiple clipboard functionality is
somewhat similar in concept to having multiple desktops and
workspaces.

Beth's proposal is a very logical and workable extension of this
line of thought.

Beth Skwarecki wrote:

> I would *really* like to see multiple clipboards. My temporary
solution is
> to use the mini-commander applet in my (GNOME) panel - it's a
one-line
> terminal, basically, but I also see it as a tiny text field that
can hold a
> bit of text. Does nothing for multiple paragraphs, of course, but
before the
> sticky-notes program started getting too obnoxious I was using
that as
> well.  I can't wait till somebody actually implements multiple
clipboards.
> I can see it being handled like suspended (ctrl-Z'd) processes -
they're
> automatically numbered for you, and then when you paste you get
the
> last one by default or can select (perhaps with modifier keys?)
which
> clipboard to paste from.

-------

A step further -- complete logging of all changes

For the extremely anal retentive maybe in addition to multiple
clipboard buffers there could also be an option that would save all
buffered cuts,  moves, etc. to a special log file.

Actually, this is not as outrageous as it sounds.  There are times
when something that was not wanted and for which there was no place
to use it was discarded, only later to come to mind as appropriate
somewhere else.   This recording process could be in the form of a
compacted log with referencing info of the file, of when, and of
where the material was cut, copied, pasted or deleted.

For near term purposes this could be reviewed when necessary to
retrieve something.  It could also be used by writers, maybe even
graphic artists, or in any professions where it is handy to be able
to demonstrate to a paying customer just how much work was actually
done.  For training purposes and self evaluation it would enable an
analysis of the work process and possibly a means to make reasoned
adjustments (e.g. rather than always starting out as such and such
only to eventually go through a similar process and end up at the
same particular point, maybe a few tactical changes could speed
things up or produce better results).

Also for the purposes of future historians, when the Shakespeares or
Blakes of the coming millennium compose their masterpieces, there
would again be a valuable record of their creative process for the
academics to analyze.  We don't have as complete a record as
historians would like to have, but when paper was the only medium in
many cases a record of revision was preserved --- and, to many
people's amazement, it usually demonstrates that rather than
flawless inspiration, it was usually more a matter of hard work and
repetitive rewriting that produced a classic gem.

With wordprocessors we may have versioning capabilities either
within a single file or by keeping multiple files, but we still do
not have the same detail of process.  I can put something down in a
hurry and completely revise it several times between saves such that
even with frequent auto saves and auto backups the intermediary
process is lost.  But on paper each of the first efforts and each
later intermediary change is preserved by scratch marks, squiggles
with arrows, and scribblings in margins or between lines -- the only
thing lacking with the old paper trail is part of the sequencing
and/or timing of the changes.  A continuous log could not only
retain all the same information, thus returning a lost record we are
now foregoing, but it could also add to it an understanding of the
sequencing and time involved.   (As mentioned above such a detailed
mirror of the process could prove invaluable for self-analysis in
the present)

Of course, some might worry about big brother or the Pointed Haired
Bosses (PHB) looking over everyone's shoulder.  But really, the
information saved would be only a little more than when paper was
the medium by default.  Oh, for those who worry about consuming too
much storage with all that information, how else are you going to
fill up those 100 Gig IBM hard drives which John Dvorak expects by
next summer will be for sale at under $100?

Such logging might be readily possible with Linux right now, I don't
know.  If it is, let me know.  I would be very interested in playing
with it to see how it can best be utilized.

David






More information about the wplug mailing list