Pretty sure we can figure out a convenient way to include this in core. Just because its in core doesn't mean it has to be in sources folder, it can be a core plugin. IMO that gives the user more options which is a good thing.

Ideally, yes. Probably even enabled by default if I'm honest. The feature is a big draw for some and given the "only triggers on @" there's not even a performance concern.

Interesting question, what would happen with the above sentence as typed?

Nothing, it'll search for " as an username on the server side (probably not even that since I don't think the regex will match it as a valid username[1]), find nothing and leave it alone. So will the JS interface (shouldn't even do a request since technically the username is less than three characters long).

If this goes in by default, so does the notification core. I don't mind it being in by default and enabled (i'd actually love that), as long as I can keep my GH repository. So if it gets a svn:external with a special status as a "core plugin" or something so that the UI can be simplified, I don't have a problem.

\w+ shouldn't match the ", but if you're doing that on the client side it should be fine.

(It is more of an issue on the server side because all display names and usernames are all pushed through htmlspecialchars first)

Regarding core vs not core, I found through bad experience that 'core plugins' do not work that well from a user perspective. They embody everything that is wrong with Core Features: having to go to an unrelated page that was convenient for the developers to just grab everything together, and it is a proven cause of support requests. Not that there won't be support requests anyway but at least some people will use search and just straight up exploration to find it otherwise.

I'd rather either have it totally as a plugin, or fully core, I don't see that any intermediate measure suits anyone but us from a purely convenient point of view.

I would love to see both this and the notifications core being core features and completely integrated. Seems to me that might be faster?

\w+ shouldn't match the ", but if you're doing that on the client side it should be fine.

(It is more of an issue on the server side because all display names and usernames are all pushed through htmlspecialchars first)

No, I'm doing that on the server side. On the client side it's is from @ till the first whitespace.

Quote

Regarding core vs not core, I found through bad experience that 'core plugins' do not work that well from a user perspective. They embody everything that is wrong with Core Features: having to go to an unrelated page that was convenient for the developers to just grab everything together, and it is a proven cause of support requests. Not that there won't be support requests anyway but at least some people will use search and just straight up exploration to find it otherwise.

I'd rather either have it totally as a plugin, or fully core, I don't see that any intermediate measure suits anyone but us from a purely convenient point of view.

I would love to see both this and the notifications core being core features and completely integrated. Seems to me that might be faster?

Definitely wouldn't make much of a difference on speed, maybe through saving a bunch of call_hook hoops and perhaps one little query, but that's more or less about it (I've tried to keep the footprint as low as I can, so it doesn't leave me much scope either way). So it's merely a semantic choice. Plugin gives me the ability to independently work on it without having you to go through legal hoops (DCO, CLA etc.) for me and I get to maintain my GitHub repository (this is actually the only major factor stopping me). Perhaps a plugin distributed in core and enabled by default? That way it's a totally core plugin?