Parser diff: https://secure.phabricator.com/differential/diff/28809/

We already have major parts of this map in getPygmentsLexerNameFromLanguageName().

• You can use syntax.filemap to configure how files are highlighted.
• The attached diff adds support for VHDL by default.

You must not have previously interacted with the object.

See additional discussion in T6516. This is not fixed until D11964. The root issue is a discrepancy between the web and Conduit workflows which I missed until it did bad things.

Those two patches should generally prevent problems here. With those applied, the behavior would have been:

Sorry, we don't build features which are only useful for application development right now because we don't support third-party application development.

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

Some related discussion in T6887.

cleared php cache

Specifically, the repro is:

Cool, that makes sense. I think the way forward here is:

One general note here is that we (the upstream) are unsure how valuable this is as a feature. In particular, although we use Differential heavily, it isn't a feature which any of us have ever felt much of a desire for, which is part of the reason why it hasn't been built yet. (I also did not feel much need for this feature at Facebook.) Speaking broadly, we haven't experienced very much difficulty tracking inlines across updates.

To clarify, you're checking files which contain ANSI color sequences into a repository, and then viewing them in the repository browser in Diffusion?

At least at one point in time, registering anything on beforeunload would disable the "bfcache":

Ah, that's helpful. I think we explicitly set the response code to 500, so the 200 is the surprising/unexpected behavior. That should be enough for me to figure out what's going on here, thanks!

The other reason not to hide the revision as a whole is to avoid dead-ending the revision: it's desirable for us to be able to discuss the change and the need for the CLA with the author.

(Or @joshuaspence, I suppose.)

@btrahan, @mpalmer isn't comfortable signing the CLA, and I've looked at D11949. In the interest of propriety, can you fix this without looking at D11949 when you have a chance?

If it's not too hard, it would likely be helpful.

I think that's the one.

I had similar feedback on the original diff I think -- I think this one looks a lot better, but we did lose the sense that the title is visually tied to the code block and is a label for the block content.

One minor note, but we've also seen feedback in the other direction, where users want to drop the URL.

I think this warning is incorrect (i.e., the statement is not actually unsafe, because the autoincrement primary key can never collide).

Hrrm, I'm having a hard time reproducing this and don't immediately see anything in the code which could cause us to drop the dialog.

I believe this was fixed by rP8599145 and rPf6915a7. Specifically:

I merged T7037 and T6908 here because they both deal (approximately) with templating .arclint files, and we're definitely not doing the magic approaches in T6908 where some linters get to ignore global excludes.

Assuming things don't change up too much, maybe something like:

Technically speaking:

We can't reproduce this.

This is more possible after the centralization of the overseer and the introduction of phd reload and the SIGHUP handling. Specifically, we could do this:

Doesn't reproduce at HEAD.

This was resolved by D11706.