Delete tags without deleting notes

This should be updated. This is far more confusing than it should be… because, as mentioned, replicants are never mentioned. Even if after creating a tag and selecting the original file, the properties tell me it has no replicants.

For example, if I move a tag to the trash and then ungroup the file from the tag, how on earth does someone know if the file is a file or a ‘non-replicant’ replicant?

if I move a tag to the trash and then ungroup the file from the tag

Under what circumstance would you do this?

Under what circumstance would you do this?

Well, I did it because I was confused about what was going on.

The point is that because things aren’t shown clearly as what they are, it’s easy to move an unlisted replicant as a file and get mightily confused in the process. I mean, if a replicant is actually a replicant, why isn’t it listed as being one? Why when I click on the original file does it say 0 replicants of it exist, when one does?

Even if you could argue that it’s a different kind of replicant, there should be clear indication something has been created from the original file, and some kind of indication the tag replicant isn’t a duplicate of the original file.

I am a little confused by the ideas discussed in this thread.

If applying a tag creates a replicant, why does the original item still indicate that it has zero replicants?

I think I want all of my items to be in actual groups and not merely in tags. Is there a way I can double check this?

They are not counted as replicants, probably in order to not confuse users.

As far as I know no, not without a script.

Since some versions it’s unlikely to encounter a situation where a record’s only parent is a tag. This is true for new records, don’t know whether the DEVONthink version that introduced the new behaviour automatically took care of old records, i.e. automatically replicated record’s whose only parent is a tag into the root or the inbox.

As far as I know now the only way you could end up with such a situation is to move a record into a tag via script. Can of course happen by accident but I doubt that’s something to worry about - given that we use test records to test scripts.

-- Replicate record to root if its only parent is a Tag

tell application id "DNtp"
	try
		set theRecords to selected records
		if theRecords = {} then error "Please select some records."
		show progress indicator "Verifying parents... " steps (count theRecords) as string with cancel button
		
		repeat with thisRecord in theRecords
			step progress indicator (name of thisRecord) as string
			set theParents to (parents of thisRecord whose location does not start with "/Tags/")
			if theParents = {} then
				replicate record thisRecord to root of database of thisRecord
				set theTags to tags of thisRecord
				set tags of thisRecord to {} -- necessary to reassign "parent 1" to a non tag record
				set tags of thisRecord to theTags
			end if
		end repeat
		
		hide progress indicator
	on error error_message number error_number
		hide progress indicator
		if the error_number is not -128 then display alert "DEVONthink" message error_message as warning
		return
	end try
end tell

Edit:

In case someone wonders why tags are temporarily removed:

Without that asking in a script for parent 1 still would return one of the tags. That means any script that uses parent 1 would then act on a tag and not on a group, i.e. we would likely run into trouble which hardly can be tracked down.

That’s not true. One can make a tag the only parent of a record by dragging the record onto a tag while pressing ⌥ ⌘.

@cgrunenberg This should be made impossible, I think.

Right now this is still supported only to improve the compatibility to version 2 and some rare workflows. Few users stored all their docs only inside Tags (although this was never recommended or suggested). As long as nobody needs this anymore, it could of course be disabled.

2 Likes

The next version will finally disable this.

1 Like

I agree, this is totally confusing! Why are replicants created at all when I only want to apply tags?

Again, you should at least MARK those replicants as replicants (highlight them in red or whatever), so I can recognise them. Will anything related to this be improved in future versions?

It is part of the mechanism relating to the underlying index and database structure. There’s more going on than a simple application of attributes.

Why do you need the replicants in the Tags marked in red? If you’re browsing in a tag group, it’s clear they are files that have that tag applied. And if you’re not in a tag group, you’d never know the difference as there are other ways to see the tags of files.

Ok, I get the point that it is a more complex process when applying tags and it is somehow needed that replicants are being created.

Still, I think what some of us users scares is when it comes to removing tags again. If I delete a tag group and than open the trash and I see all those items in there which where tagged before and now not being marked as REPLICANTS, it lets me think these are my original items. This is confusing. So it would be wonderful if I could see IN THE TRASH group, that these items are only replicants. Do you get my point?

Yes, I’m clear on your point. Development would have to assess the change in behavior.
Outside of having them shown in red - which indicates normal replicants - what visual cue do you feel would be sufficient?

Thank you for your openness regarding this. Well, IMO a very simple yet powerful visual mark beside the colour would be showing its name (the replicants) in Italic - and only the original files in standard font. Or is this being used elsewhere already? What do you think?

No problem!

Replicants are already shown in red italics.

Actually, I just noticed a distinction.
A normal file in the Trash has a strikethrough.

image

A trashed tag replicant does not.
image

4 Likes

Oh, how interesting! You are right. I didn’t know that! Actually this is something I can work and live with. :grinning_face_with_smiling_eyes: This “feature” is absolutely sufficient to me. Thank you! :blush:

Excellent and I’m glad it works for you. Cheers and welcome to the forums! :slight_smile:

Thanks. I’m quite new to DEVONthink as you can guess, I’ve been using it only for a couple of months now, but already it appears to be super handy for me. Needed this tool for years and didn’t know it existed, haha.

You’re welcome and glad to hear you’re finding it useful!

Hi Bluefrog

As always, your comments are extremely helpful. I have only just fallen on this topic, but, in fact, I find myself a little confused.

I had always assumed that replicants (unlike duplicates) were just aliases. But a quick test seemed to show me that when I deleted a replicant, and then searched for it in trash, the replicant was of the same size as the “original”. (So if every item in a database had a replicant, the database would double in size?). I had also assumed that a tag was a kind of alias, too.

Does this mean that if all the items in a database are given four tags, the database multiplies in size by five? Even if the tags are only applied to parent groups?

I now find myself a bit nervous about deleting tag groups in case the original goes too. Never seemed to happen to me, mind you. Is there perhaps a quick way to remove tags instead of deleting them, bearing in mind that removing tags one at a time is very slow?