Trailing punctuation included in tags

Including a tag with punctuation immediately after it causes both the tag and the punctuation to be highlighted. For @example, in this sentence the highlighted portion would end up being: @example,

This cosmetic detail isn’t very significant and the expected value (without the punctuation) is added to the suggested list; however, clicking on the highlighted label (to do a search) populates the find box with both the tag and the punctuation, and this is unexpected behavior.

Steps to reproduce

Starting from scratch, what are the steps to make the bug happen? The fewer the steps, the better.

Add an item like: This is a @test. Be sure to include the punctuation.

Click on the highlighted link to perform a search.

Expected result

What do you expect to see after carrying out the steps above?

The word @test to be highlighted and clickable.

Actual result

Instead of the expected result, what happened?

The word and punctuation @test. are highlighted and clickable.


Which operating system are you using? Which browser are you using? If you’re using a desktop or mobile app, what’s the version number of Dynalist?

Chrome 55 on Windows 10 Anniversary. Sorry, not sure how to find out what version of Dynalist I’m using, but it appears to be up-to-date as of Friday, 2017-02-10 at 5pm EST.

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.

I’ve tested labels with a hash-sign at the beginning as well as an at-sign and with trailing commas and trailing periods at the end and the results seem to be the same. So things like


all seem to exhibit this behavior.

Additional comments


This was tested on the web site, sorry for not specifying that.

On the Windows app, the functionality is the same as of Dynalist 1.0.19.

Thanks for the report, @Chris_Allen!

This is partially expected, I think. You need a space in order to not include any trailing punctuation. That’s for the case where someone may want to include things like parenthesis to write fancy tags (e.g. @project(a) and @project(b)).

Our tag autocomplete will automatically inserts a space for you, FWIW.

That being said, it might be a good idea to exclude comma and period, since they are used so often. But then there are cases like @v1.0.9 where it might be useful.

I just got bit by this, I have been making a list of tags inside a set or parentheses and I need to include a trailing space to make the tag not include the parentheses in it. It is not the end of the world, just a minor bother. I wonder just how many people include parentheses in their tags though?

1 Like

Agreed, probably my top daily annoyance in using the product. Definitely in the top 3. For example, I always have to stop and think whether I need to put a space after an @ name before ; ! / . ) instead of just writing naturally. I reported it here as well and there’re some good discussions there:

When in doubt over how to implement something on your platform, just use rules that work on other ones, like Twitter. Typically parentheses aren’t considered as tag, instead of worrying about “fancy” tags. E.g., project(a) is a strange one, whereas “Don’t forget x (requested by @Bob)” is a normal thing to write.


I’d also like this annoying issue to be fixed. I often add punctuation after a tag, and it feels like a break in natural writing, as @Alex_Pasternak reported. I’ve had the impression this issue was recently fixed on Mac desktop app, but now I’m using Dynalist on Chrome on Windows and it’s there. Maybe I’ve just dreamed it!

1 Like

@Erica and team, is there any chance of this ever getting fixed? It’s literally a daily annoyance. I should be able to type “I like using @Dynalist.” without having both @Dynalist and @Dynalist. tags now existing.

The issue (at least for me) is only for trailing punctuation, so an example like “@v1.0.9” above does not apply. This would be a basic and really overdue fix, that would be really appreciated.

Even the preview text parser for this post understands the . is not part of the tag :slight_smile:

I’ve had this on my list for a while. Will make this into a priority to fix.

1 Like

Will be patched in the upcoming release.


I’m overjoyed, thank you for finally getting this one fixed!! Looks like this one and related issue can now be marked Fixed (vs. tracked state). This will be a serious daily help, after I retrain myself to use tags more naturally and not being afraid to follow by punctuation.

Hope you can throw more of these types of fixes in soon, perhaps some low-hanging fruit. Like hitting Esc key from global search which I still do without thinking all the time leading to that empty screen. But for now, that’s a big one off the list!


Great to hear!

We should have fixed it sooner so that people don’t rely on it unknowingly. There are quite a few reports for this new “bug”, e.g.

1 Like

Hey team, in solidarity with other recent bug reports due to this “fix” – I’d like to throw out a request to only drop trailing punctuation from tags. I for one, have many many many tags I’ve created over the years in multiple documents, that have use periods in particular to connect multi-word tags.

This change broke a big part of my daily workflow. It would take hours to fix them all and I find it really clean to be able to use periods in tags (and I already use other punctuation like underscores for other purposes).

Thanks for all the great work you do, love the product!

Edit: another thought - if there’s no chance the code can be updated to allow at least periods within tags (but ignore trailing), could you please add an option to toggle this in the settings?

Since this behavior has been working this way for a long time, I’m guessing others too have been using this ‘bug’ as a feature. It would be really helpful for those of us who want it to continue working this way, to have an option. It would at least to help us migrate more effectively by letting us rename tags more easily, especially those across multiple documents.

1 Like

That’s a good point. We’re considering (at least temporarily) bringing back non-training period (.) and colon (: ) to help with migration. Would that help?

Also @Alex_Pasternak would this be an issue? Non-trailing means #tag: test would ignore the colon and #tag:test would include the colon.


That would be amazing Shida! :pray:

Like I said above, @v1.0.9 seems like a reasonable tag value, even though it’s not part of my personal workflow. For me the pain point was always trailing punctuation, not mid-word. I did mention @Jack/@Jane in my the issue that I opened, but that was a sample and not really a daily usecase.

That said, I think search and replace is a reasonable workaround, so it’s really all about where you want to spend your engineering time. If I as a user had @v1.0.9 no longer working, I’d rename it to @v010009 and be done with it.

Like I also said before, if I were a DL dev here, I would pick a gold standard for tags of an existing product and just adopt that, instead of trying to reinvent the rules myself. E.g.,

Which you did eventually, but now it’s breaking functionality so has to be either easily fixable or be behind a feature toggle.

OMG! Thank you so much Shida!!! I just noticed tags are allowing periods and colons again :smile: :bowing_man:


That’s right, it’s back! I’m hoping people would eventually migrate away from using them but for now I think this should be a good compromise since almost everyone adds a space after colons and periods.


Thank you for that fix Shida! I was bummed at the thought of having to rename all my tags. :slight_smile:

1 Like

PowerPack formatting also appears to be working again correctly, which is great, while trailing punctuation fix is unaffected. So I think – hopefully – we have finally found a good compromise on this one.