Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User tags are disabled if followed by comma, colon, ... #8465

Closed
2 of 7 tasks
HenrikBengtsson opened this issue Oct 11, 2019 · 3 comments
Closed
2 of 7 tasks

User tags are disabled if followed by comma, colon, ... #8465

HenrikBengtsson opened this issue Oct 11, 2019 · 3 comments
Labels
type/enhancement An improvement of existing functionality

Comments

@HenrikBengtsson
Copy link
Contributor

HenrikBengtsson commented Oct 11, 2019

Description

Putting a comma, colon, or a semicolon after a user tag causes the tag to _not_ link to that user, e.g.

1. @hb works, and
2. so does @hb.
3. However, using @hb, @hb:, or @hb; do _not_ work.

Similarly, putting a user tag in curly brackets disables the link, e.g.

4. Moreover, (@hb) and [@hb] work, but
4. {@hb} doesn't.

As a reference, all of the above works on GitHub.

(I fenced the description to make it easy to cut'n'paste for testing).

Screenshots

gitea_1 9 4_tagging_bug

@guillep2k
Copy link
Member

guillep2k commented Oct 15, 2019

This could be fixed in the regular expression that parses mentions. I'm not sure if it's always advisable, though. I didn't analyze this myself, but perhaps there are many cases where text looks like a mention but it's not. As a mention immediately sends an e-mail, false positives could be very annoying.

Probably a good trade-off would be to accept ,, ;, :, ? as long as they are followed by a spacing character (i.e. space, tab, end of line).

@HenrikBengtsson
Copy link
Contributor Author

A false negative that I keep hitting on a daily basis is when I mention someone as:

Hi @hb, can you please have a look at this?

Much less common, we have at times wanted to do:

...

Probably a good trade-off would be to accept ,, ;, : as long as they are followed by a spacing character (i.e. space, tab, end of line).

That sounds like a reasonable tradeoff.

@lunny lunny added the type/enhancement An improvement of existing functionality label Oct 15, 2019
@guillep2k
Copy link
Member

This can be closed as per #8889

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

No branches or pull requests

4 participants