Oh, I like that.

sadderp

◀ Merged tasks: T4870.

Let me just note that Feed strikes through the entire label. No strong opinion either way.

Yeah, when we render links via "handles" we strike the whole thing. I find these fairly difficult to read and and that's part of what's motivating the "strike only the object name" approach, although you're right that things are hard-to-read and inconsistent right now, while we could easily make them merely hard to read.

(Specifically, I would want to strike only the Txxx part in the feed cases too, so the strikethrough was consistent -- and hopefully readable -- everywhere. This is not very difficult, it just requires a bit of legwork and hasn't come up all that often.)

I agree it is not an urgent problem, still a nice to have.

For what is worth, I noticed this problem when trying to create a smart casual checklist in the description of a task, see http://fab.wmflabs.org/T190

Yes, you can say "mark the task as a dependent", but casual checklists aim to be just that, casual.

See also T3945 (implementing checkbox lists) and T405 (syntax to embed query results in a comment or description).

That's an unfortunate limitation of an otherwise really neat feature which kind of prevents using most effectively especially for lists of tasks (you need to mouse hover over the task reference to know its status) .

If striking only Txxx is too complicated, is there anything simpler that could be done as a temporary stop-gap? Like changing the font weight, style, background color, etc...

Personally I'd vote for striking the entire text: sure it's not perfectly readable but it's not like it's a new convention. Most text editors allow striking text for a reason: let the writer still leave the information around and in some readable form and people deal with it fine. You might however want to use a regular font weight instead of bold as that most likely would make the text more legible.

I'm not sure if you have a technical background or not, but I'll accept a patch if you want to make it strike the entire thing for the moment. I think striking just the monogram is preferable in the long run, but that's a bit more involved. Striking the entire thing would be a reasonable stopgap.

You can implement it in PhabricatorRemarkupRuleObject, in the renderObjectEmbed() method. Copy the logic to build the closed attribute from the renderObjectRef() method in the same class. I think that's sufficient.

I have a different solution. It might suck, but I'll send you a diff.

@swisspol BTW, I was an Everpix fan (and customer).

Thanks for offering to accept a patch and the pointers. I have a programming background and have contributing to various open source projects. The only reason I haven't proposed a patch upfront is that I'm not comfortable with this code base yet (and I haven't done any PHP coding in 10+ years which doesn't help). I will have a look and circle back.

@chad The Internet is a surprisingly small world :) Thanks much for having supported our product! I'm been spending more and more time with Phabricator recently and I'm really liking it more and more. It's certainly excellent to support engineering work. I just wished it had a few small extra features which would significantly improve its use for project management, road-mapping, etc...

BTW does the Phabricator team accept sponsorships for certain (well scoped and limited) enhancements?

We do some level of paid prioritization (we'll build something that makes sense in the upstream and which we might have built eventually for you, just sooner), but it currently is all one-offs and involves contracts and has significant overhead unless you want a fair amount of work done and/or have a bunch of contract templates sitting on your desk.

I'm not sure exactly what you're thinking about, but if it's just a handful of small things we don't have a good streamlined way to bounty/sponsor minor tasks right now.

I think we might in the future (we want to develop a couple of use cases for Phortune before using it for really charging money, and "premium tokens" or "task bounties" might be good, small transactions) -- but probably not for a while.

If you want to talk through things in more detail, feel free to shoot us a message in Conpherence or an email (epriestley@phacility.com).

A basic version is now at HEAD. Will keep this open for any issues.

Most impressive! This is the second time I've seen a hourly turnaround on a task in a few days, which I have never seen before on a large open source project. This reflects greatly on the dedication of the team to this fine product. Thanks so much!

Note that we have been using this feature for the past 10 days and it works great.

Test: T3510: Indicate a task/revision is closed in Remarkup