Why Isn’t Cut and Paste A Stack?

Every post containing a quote and a link requires swap between the windows to copy first the quote, and then the URL for the link. And hence my question, why isn’t cut and paste a stack based system? Even if it wasn’t by default, it’d be really useful as an extension. In fact just by adding a modifier to Control-C/X and Control-V would create something useful:

Ctrl-C – copy the selected text, clearing the stack

Shft-Ctrl-C – push a copy of the selected text on to the stack

Ctrl-V – copy the selected text, peeking from the stack

Shft-Ctrl-V – push a copy of the selected Text off the stack

Wonder how much use it’d get if it was there? The default behaviour is identical to what we have now, so where is the harm? What am i missing? Maybe we don’t have this because of past memory restrictions… can’t see why it’s not doable now.

Advertisements

9 thoughts on “Why Isn’t Cut and Paste A Stack?

  1. First of all, why two different push operations? One seems to be enough.
    Then: how do I cycle through the stack of pastes to find what I want? Keep pasting them until I have what I want? And then repush the others? Urgh..

    That brings us to the real reason for the lack of this feature: Lack of UI concepts to make such stuff viable. Some kind of inspection method for the stack. Integrated seemlessly the way the key actions are. Maybe a context menu operation? Just a popup?

    Then again, X hasn’t yet even discovered that letting the application manage the clibboard memory, thus loosing the clipboard by closing the application you copied it from.

    KDE and Gnome both had some panel applet solutions to the clipboard problem which never really made it.

    There are many questions like this. Like: Why do we still “Save” stuff?

    Everything the user does should be cherished. If the user closes an application, save it somewhere as “Unnamed work from last Monday / January / 13.1. 2010” and then exit.

    • The two push operation are because it’s the easiest was to maintain backward compatibility.

      I’m not that worried about cycling back. For me this is really solving the problem where i want to couple several distinct items from one application to another. Really limited.

      This is another of the reasons that xclipboard was a waste of space – the cut buffer was only one slot. Yawn! If the clipboard was a stack the app would actually have something to do.

      Hasn’t Apple started to do away with ‘Save’ as a concept in OS X Lion? Should probably upgrade sometime… one of the problems with OS X is that it has long ago become far to comfortable, and makes upgrades unnecessary.

  2. Reminds me of using an HP calculator instead of a “normal” one… But I could see the stack (or at least the past, say, 10 lines) at all times and could move items up and down the stack (by rotations, yes, sometimes annoying) That means to have an app (or gui or whatever) that allows you to browse the stack. Does it call for the need of an external app or does it call for the need for an embedded function in all apps.
    I need to have a look at how vi(m) is handling the thing.
    But I agree with you Jon, cut/paste is too limited to be useful in certain situation, albeit for a bunch of nerds, probably a niche.

    (note: I use app, I mean software, bad me…)
    (note 2: got me thinking at 8am in the morning, wow!)

    • I think the closest thing in vi(m) is buffers, but it’s too abstract / complicated to ever take the place of a simple stack. At least in my mind.

      You’re right that it’s a niche, but there are many keyboard bindings that are completely unknown to people. Can’t see why one more would hurt.

  3. There are some half assed implementations by MS Office. At least I remember something like this.

    But honestly, unless you really have a good memory you not going to remember what you have in your clipboard stack. It sometimes would be really awesome, so I installed “ClipMenu”, a free clipboard stack software, and then I forget all the time that I actually had it installed.

    Normal human beings do not even know that there are keyboard shortcuts for this …

    • “Normal human beings do not even know that there are keyboard shortcuts for this …”

      That’s precisely why it seems like it would be harmless to implement in the way i described.

      ClipMenu. Will check it out. Thanks 🙂

    • Yep, it would need to be another modifier key.

      Next time i remember i’ll look around for something implementing it…

  4. I built this.

    Years ago, no dual modifiers, a bash script that pushes each cut/copy operation into an array, and pulls from it in LIFO order and injects it into the clipboard until a new cut is made each time a paste is made, it works for text, urls and the like only, but it can be confusing, mine being a bash script is slow, and runs as a daemon. But it’s handy as *&@# for me. Because stack logic and state is utterly intuitive to me.

    There are tons of ways to address visibility of the stack, but Apple is dedicated to breaking every HID rule they ever wrote, and stupefying OSX to the point where any real “pro user” is going to be endlessly frustrated by the fact that their $3000 computer is now no more functional than a $300 phone.

    MacOS (PreOSX, had a menu item for viewing the clipboard under the EDIT menu).

    Personally, I think a contextual control-click would work just fine.

    $ man pbcopy

Wise words...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s