I'm think just going to put a "Save Current as Default" or similar at the bottom of the menu (and another one at the bottom of the filter menu) since I think those are sufficient here. Two possible concerns:

No problem, thanks for the detailed request. Let me know if I missed anything or you run into trouble.

Awesome. Thank you!

Oh, the weird/nonstandard stuff in my regexp, if you or some future reader hasn't seen it before:

After D15254, you should be able to use either "does not contain" or "does not match regexp" against text or list-of-text fields, including "Affected files".

Yeah, I don't think this is possible when matching an expression against a list of possibilities.

Sounds good -- that change looks reasonable and safe to me, and I'd expect it to work well until we get T7715 done.

Yes, completely agree that a generalized solution is best.

I'm going to merge this into T7715, which has some more discussion.

This depends mostly on T7715, and maybe T5873.

Maybe I'm alone in this case, but I like to arc patch D1234 the diff and then locally browse the files using my editor. I still have to go to the web UI to post comments, but I have in my mind a script that would allow me to select my open reviews, patch it locally, and then open the webui.

What is the use case since in order to perform any meaningful actions you have to go to the web UI?

We run origin/stable from rP (times three), except for reverting rP71bda66870d8ef832f4d048b11282f9ae0086f05 to prevent this issue from occuring.

(I'm not sure if the daemon is fast like "100 milliseconds" or fast like "5 seconds").

Also, if whatever you're running is extremely fast already (i.e., effectively caching results for you), you can just have both lint and unit run it and ignore the parts of the output they don't care about.

If you are are extremely adventurous, you could make a checkstyle-daemon, some start-daemon-or-use-if-already-running command (Maybe gradle in daemon mode can already do something like that?), and a custom ArcanistLinter that talks to it. That's a significant amount of work, but does not clash with arc's current world view.

There may be a better pathway forward for issuing the actual prompt after T10329, depending on how that pans out.

There's more discussion of this in T9223, which effectively superseded this. I've filed T10329 to describe the pathway forward.

Thanks for the thought. There's 2 issues with this solution. The first is, as you mention, that the result doesn't get uploaded to the server. The 2nd is that there's no enforcement: developers can still run "arc diff" to create a diff that has lint errors and nobody would know. What I'm looking for is a way to efficiently run checkstyle for each new diff. Ideally the results of the checkstyle run would be sent to the server but I'd settle for a solution that simply gives the dev and error message and bails.

I have a vague idea about adding some sort of "addIconAttribute" method eventually, so that we could in theory pass any Task metadata over like how many diffs are attached, if its blocked, pholio mocks, etc. Sort of what we originally planned footIcons for. I also need to just remove the footIcons code.

Alright, let me take a stab at that..

Yeah it should just be a tag set via addAttribute. I only ask that it renders as the first attribute.

You can copy/paste it into src/extensions/ to generate a new maniphest.gettasktransactionswithids endpoint, but whateves, sure, send a diff.

Great, and I agree it's a bit weird -- so can I get that patch to include the transactionID so I can hack it together?

Yeah, I think that's reasonable. The actual logic is mostly trivial (look forward for transactions with the same author within 5 minutes) but then has a long tail of complex ordering/hiding/grouping/folding behaviors. If you just do something like:

Or is the idea that someone pastes T123#456 into chat, and you want to not only expand the T123 part, but also provide context about the #456 part? That is, this bot is reacting to human messages, not to events from Phabricator?

Sorry, I mean: where is the bot getting the link from?

From this page, on any comment (or transaction listing, like "jshirley created this task"), the timestamp on the right hand column has the link: https://secure.phabricator.com/T10327#158499 (for your last comment).

Where are you getting the link from?

The problem we're facing now is that when we do have a link generated by Maniphest, we cannot use the API to reconcile what that is.

I'm just going to merge this into T5873 (which discusses building a modern transaction read API, among other things).