Tags list includes '#' and '@'

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

Just to follow up on the status of this bug, since weā€™re cleaning up the existing bug reports.

Is the original bug (tag list includes # and @) still a problem?

I understand there are other related requests, like ignoring numeric-only tags, could you please make a feature request for that? Thanks in advance!

@Joseph_Fieber @Alex_Pasternak

1 Like

No empty @ tag, but Iā€™m sorry to report that I still have ā€œ# (3)ā€ showing in the tag pane. Even after signing out and back in. Not at all a major issue for me though.

Same as Alex. No more empty @ tag, but still have ā€œ# (3)ā€ which when clicked pulls up search of every ā€œ#ā€ that exists.

1 Like

Weird, you even have the same count of # as @Alex_Pasternakā€¦

Could you try showing checked items and note and see if you can find those 3 mysterious tags?

Yea, strange. Like I said, if I click it I just see a search for every ā€˜#ā€™ in the document (hundreds). Iā€™ve scrolled through a bit, I canā€™t tell how it would be picking out any 3 in particular. I thought maybe it was finding just ā€˜#ā€™ by itself, without being part of a larger tag, but when I search for # followed by a space, there are dozens, so itā€™s not that.

1 Like