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 
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 
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!
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
I just thought of something: do you have the habit of using unicode characters after #?
Iām glad someone else is echoing this. The solution should be to tie clicking tags to actual indexed results, not just to a search default. Then you would immediately see where empty # or any other bad tags lead.
Itās possible. I have some different types of coding snippets here and there. Some of it is marked as code, but not everything. Will probably go through and mark it better once the option for multiline code becomes available. I agree with Alex on tags leading to indexed results!
Tie items to the tag itself is a good idea to avoid things like this, also to avoid scenarios where you search for ā#tā and end up seeing ā#tag, #test, #teeheeā.
Unfortunately the way tag list is done right now, itās more of a helper that helps you list, sort, and search for tags. Itās not treating tags as anything more than a string right now, but it should. Thatās another feature request on its own though.
Regarding the mysterious #/@, the thought just came to me that it might be caused by invisible unicode characters, but thatās kind of hard to debug. Of course itās not possible if you never copy from other sources or use unicode extensively. Weāve seen this case where people use some unicodes that invalidates the OPML file (because itās an invalid XML file in the first place), thus preventing the OPML file from being imported at all, because an invalid XML file cannot be properly parsed.