- User Since
- Mar 18 2015, 3:47 AM (380 w, 5 d)
Aug 10 2016
May 6 2016
Apr 27 2016
I guess I was hoping for a timeline. Or an explanation of why it's hard
and not done yet. That page seems to me to say "we'll get to it when we
feel like it" (ok not a totally fair paraphrase, but it's one way to read
it). Waiting a year for a minor feature that would drastically improve one
of my workflows just makes it feel like you guys aren't being very
responsive to feedback about how the UI could be made better. And I have
plenty of other complaints about the ui - just haven't bothered filing most
that was not a particularly helpful response
Any updates here? This task has been open for over a year now and it's something I wish for approximately weekly.
Mar 9 2016
Thanks for all the examples - definitely makes sense that these behaviors are a bit of a different class than ones that actually examine file content.
I suppose the rules I am writing are fairly lint-like; part of this
reflects the sorry state of our lint infrastructure, though it is probably
a bit more flexible than herald. Having said that, sometimes I do want to
have rules that subscribe me to various diffs, before I figure out how to
automate my own advice; is there a way to add subscribers via lint rules?
Mar 8 2016
Ok so I just took it for a spin while editing herald rules. While it sort of solves my problems, it's very much a poor-man's solution - it's completely out of the way from the "create a herald rule" workflow - ideally, on the page where I'm creating or editing a herald rule, the test console should be right there so I can try out my new rule without necessarily having to save it; also it would filter to just trying that rule instead of trying all the rules, which would cut down on visual noise. This sort of change would make it much easier for the non-power user to create working herald rules.
Feb 23 2016
Derp. I'll check it out.
what test console?
Jan 5 2016
Mmm I didn't know that existed - will be super useful. Sorry for the bogus
Dec 18 2015
thx for deduping
er better example: T1023 v. https://secure.phabricator.com/T1023. Ideally both would be handled the same way.
Dec 4 2015
$ time git branch --contains 1eb050dff95372999c17b06d6c4caa63ce3f1659 * langpack_as_js_module
Here's the first part of a trace of an arc diff for me (includes most of
the pre-commit-message work):
this repros reliably for me - 100% of the time.
Sep 10 2015
@jhurwitz do you remember a diff that we saw this on?
Aug 19 2015
Aug 3 2015
+1 to this.
Mar 31 2015
Mar 19 2015
+1000 to improving serverside lint support. I have no problem with "can't
auto-change code" as the few uses of that we have have drawn some
Mar 18 2015
that would be nice (maybe even ideal) if lint was actually a reliable thing
there are plenty of cases where we do want a security review instead of
just lint warnings - it's definitely not as simple as converting everything
to lint rules. And part of the problem is that lint isn't expressive
enough - and in some cases can't possibly be.
So I guess I should explain more about our use case.