What's the format for setting? I tried ["http","https","mailto","hyper"] but it didn't work and actually breaks all links.

haha no idea, this arose from a product discussion about how project tags will render when there are 16 levels.

wait how do I get @epriestley points

are you kidding me, I spent all my @epriestley points on this as is.

Is there any intention to add support for auto-complete when typing like "T1234" or "D1234"? That would help immensely with instances that have a large number of tasks or diffs. I know there's been a few times on this instance where I've wanted to refer to diffs in task comments, but I can't remember the number perfectly so I have to open a Maniphest search to try and guess what number it was. Having it in the typeahead with the task / revision title would mean I don't need to spend time doing that.

From D15029:

ǝɯ ɹoɟ sʞɹoʍ ʎǝlʇsǝᴉɹdǝ@

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

Is it expected that this doesn't work on mobile?

In the case of 1 match, we now hide if there's one match and it's exactly what you typed.

I think that's what I intended to describe - hadn't considered if there was a single match but wasn't exactly what was typed. Thanks.

In T10163#154334, @cspeckmim wrote:

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

Okay, all that stuff is live now too.

Yeah I'm finding implementation mixed at various sites.

I didn't do that because I don't think a space is universal -- I've seen ":" and ",", particularly.

I sort of expect it to also place a space for me after selecting the correct object.

That word stuff still has some weird/buggy results, I'll see if I can improve the behavior.

Alright, all that stuff is hopefully fixed/improved now:

T10150 is probably describing the same issue, but this report is much more detailed.

Just a heads up. I hope those duplication instructions are sufficient - this is a very weird one.

After extensive testing, with help from @avivey on IRC, we discovered this actually wasn't caused by a deleted user - that had cleaned up just fine. It appears to be a new Projects related bug. See T10168: Provide a clearer pathway forward for old projects with invalid hashtags.

Phurl is a prototype.

That would change your case of @epriestley xvnoinoandsonaf having autosuggest stick around though.

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

Maybe we can do this:

That'll break @evan danger priestley and #differential mobile unbeta. I don't really see a clean way to resolve that based on spaces-typed, since both human and project names may contain an arbitrary number of internal words. We could put some artificial cutoff (three words? maybe four or five for projects?) but I don't immediately see a way to write a rule that always does what you users want.

@epriestley - Sorry, was just noting the different cases while testing -- most of the 'prefix' ones I gather made sense for the exact reasons you described. The only change I would prefer is if space also dismissed the typeahead - if completely ignoring typeahead it feels like it's in the way.

Another errata is when the typeahead appears off the page and you have to scroll. In Conpherence it, uh, scrolls the main header off the page.

Let's try the less-annoying way and see if it actually causes problems, it's definitely the behavior I would prefer personally.

But maybe it will feel weird, since I don't think most inline typeaheads work like that. On github as soon as I hit @, it pops a typeahead with you at the top (presumably, you're the commit author?)

From a design POV I see typeaheads as "Search", not "Browse". They should have some idea when they did @ or # what they were looking to link to.

Do you think that's preferable? I think it's probably much better for experienced users, but I'm a little worried some users will type a #, sit there, then tell us it's broken if we do that.

In T10163#154322, @epriestley wrote:

We could also decline to pop the typeahead until the user types the first (valid) character. Currently we pop it on @ or # immediately to show the user that it's available and aid discovery, but it might be better to wait until they type one valid character before we pop it, so there wouldn't be a flash on cases of ##, etc.

We could also decline to pop the typeahead until the user types the first (valid) character. Currently we pop it on @ or # immediately to show the user that it's available and aid discovery, but it might be better to wait until they type one valid character before we pop it, so there wouldn't be a flash on cases of ##, etc.

Typeahead starts when preceded by ., -, (, |, #, @

Some nuances I've tested:

1. Typeahead starts when preceded by ., -, (, |, #, @
2. Typeahead does not start when preceded by most other characters including ', ", ?, ,, /, {, }, [, ], ), :, >, < +, _, ;, !

Not sure if rP2d495e97014d made it on this install, but typing two # in a row still tries to autocomplete. Should it be dismissed if prior text is # as well (for headings/sections)?

The second biggest source of storage pressure appears to be test instances that, e.g., imported the Linux Kernel and were then suspended. I've filed T10166 to follow up.

This is now available in the cluster, but the storage engine currently never selects it for new writes because MySQL is still configured to allow 8MB chunks. I'm going to selectively migrate some data, but probably not turn default writes on for a week or so.

Pygments added support a couple of months ago but hasn't released a version with support yet. See:

Do you have pygments enabled?

This is very nice :), but I got three questions left:

We're actively working on it.

I think you can use ./bin/repository reparse to re-read old commits.

I think this design is really great! Is this full live or just a part?

I think Projects (Home) is in a reasonable place, will update milestones and subproject mocks.

So Phabricator just won't check the commits for any changes at all then. For example, if the names of commit authors were changed or commit messages were edited, these changes will probably not be picked up? It makes sense that Phabricator doesn't check for these types of changes, although it might be nice to have a way to prompt it to. That is probably of limited use though, so it might not be worth the time to implement it, unless doing so would be simple.

Right; If you svnadmin the same commits over, the svn cat commands would work correctly, and everything should be ok.

Thanks for the reply.