I think I can fix that. The current assumption is that the wrap is the result of multiple words:

Feel free to say no... but if you start an @ at the edge of the remarkup box, the text will move to the newline but the box won't.

This bare "v3" in the is still a little weird:

heh

yeah whatever

》 looks okayish but has weird spacing:

❱ he he he

HOLD ON WE HAVE HUNDREDS OF BRACKETS TO LOOK THROUGH STILL

⟩ doesn't have the bad spacing but does have an odd baseline:

Using the Milestone Icon should identify it clearly as a Milestone.

We could just do parens. [ Stonework (Iteration I) ]

〉 has the bad spacing and also a weird baseline:

〉 looks a lot better, except that it has some kind of bizarre super-wide right margin on the actual glyph, at least on my system/font:

Well, it doesn't look awesome either:

› probably doesn't look that bad.

I think this is actually a little tricky. In the UI, I'd like to see us auto pre-pend the Project Name with the Milestone, then represent that as the object everywhere (search, tags, typeahead, page title). But that likely means using some UTF-8 delimiter over a pretty pretty icon.

it's beautiful

This has been live for a few weeks without any issues, and I generally expect it to have nearly zero impact on reasonable workflows, so I'm going to assume the best and close this out.

The WMF-specific aspects of this are covered on the WMF install in https://phabricator.wikimedia.org/T125104, and that looks like it has a promising path forward that doesn't rely on this event. We haven't seen other outstanding unresolved issues and this has been in the wild for about two months now, so I'm going to assume the best and close it out.

This has been live for a couple weeks without making any waves and these changes were all pretty straightforward so I'm going to assume we're in good shape, but yell if anyone bumps into issues.

+1 for this from me, internally for us getting a new gmail account (provides IMAP/POP access) is relatively easy, but getting necessary MX records/mail routing/etc... for a local copy of sendmail is significantly more difficult.

Looks great, thanks for the quick turn-around!

I'd recommend reading up on feed-hooks and Doorkeeper as well (see T5462 for an overview).

For example a root problem might be:

srry :(

I believe I described the root problem already, but just to be extra super clear:

I believe I described the root problem already, but just to be extra super clear:

Broadly, these emails can certainly be improved (see T6600; see also some outstanding known issues like T6576, T7031, T7030, although I think those are non-impactful). The "with context" inlines and inline diffs are particularly bad, but these features are off by default and I believe they generally run counter to the goals of the mail and do not expect most installs to enable them (they exist for a variety of historical reasons, and because some installs have special needs), so they've been fairly far down the priority list.

Couple of quick basics for easily addressable / surface issues:

Same thing, just one repo out of many (biggest one, only 400 MB, though).
Reverting the {71bda66870d8ef832f4d048b11282f9ae0086f05} helps.

I got the reason for this error now:
I don't know why, but in this case PHD was not the owner, (root was it) of the repo, so you can make him an owner, or change chmod, so that phd is able to write.

Adding if (matches[2]) before content[matches[1]] = matches[2] in aphlict_server.js (to allow the default to kick in for otherwise empty values on the cli) resolves the problem for me.

I'm experiencing exactly same problem while accessing one of my repos via HTTP.

Can I get clarification on philosophical opposition to this? Is it leaking abstraction of the "icon" interface to the end user?

Hows this: