Thank you !

• D20208 adds an authorPHIDs constraint.
• D20209 provides details for transactions which add or remove projects. See above for format and rationale, or just query something and see what pops out.
• D20211 makes the documentation less bare-bones.

A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.

I ran a query against a subset of instances to determine if "Mute Notifications" sees any usage whatsover (see T13068):

FWIW I appreciate and use the mute feature (though only occasionally)

Currently, project tag changes and subscriber changes don't expose data in "transaction.search" because there's no "obviously correct" way to represent these changes in a future-proof way.

To my surprise, it also seems the method does not output any project tag changes that happened on a task?

Thanks for the quick reply!
Haven't played with webhooks yet so I did not know/realize it's transaction PHIDs only - "PHID" sounded generic enough that I incorrectly expected any kinds of PHIDs to be accepted as input. So this task is somewhere between either "clarify documentation that only transaction PHIDs are supported" or a "support other PHIDs" low-prio enhancement request.

We no longer offer support for this kind of problem (that technically has reproduction steps, but is sufficiently involved to reproduce that no one has time to follow them, e.g. build a new server from scratch with assorted specific software versions).

The phids constraints matches transactions with specific PHIDs (PHID-XACT-...). Usually, you'll have a list of transaction PHIDs when you're responding to a webhook callback, so the phids constraint is most useful for webhooks.

This change broke the search dialog on tags typeaheads...

Probably a good idea, but not worth keeping a task around for.

This is probably a natural feature if we iterate here, but not worth keeping a task around for.

We have no customer interest in this and no current plans to pursue it.

I'm looking at these storage/backend changes:

Presuming resolved by D19748 since we don't have an actual reproduction case.

D20196 removes this code.

I think it had some white-space removed from its end.

After D20194, expansion of tabs now uses the correct rule (expand tabs to the next tabstop) instead of the old rule (hard-coded replacement with a fixed number of spaces).

There are probably still a few remaining kinks to work out here, but I believe this is substantially resolved:

• The "<<" and ">>" indicators are rendering in places where indentation has changed but the entire line is also different. This is not intended.
• The ScopeEngine can raise an exception on diffs with partial context. We should probably just skip this feature if we're missing context.
• The indent depth indicators are probably generally too bright / high-vis.
• There's no color blind scheme for the indicators.
• The indentation indicators in one-up mode aren't great (?)

I'd propose for simplicity that the focus switch from largefiles to lfs support for Mercurial repositories. lfs has been added to Phabricator for Git already T7789 and it seems that there'd be less work involved to piggyback on that.

I'm probably not going to fix this since it's pretty minor and moderately complicated to fix, but this interaction is not ideal:

In Firefox, selecting a range which crosses an inline comment currently drops the line after the comment. Here, return arra does not copy:

Note that T6791 has an example of a change where removing the whitespace options is going to cause a behavioral regression. Here's an example:

This report is generally unclear / hard to reproduce / unusual so I'm not sure how to move forward. It's likely mooted by D20181.

See PHI701. This behavior is not ideal:

I'm going to start here, and implement this proposed rule, which I think is the simpler and more intuitive of the proposals:

It sounds like real-time updates will more-or-less moot this.

(See T13251 for followup.)