◀ Merged tasks: T5572.

T5572 discusses stripping the domains instead, but I think this (recognize these domains as "this Phabricator install") is a better and more consistent approach.

That makes sense as this way the entered content in remarkup is not "magically" different from the one saved.

However, pattern matching should be a bit relaxed i.e. https://secure.phabricator.com/T5378 and http://secure.phabricator.com/T5378 should work as well as https://secure.phabricator.com/project/view/43/ vs the tag version URL like https://secure.phabricator.com/project/tag/aphflict/ (which I never understand how to get to).

This stuff is getting a bit easier -- at HEAD, #aphlict produces Aphlict and the project page shows the hashtag.

I meant sometimes when I navigate to a project, the URL for the project page becomes /tag/aphlict or something instead of the obscure /project/view/43/. I don't understand what are the rules for this.

This request has been evolving at https://phabricator.wikimedia.org/T76095 and now we think that the good solution is to actually parse "https://secure.phabricator.com/T5378" just like T5378

As reported in the Wikimedia task, Quora does this, Jira/Confluence does this, Facebook does this, and MediaWiki's VisualEditor is about to be able to do this.

I can update the description unless someone has a strong opinion on keeping the current rendering of full URLs.

I have a mild opinion about rendering the full URL -- I think we're better off preserving features of the input text when we can, and overall find features which discard input text to be frustrating more often than helpful. For example, if I type:

Enter http://blah.com/T123 in your browser

...and it eats the URL part, so another user only sees:

Enter T123 in your browser

...then the formatting has destroyed an important part of what I meant to communicate. This only happens, say, 3% of the time, but it's super frustrating to me when it does, and way worse overall than the tiny benefit provided by it making the text a little prettier 97% of the time.

Formatting these with or without the URI is trivial; the only real difficulty is that URIs parse early (priority = 400) and object references parse later (priority = 450). The URIs that we currently special case (Asana and JIRA, when linked) are handled by a separate rule which runs earlier (priority = 350).

If we move the object reference rule before the URI rule, we need to make sure we won't pick up object references in the middle of URIs, which may be a bit tricky. For example, the URI http://example.com/en/Terminator_(T1000) would currently consume the T1000 as an object reference before the URI rule consumed the URI, producing the wrong result.

If we leave the object reference rule where it is and introduce a new earlier rule to handle these URIs, it needs to share code with the existing rule. This is also a bit involved because the existing rule is extensible and heavily subclassed.

Ideally we would not modify the RAW text at all, rather

http://blah.com/T123 and {T123}

would render identically as T123 Title of the Task

When quoting or viewing raw the full url would be easily visible and accessible

I have a basic implementation of this in D12691 and D12692. It's really hacky, but seems to work... I'd like to iterate on this after hopefully receiving some initial feedback. I'm not exactly sure how I should proceed.

thx for deduping

We should make sure to include mentions support too.

D12692 is nearly the correct patch for this (and will support mentions, file embeds, etc., although currently not Fixes http://example.com/T123, which is parsed somewhat separately -- but that is also fixable fairly easily), it just has some tricky regex/execution order stuff that hasn't quite been sorted out.

I'll steal it the next time I'm touching this stuff if it isn't in HEAD by then. There may be a hovercards/handles/etc iteration in Projects since subprojects will need some changes here.

Per the latest update in D17502, this remains involved.

This is also extremely silly, but I sometimes do it because I'm dumb and have muscle-memory for ⌘+1+⇥+⌘+V+⏎: searching for an object URL doesn't jump you to that object URL, but you probably meant to put it in the other box.

PHI1224 describes a somewhat-adjacent situation: an install would like a way for external automated tooling to reference source files and generate editor links for them.

I'd like to do this by first recognizing Diffusion URIs and specializing them, then introducing a {src ...} rule to refine the behavior. This charts a course fairly squarely through this task.

This is vaguely the same as T9720, although at task doesn't have much of a use case and I expect to just nuke it as nonactionable once {src ...} and URI recognition exist.

In my attempt to revise D12692, I initially made a big mess and concluded that this should be several passes. I'm going to attempt that approach:

• Pass 1: Match {self-uri} and self-uri and variants. This is a version of HyperlinkRemarkupRule which runs first and is selective about which URIs it matches.
• Pass 2: Match all other URIs.
• Pass 3: Match monograms.

I think the major trick is that passes (1) and (3) need to share a lot of the same rendering code, and the monogram rule logic is currently very deeply baked into the Remarkup rule, not some sort of nice separate "reference to an object that we're going to render Engine". I think this is likely not too difficult to extract, though, and we'll probably end up in a better place for it since it's not terribly clean today (some of the embed / mail stuff didn't really fit cleanly into the original design, I think).