There seems to be no other way than setting the timeout via ini_set().

Confirmed to work, thanks!

We are at 0c37f8db4b82 right now, which includes that commit as well.

You can check if the optimizelegibility is indeed the cause by disabling it via the web inspector. It is the issue for me, at least.

This is due to a bug in Chrome (most likely) which makes text-rendering: optimizeLegibility behave very strangely.

Qafoolabs mentions a "proposed timing API" in a pull request. I can't seem to find anything about anything having been proposed, but it might be worthwhile to keep that in mind.

I do see that gc_runs and collected are available (via GC_G(...)) unconditionally? It's not much, but it's more than is available now.

Pretty sure you've been across the same path as I was, but I want to share my findings just in case someone can find a way to use it:

Ah, no - I was wrong. It's because of the ---- line from the quoted section (- indicates a list item too). Observe:

> --
> Hello
> 1. One
> 2. Two

Hello

1. One
2. Two

I'm guessing that this is a side-effect from rPHU0db4b149c4e0. Strange though. :/

Specific link to the source, for future reference: http://git.php.net/?p=php-src.git;a=blob;f=ext/standard/exec.c;h=6106fe2c86bb687979e36e2070a99283cc0a0878;hb=HEAD#l365

See T6348 for details on why this happens. escapeshellarg under Windows removed % signs.

I believe the check for TERM should be fine. However, for reference, the Symfony framework uses a slightly simpler check - and will probably behave saner in most of these cases to do go wrong.

Basically, double quotes disappear when passed through escapeshellarg. The command for history basically becomes:

The history support is useful. I might be able to find out what's happening.

Oh, I notice I forgot to mention it was about a task :/ My apologies for
that.

I've now seen the same issue over several commits, leading me to believe
that it's not a fluke.

It's not very rare, it's just that MySQL (by default) will allow non-standard behavior for the GROUP BY clause.

A related case with try..catch..finally (see D10337) works in the same way as @epriestley described. However, in that case it's easy to fix. This may be less trivial, but still worth fixing.

Having the favicon also change would be very cool. I usually have my phabricator tab pinned, which means that I don't see the title.

• However, I'm not sure if there's an agreed-upon or standard way to canonicalize combining marks.

@epriestley: could you take a look at the comment above? I'd push out a diff but for some reason the values of the tokens change when I rebuild xhpast.

Verified to work, thanks!

Catches are optional when you have a while. This small diff fixes that:

Well, I seem to remember it wrong; when I close the new-commit file in Sublime Text now, arc continues as it should.

If I recall correctly, I had the same kind-of issue. The file opened in an already opened instance, and arc would only continue if I closed the entire instance. Adding -n helped in that only the new instance had to be closed.

Closed by commit rARC3201239e85ea.

Closed by commit rPHU3fe4daa19d2c.

The fix @epriestley mentioned, indeed.

I can confirm that your fix makes the problem go away at my Windows pc. Nice :)

The hg grep search doesn't seem to be too slow. Also, by replacing it with a hg locate command you lose the line numbers which seems to be a shame.