Quirky cut-and-paste

I’d like to cut a note from one container and paste it into another container, i.e., move a note from one container to another… a fairly straightforward operation. This led to “discoveries” of quirky behavior, which I’m reporting to confirm whether others see similar issues. Of course, I’d also like to learn how to perform my intended task – move a note while preserving its attributes. Details below. Thanks for your help.

Behavior A

The pasted note maintains its $Name, but unfortunately, its $Text is replaced with $Name. The original $Text is gone, as far as I can tell. Is this the intended behavior? I did not look at other attributes to see if they were preserved through the cut-and-paste procedure.

Behavior B

For fun, I made a few notes in the left most column (see image). Then, I selected each note and pressed Cmd-D (Duplicate). The good news is that this process creates a new note (to the right in the image) with $Text preserved, and a slight change to $Name. The name change for the first duplicate adds the suffix “copy”, and subsequent duplication of a duplicate, appends a number… seems logical, and consistent with how Finder behaves, for example.

Here too, however, there are some peculiarities. Notice the 2nd row, starting with the note “test”. Its first duplicate does not follow the usual pattern; if it did, I would’ve expected “test copy” to the right of “test”. Instead, it’s “test 1”. Also note row 6, which is even more puzzling. I start with the note “test2”. The first duplicate is an inexplicable “tes 1”. Weird…

If you are still with this post, I do have questions:

  1. do others see this kind of behavior with cut-and-paste and with duplication?

  2. Behavior B is just strange, but inconsequential (to me). I am, however, wondering if Behavior A is the intended behavior of cut-and-paste??

  3. how do I move a note from one container to another? I mean, I could open Quickstamp, go to the $Container attribute, and change the path. This is what I’ve been doing, and boy, that’s tedious. To emulate a copy-and-paste, I would have to cmd-D, rename the note to get rid of the suffix, then Quickstamp a new $Container name… again, tedious. There’s probably a simple way to cut-and-paste a note while preserving all its attributes, including $Text (I hope).

This came up recently in some similar threads.

Personally, I think the fastest way to move something is to change the value of $Path for that note. Changing that value immediately moves the note to the new parent container.

1 Like

I agree with @PaulWalters re setting $Container - it may appear an odd idea at first sight but after first use it becomes quite a natural way to do this, especially for lots of items. To address the other points.

Behaviour A. I don’t see this but don’t forget that when to paste notes they will fire the new container’s $OnAdd and the new location may put the items in scope of an agent that might also then act on them.

Behaviour B. This behaviour as I’d expect and as is documented. My understanding is trailing numbers are incremented whereas everything else is given a ’ copy’/‘‘copy 1’/’ copy 2’/etc. suffix.

So, I think that answers you questions 1/2/3. Do ask if not.

I cannot reproduce your condition A; copying and pasting notes preserves their name and text.

The easiest way to move notes to a new container is probably just to move them in outline view, or perhaps in chart or Treemap view.

Thanks everyone.

I identified the source of Behavior A. The culprit is a clipboard utility: Copy’em Paste (v.2.3.2). If I quit this application, TBX cut-and-paste works as one would expect, and as @eastgate described.

I am glad to find the root of the problem. However, the episode is a bit worrisome – it makes evident how complicated our machines have become when even innocent maneuvers like cut-and-paste can get screwed up by a “small” utility that should run inconspicuously in the background.

As an inconsequential matter and for the sake of completeness, I will just note that quitting my troublesome utility does not resolve Behavior B (duplication with notes named “test” or “test2” – see green and orange notes in my post above). The naming of green “test2” duplicates are particularly strange. This is not a critical issue.

I’d missed the last example when answering previously. The naming in the last green set appears to be a re-emergence of known issue #2075. I can replicate the problem in v7.2.1. I’ll report this.

In your screen grab, on the ‘macro’ line the second items is actually called ‘macro copy’ although the ‘copy’ part is not rendered in the visible part of the title. Thus further to my last all rows in your example, except the green row are working as expected. The green line shows a regression of a previously fixed error.

The “test2” name issue will be addressed in the next release.

1 Like