Event listeners do, generally speaking, respect middle and right clicks. This isn't a case of event listeners just being too ambitious.

(Our largest human-facing source file is PhabricatorApplicationTransactionEditor.php and weighs in at a paltry 78KB.)

In an ideal world, would the regularly edited human-facing 537KB file still be a single 537KB file (rather than, e.g., a collection of smaller files, or a code-generated file, or some other kind of resource)?

I think it's reasonable for #x y to mean "documents matching query y in project #x", but I don't think x y should mean this on its own.

T5307 discusses finding some way to fit "Export to spreadsheet.." -- and various other options -- into the UI in the general case.

We're vanishingly unlikely to redesign search results in the general case, and this request isn't compatible with responsive "object" list search results.

Sorry, we don't accept feature requests for prototype applications like Phame. See:

Diffusion, Pholio, Differential and Maniphest now support generic, full-power modern project filtering. I think that covers all the applications we're aware of significant interest in for this feature. It will come to other applications as they get modernized and updated over time.

These aren't universally deployed yet, but are substantially complete and are deployed in multiple applications. See T7858 for some followups. These will deploy everywhere over time, although they may not come to some lesser-used applications for a bit.

to meemees is two many meemees

As much as I hate features, this is relatively easy to build from a JS/eng point of view, fixes T7132 more easily than giving it a real target, and might let us just not pursue T7843.

In Git, we get fairly good control over error messages, although less so in Subversion/Mercurial. We emit this particular message ourselves:

Does your remote also have an enormous number of branches?

This is possibly tricky because the user can enter some unparsable time format in their preferences, but we can assume that users mostly enter reasonable time formats until we have evidence to the contrary.

When you enter "23:00", what does it do? What did you expect it to do?

Couple things offhand:

Here's an updated profile

And, if your desired value is larger, would making it easier to activate highlighting be a reasonable alternative approach? Currently you can highlight with:

If it was configurable, what value would you set it to?

I think php_compat_info.json is the biggest easy win.

Those regexps can also be memoized.

This can probably build a single huge regexp and drop time to nearly zero:

The profile likely overstates the cost of functions like idx() and mpull(), but occasionally they're worth reducing to isset() or similar if they're really getting hit tens of thousands of times.

I don't see any huuuuge wins, but:

Let me know if that fixes it when you have a chance? Still not totally sure I've nailed this down but it shouldn't be possible for it to recurse now.

I think workboard permissions are a little iffy until T6502.

D12511 is a possible fix, although I was only sort of able to reproduce something sort-of similar to the issue you hit.

Doesn't repro for me at HEAD and I'm pretty sure I remember fixing this. I presume you can't reproduce on this install?

I suspect I'm just not hitting the right edge case, but this stuff did churn a lot recently so I just wanted to double check that it's definitely not me testing different code.

Just to confirm, you're ahead of rP8efdc4aa? I'll keep digging, but I can't immediately reproduce this at HEAD.

Ah, okay. Yeah, looks similar. I'll take a look, thanks!

Set debug.time-limit to a value like 15 and hit it again? That should give you a trace.

You can change the chunk size constant to 1 to see the effect -- I expect it will lower memory usage (but not provide a huge reduction in peak, which I think is approximately a function of the largest file in the repository at these chunk sizes) but be much slower overall.

I feel that the memory usage could be further improved if we linted by path, because we would only need to store a single XHPAST tree in memory. This means that we wouldn't need chunking.

I've marked D12509 as fixing this, although it really just obsoletes it. Specifically: it removes this behavior (we no longer default to the first query) and makes scope selection explicit instead (if you want to default to a specific query, just select it from the dropdown).

I'm going to merge this into T4103, although D12509 partially obsoletes it. Hopefully, the explicit control surfaced in D12509 resolves the confusion here on its own.

he he he

I think we should probably just document our way out of that; it's admittedly unclear that we're dumping the input into a font: attribute and we don't provide any examples.

Ah, I'll fix the double-escaping.

I also can't reproduce this. An example string which works for me is:

After T7849 (in review), there's a sort of kludgey workaround for this that has some caveats but should get you 90% of the way there:

I think the root cause for this is a bit complicated to explain, but basically we try to match this as a move:

We don't require MySQL 5.5. The install guide says this:

Estimate = review/test that ^^^

It looks like you already have a conflicting package installed already ("MySQL-server-5.6.13-1.el6.x86_64").

T7884 has the similar case of changing a real file to a symlink.

Yeah, but I'd have to take another look at the code to give you an estimate since I don't remember exactly how much stuff is standing in our way. I'm headed to bed pretty soon but can take a gander tomorrow morning.