I tweaked the description so there's an easy comparison between the two behaviors currently.

The request here seems straightforward enough. No idea how easy or difficult it'll be to implement, though.

Thanks @MZMcBride better comparison, the formatting is what I'm expecting, but not only the formatting but expanding the name and possibly the task status (this is something Jira does well)

Like this?

T76094: Have tasks with due dates displayed on a calendar

Yes, just make it automatic, not everyone will know your wizardry

{T76094}

It's pretty simple, and there is a Help icon at the corner of the textarea. Usually people learn by seeing that it is possible to do it, and observing how others have done it (by looking at "View Raw" in comments or "Edit Task" in descriptions).

In T76095#789521, @Qgil wrote:

Like this?

T76094: Have tasks with due dates displayed on a calendar

Oh, that's a new one for me. :-) Neat trick.

no one is doubting that is is possible or learnable, but it seems like a small task to make it automatic.

Quora does this, VE is about to be able to do this, Jira/Confluence does this, Facebook does this. So yes, it is a common practice, both for internal and external links.

I'll see if i can find an open source library for this. but yes, it is a common practice, and something users expect.

a resource for this — http://stackoverflow.com/questions/4348912/get-title-of-website-via-link

In T76095#789880, @Jaredzimmerman-WMF wrote:

Quora does this, VE is about to be able to do this, Jira/Confluence does this, Facebook does this. So yes, it is a common practice, both for internal and external links.

Fair point.

I think you'll have an easier time selling the idea that https://phabricator.wikimedia.org/T76094 be treated equivalent to T76094 than you will trying to sell the idea that https://phabricator.wikimedia.org/T76094 be treated equivalent to T76094: Have tasks with due dates displayed on a calendar.

The former is relatively easy and straightforward to implement and brings in expected behavior. The latter is more difficult to implement because it immediately requires an opt-out (when people want to only insert a link to "https://phabricator.wikimedia.org/T76094"); compare with how Facebook has a little X that pops up to remove the auto-generated mini infobox about a pasted link which I always use. :-)

What are the use cases where a user would want to insert a full url?

sent while mobile

In T76095#790305, @Jaredzimmerman-WMF wrote:

What are the use cases where a user would want to insert a full url?

I think you mean render a full URL as a literal URL string. You and I both copy and paste ("insert") full URLs all the time as it's very convenient. :-)

It's a bit a matter of expectations, particularly among the more tech-savvy audience. Again, I think either option I mentioned in T76095#790292 is fine, but the latter option (treating "https://phabricator.wikimedia.org/T76095" the same as T76095: Pasting Phabricator task URLs into descriptions should create pretty link) would require an opt-out of some kind from my perspective. Maybe there's another syntax that could "protect" a full link.

I'm re-opening this task for further thought and consideration. I'm also strongly considering instituting a "no declining for X days" rule in Phabricator. There's no deadline and a holiday weekend is here in the U.S., which means more free time and time to think about workflows and niceties and whatnot. Please, slow the hell down with the declining. Give ideas time (days and weeks, not hours) to flourish and grow and be discussed (or die... but let it happen organically!).

AFAICS this doesn't "need discussion", it would clearly be an improvement. How to state that in the fields/workboards?

MediaWiki doesn't have this behavior either when pasting URLs of internal
pages. I'm personally happy with the current behavior.

In T76095#790373, @MZMcBride wrote:

It's a bit a matter of expectations, particularly among the more tech-savvy audience. Again, I think either option I mentioned in T76095#790292 is fine, but the latter option (treating "https://phabricator.wikimedia.org/T76095" the same as T76095: Pasting Phabricator task URLs into descriptions should create pretty link) would require an opt-out of some kind from my perspective. Maybe there's another syntax that could "protect" a full link.

It looks like http://www.example.com and http://www.example.com/ (the former link being unadorned, the latter link being wrapped in double brackets) render the same.

Some months ago, we upstreamed a request that conflicts with this one: T253: Phabricator task URLs don't enjoy hover text. Should we merge them and discuss which is the behavior desired?

As Wikimedia we should push one request at most, not two competing.

@Qgil, let us never ever ever use Mediawiki as the benchmark for how an interface should work ;)

I don't use MediaWiki as a benchmark for how thing should work, but as a benchmark of how demanding we should be with a team of basically three full-time developers. Every request takes a % of their bandwidth, and this is why I think we should filter small / non-obvious requests and promote the improvements that really matter, for our own benefit.

But still, I haven't used any tool that will not present a full URL when pasting a full URL. Have you?

But still, I haven't used any tool that will not present a full URL when pasting a full URL. Have you?

yes, did you see my comment above? "Quora does this, VE is about to be able to do this, Jira/Confluence does this, Facebook does this."

I think that list runs the gamut of serious (Jira/Confluence) to frivolous (facebook) all using this a pattern.

The bandwidth is trivial, we can put the onus on the more technical user to "learn the syntax" for pasting in raw links and allow the default behavior to be "pretty links" or more accurately "useful links" I'm not asking the team to prioritize building this internally, but making an upstream request and not closing it seems reasonable.

Trello also does this. https://trello.com/c/nIDJHl8s/821-search-tracking - Those prettified links are all just bare URLs.

In T76095#795621, @Qgil wrote:

Some months ago, we upstreamed a request that conflicts with this one: T253: Phabricator task URLs don't enjoy hover text. Should we merge them and discuss which is the behavior desired?

Agreed they should be merged, but prettified links already/implicitly have hovercards, so I'd suggest Merging that one into here, and updating the upstream request accordingly.

Alright, commented at https://secure.phabricator.com/T5378#85925

Thanks @Qgil!

I believe this is now largely resolved by upstream changes connected to https://secure.phabricator.com/T5378. This is the new behavior:

Because Phabricator is often used for technical discussion and I believe faithfully representing what the user typed is often important for clarity in this kind of discussion, raw URIs in text still render as raw URIs by default. An example is that if someone says "Next, type https://.../ into your URL bar", I don't want the default behavior of Remarkup to be to mangle the intent of their statement by completely replacing the text of the URI (which they intended literally) with a fancy human-readable alternative that doesn't have the text they provided, because this can reduce clarity and create frustration in common cases, especially for newer users.

Although the text we render is still the raw URI, it gets a special visual style and a hovercard, so you can mouse over it to see details about the task it refers to. Put another way, the text https://example.com/T123 now behaves roughly like T123 (the original text is preserved, but rendered with a special style and a hovercard).

The {URI} syntax now acts like {T123}, and renders the full title of the referenced object. In this case, the author is almost certainly explicitly requesting fancier behavior from Remarkup, so we can provide a fancier replacement.

The <URI> syntax can force URIs to render more literally.

This stuff isn't documented in the Remarkup documentation yet, but that will happen soon after some followup changes (see https://secure.phabricator.com/T13291).