Mentions/tags include common punctuation

tracked

#1

Steps to reproduce

  • Use tags and use common punctuation for @ person name mentions, like ? or )
  • Observe that they show up as separate instances now for tag completion and in tags list

Expected result

  • A single @ name tag is created and recognized consistently

Actual result

  • Many tags are created for completion and in tag list

Environment

Chrome macOS, but non-version specific


Additional information / comments

It seems that including punctuation at least in some cases is by design, based on what I’m seeing in in issue #927. But if you look at my use case in the screenshots, it seems like a pretty typical one, and the results are slightly ridiculous. There’s no good reason why @Jane shows up 4 times here.

Once again, if someone relies on this behavior now, unfortunately, could an option be added for this, to strip punctuation from tag recognition? And also clean up tags previously split this way.

Completion (here I would expect to see 2 tags only, @Jane and @Jack):

Tag list (same expectation, 2 tags only):

This is a trivial example, in my real project work this is much worse, making it very difficult to find tags for completion. The workaround of always including a space before punctuation is artificial and not user-friendly.


#2

Hmm, the premise is that if you make use of auto-completion to input tags, there should be a space after the tag, separating the tag and the punctuation. Of course, this depends on the first tag being input correctly (i.e. without punctuation) though.

That might not work for some people for aesthetic reasons though.


#3

I’m not quite sure what you’re saying, Erica, about “first tag being input correctly”. The first use of the tag above, @Jane, indeed had no punctuation after it, but only a space. But subsequent uses of it now become new tags/mentions, making it difficult to see all instances/uses of @Jane.

It seems like current behavior requires a space after not just the first time, but every time, making uses of people’s names, projects, tools, etc. seem very unnatural. Is this really by design behavior?

I also don’t understand why some punctuation is properly recognized and doesn’t cause new tags, like , and :, but ) and ? are lumped in with the mention/tag:


#4

I mean if you use the auto-complete to input it, a space will automatically follow “@Jane”.

To achieve what’s in your screenshot, you’d need to either not use auto-complete to input the tag, or manually delete the space for style reasons, is that right?

Exceptions were made for , and : (for : partially to not break Powerpack). Brackets could be used in the future for tag attributes in the future. Haven’t considered the case of ? so it weren’t added to the whitelist of exceptions. That’s the reason behind it.


#5

As far as auto-completing spaces, I’m particularly noticing this in Workflowy imported data, of course, which did not consider this punctuation part of a tag. Arguably it’s another bug that you create multiple tags like this during the import process, instead of perhaps offering an option where the data is cleaned up with spaces, to comply with Dynalist’s differing rules.

I imagine a workaround proposal will be to go back and manually clean up the data, but that is a large manual effort now on my part.

You make it seem like adding other punctuation to exception whitelist is possible, does that mean this bug can get a commitment to be fixed? Having a space does not look natural before ) or ? in sentences. The tag attributes feature you mention uses a format that starts with (, but I’d be happy with with ) only.


#6

From reviewing my auto-generated tags list, the common offenders are:

  • ?
  • ;
  • )
  • /
  • !
  • .

I can give examples for all these, but they were used with mentions in natural sentences. Reply to @Erica! etc. which don’t need separate tags. Btw, notice how here in the message board ! doesn’t become part of the name tag.

On a related topic, is there a feature request to hide some tags? We use Git and pull requests, and many of my items were about code pull request numbers, like #999. So there’s a bunch of junk tags with 1 instance of some iterating number. I’d love to hide these from my tag list; please let me know if I should open up a new, separate feature request for this. Thanks.

Update: Added ., which I missed before. Yes, @Jane and @Jane. are really the same person. Hopefully not too late for your update, @Shida.


#7

There’s no dedicated feature request for this, so please go ahead and post one. I think someone mentioned it somewhere though :slight_smile:

@Shida could you take a look at these characters and see which ones should be whitelisted? Thanks!


#8

I will tweak the whitelist!


#9

Could there be a Pro feature that allowed for customising the whitelist?

-Fred-


#10

Fred, could you elaborate? Do you want to remove some of the above suggestions from the whitelist more? If it’s the latter, feel free to suggest them here :slight_smile:


#11

Sure I will elaborate. Perhaps it is because I like to be in control :wink: but I would like to control my own whitelist of punctuation that works with @mentions. That level of granularity may not be everyone, but I would definitely use it.


#12

I see, that’s not easy to do, unfortunately :frowning:


#13

@Shida, any update on when this whitelist tweak be done? And, when done, will existing redundant tags like this be automatically merged?

I’ve been trying to manually “clean up” my previously imported Workflowy tags (in quotes because I don’t really want to update them with strange spacing), but it’s a huge hassle, partially because of other searching/filtering DL bugs that make this process painful. I have a lot of bugs to file in that area separately when I get the chance.


#14

(1) No and (2) yes. Will do it soon, our current top priority is some mobile bugs that are even more annoying than this.


#15

I don’t believe the list can be tweaked per-user. This is mostly because any officially supported formatting should be consistent across user because many users share dynalist documents with co-workers, or publicly. Thus, the interpretation of formatting must be the same, unless if you use a local plugin like powerpack, which is not official.

But otherwise, yes they will be merged once the change is deployed.


#16

Another thought that I had on this was that you should’ve gone with Twitter convention, rather than coming up with your own. Hashtags were invented on Twitter, and this is the convention most everyone is familiar with.

Their guidelines on this are quite clear:

You cannot add spaces or punctuation in a hashtag, or it will not work properly.

3rd party guidelines are very similar:

Punctuations in the hashtags or after will also render the hashtag in error. Do not use apostrophes in the middle or punctuation marks in the end, including a period, comma or colon. The hashtag will end where you place the punctuation.

Etc. That whole last list is worth a read, and should’ve been used. E.g., avoiding use of “Purely numbers”. Not too late to at least match the punctuation expectations better :slight_smile:


#17

Hi, I’m a new convert to Dynalist from Workflowy. Just started tripping over these tag problems plus the inverse bigtime!

I have lots of lists where the first word is both a tag and bolded: **@Tag** fails to be a tag at all! I was wondering why tags and locations i knew were missing. It seems straightforward to not count * and _ (for italics) in making tags.

Tags also fail if they have a leading parentheses. As an academic writer who uses references a lot, i often have `(#ref-Kuhn2014, #ref-Kuhn2016)’ since these both link me to my notes on that reference, and can later be replaced with actual references. But now the first one isn’t even a tag, and the second one includes the parentheses. Is there any solution?

Here’s a summary of the problem.


#18

#ref-Kuhn2016) is the problem reported here, but if I understand correctly, the OP wasn’t complained about leading punctuation. To report and track that bug, it would be nice if you can create a new bug report on the leading punctuation issue.