Tags list includes '#' and '@'


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


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.


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.


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.