Tags list includes '#' and '@'

I have some unexpected entries in my Tags list.
My Tags list includes ā€˜@ā€™ (Just the ā€˜atā€™ symbol by itself), which when selected shows me entries within email addresses and other non-tag related entries

My Tags list includes ā€˜#ā€™ (Just the ā€˜hashtagā€™ symbol by itself), which when selected shows me 61 (of a total of 751 tags) of the hashtag symbols at the beginning of other existing tags. For example, when I click the ā€˜#ā€™ Tag, it shows me #Weight with just the hashtag selected. #Weight also appears in the Tags list and functions normally. There is actually 61 ā€˜#ā€™ tags in ā€˜Document Tagsā€™ and 63 ā€˜#ā€™ tags in ā€˜All Tagsā€™

My Tags list includes a ā€˜#1ā€™ tag that is the suite number from within an address. Any way to detect addresses and exclude them from tagging? Or maybe provide an ā€˜Ignore tagā€™ option to weed them out of the tag list?

Environment

Iā€™m using the web version of Dynalist on the latest version of Chrome for Mac OS, and on an up-to-date Chromebook. I see the same results in the Dynalist app for android on a Pixel XL running Android 8.0.0.


Additional information

Anything else you think would help our investigation, like a screenshot or a log file? You can drag and drop screenshots to this box. For large amount of text, try putting them into something like Pastebin.


Additional comments

1 Like

Same issue, I was going to log this possibly. Also the new sort setting is not remembered, even though Iā€™d rather have it always sorted. Perhaps I need to open a new one on that?

Yeah please do. Itā€™s sorted by # of occurrences when you refresh/restart app.

Some things (like which format you last exported too) are not persisted (remembered across sessions), since they are not as important. Tag sort is probably one of the more important things.

Regarding the bug itself, weā€™ll fix it and not let # and @ alone show up as tags. Sorry about that!

I see that this was addressed in the latest update, and the @ has disappeared from my tag list, but the # still exists. Strange thing is it shows there are three results, but when I click it in the list, the search shows every tag that exists since itā€™s searching for #.

Have you refreshed the page? Just curious.

Yup, definitely, I see this on multiple computers, multiple platforms

I see, thanks!

@Shida looks like the fix is not complete then.

Actually, I just pulled it up the app on Android, did a refresh, and both the @ and # are still in the Tags list, seems the fix didnā€™t work there at all.

The change hasnā€™t been deployed to the apps yet. Right now itā€™s only on the web version.

1 Like

I still have 3 tags reported for # in the my tag list. What is the expected behavior when a hashmark is used in regular sentences? E.g., if I have notes like ā€œneed to reduce # of bugsā€, is that supposed to count as a tag?

I wanted to find which 3 items are being counted, but this is very hard. Clicking # just launches a search with ā€œ#ā€ character, which identifies hundreds of items. If I search for "# " with space to find sentences like above, I get more than 3 results.

It should not be recognizedā€¦ I canā€™t figure out why you can still see # in tag listā€¦ Guess what we can do is manually exclude # and @ from the tag list for now while we continue to debug the issue.

Let me know if you can find an occurrence of # thatā€™s being recognized as a tag.

1 Like

Strange that we both have 3 results for #. Related to this is a feature request Iā€™m going to make. The ability to ā€˜hideā€™ or ā€˜ignoreā€™ certain tags. Iā€™m thinking of, similar to you, those non-tag uses of the #. Like an address that includes something like ā€˜Suite #200ā€™. It would be unreasonable to expect the software to properly predict every use of a tag, so having the ability to ā€˜ignoreā€™ specific instances in our documents would be a good work-around to keep our lists clean, without missing those things we really want to be tags.

1 Like

While I support in general the feature to hide certain tags, thatā€™s almost unworkable for me, as I have too many Iā€™d have to do that for. My dream feature would be to ignore tags starting with a number, which would also fix your ā€œSuite #200ā€ example.

We use BitBucket here for code reviews, and pull requests are numerically numbered. So any time I reference an email subject, for example, in DL thatā€™s a tag in the list. Just a small taste:

Iā€™d love to ignore these en masse.

@Shida, the tags are probably being indexed from real data like this, typically when people use # as shorthand for the word ā€œnumberā€, which is quite common. From my real data:

  • Automation result for Prod build # 582 ā€“ 591
  • Wrong version # in installer

Could you refresh (web) or restart (desktop) and see if that clears it? What Shida meant is that examples like those shouldnā€™t be indexed at all, so they might be ghost tags and are clearable on refresh/restart.

Let me know if that doesnā€™t work.

Yeah, I agree.

@Joseph_Fieber maybe there should be an option to ignore tags that only contain numbers. That should eliminate these en masse without any manual work.

1 Like

Iā€™ve restarted Firefox since then, which certainly refreshed the page. Also just now logged out and back in. The # (3) is still there, sorry, along with its useful friends. (In case you may ask, #1x1 is a non-junk tag, but I would be happy to rename it to #OneOnOne if numerics became ignored)

#1x1 is fine because itā€™s not 100% numeric (the ā€œxā€ in the middle).

And thatā€™s weird, after restarting the browser it still doesnā€™t work (logging out and back in is not required but I appreciate that).

Hereā€™s a screenshot from latest production and you can see # alone is not longer indexed.

Iā€™m happy to try something else, if you have suggestions. I agree that with newly created data, the empty tag does not seem to appear. But for historic data, it seems to be there.

Since you canā€™t click the tag to see its instances, only launch a search with ā€œ#ā€ as default, itā€™s really impossible to know what itā€™s indexing (for me). I tried adding ##, various combinations of spaces, etc. My 2 suggestions from real data from above also donā€™t make that tag register in a new doc.

However, the # (3) for me is a super-minor issue, compared to the others. This can be the bottom of the backlog :slight_smile: With 100% numeric tags removed, the list is already really cleaned up. Now if trailing punctuation could just be ignored, the tag list would be nearly perfect. After much manual cleanup, I still have stuff like this:

Thatā€™s weird, as we re-count the tags every time you restart/refresh, so it shouldnā€™t matter which tags are new and which are historical :frowning: I hope we can figure that out soon.

1 Like