Ooh just kidding. ⌃+Refresh fixed everything

@beng pointed out this resource for future use: http://cldr.unicode.org/

Can we please add the keyword subscribe or subscribers in this task title? I looked through 2 pages of subscribers search before filing a dup. I know now I was searching the wrong term, mention would have given it to me instead. But they are related.

I see your point.

I think the complexity of those rules exceeds their utility.

What are your thoughts on allowing valid HTML entities through to the
browser without further escaping (outside of code blocks)? There seems to
be no reason to have them in text, and they could allow escaping.

If you want to implement the rest of it with a ( trigger I can counter-diff you for a (( trigger.

the trigger was the main thing preventing me from implementing phurl

In the specific case of Phurl autocompletion, I'd be happy to review a change if someone wants to tackle it. The recent emoji autocompletion is probably a pretty good example to start from.

(It's still not possible to name a link X | Y, but I think we're no longer aware of any reasonable cases where this is important.)

I belive this was effectively resolved by changes connected to T7691. Specifically, if you had a page titled "A" at location "x", you previously needed to type [[ x | A ]] to get it to render the right link text. If you omitted the ... | A ... part, the link would just be named x.

In T5301#210596, @DemiMarie wrote:

What about triple backticks in code blocks? Code blocks can contain
anything, so I consider not being able to put three consecutive backticks
in them a bug.

Commentary on this is welcome, even just to say no it won't fly.

I think this is the same as T11543 but I'm going to merge that here since this one is a little cleaner. My current thinking:

You're correct, using brackets makes the regex work, thanks.

For starters, this regex fails to work

In T5301#149071, @epriestley wrote:

T5397 is another copy of the pipes-in-tables issue.

You can use remarkup.ignored-object-names to prevent S3 from being marked up: S1 S2 S3 S4

That said, if it's open, we do plan to address it eventually.

It sounds counter-intuitive, be the upstream prefers not to spend time on theoretical issues. Basically we have thousands of open tasks, and we complete them based on overall impact. Something hypothetically an issue isn't going to receive much attention.

What about triple backticks in code blocks? Code blocks can contain
anything, so I consider not being able to put three consecutive backticks
in them a bug.

Also I very probably meant "inline comment" and not "inline diff"

Oh, I missed "inline". That reproduces for me. I'll file a separate issue.

I do not have persistent chat open.

Do you have persistent chat open?

I came across a small bug with the "auto-suggest" feature. In differential I was writing an inline diff, and ended with :/ to show my face in plain ascii, and hit ⌘+⏎ immediately after to complete my inline diff. After typing :/ the auto-complete popped up and when I saved the draft with ⌘+⏎ it forever immortalized the auto-complete popup on screen with no seeming way to get rid of it (refreshing probably fixes~). I can reproduce on this install.

T6143, while closed, seems to be a real-world use case to me.

All changes in Phabricator need to be driven by strong, real-world use-cases.

@epriestley I hope to fix this in a very general way, which will also solve many of the other tickets related to Remarkup (T6276, T5951, T5427).

I'd like to see real use cases for this before pursuing it. In the use cases above:

I'll take this and T6002. Where in Phabricator's source code can I find the relevant PHP code? Edit: Found it in libphutil.

In T12139#208563, @chad wrote:

If you're on linux, I think emojione extension likely only choice. What OS/Browser?

hmm everything seems in order

Click here for 🐱

He's so little. :)

These are still so painful on non-Safari

Poor 🐈.

yup it works

💯

I rolled the server for the bug testers.

🐱

🐱

🐱

🐱

🐱

🐱

🐈

🐈

🐈

🐈

🐈

🐈

I guess I don't even have a glyph for :lion_face: anyway.

I've already started the 2 minute arc diff process

Also while you're in there maybe replace _ with (space) in the strings? I can't find :lion_face: by typing :fac... right now, but I think if you swap the underscores for spaces it will work. Then :cat should be able to find crying_cat_face and stuff, too.

not memorizing emoji collation order in 2017 pfft

FINE IT IS MY FAULT

The list is sorted by emoji. 🐈 is "alphabetically" earlier than 🐱 in the list of emoji.

cats are naturally dubious so i'm not surprised

I can't figure out the sort thing, don't think it's an emoji issue.

sort by awesome, descending

Cat2 is twice as good as Cat

Typing :cat will list the cat2 emoji before cat
🐱

Found the Chrome issue / Mac: https://bugs.chromium.org/p/chromium/issues/detail?id=551420

@johnny-bit I had good luck using https://chrome.google.com/webstore/detail/chromoji-emojis-for-googl/negakbijaemdgbhklopmghphgaeadmpo on Ubuntu/Chrome.

If you're on linux, I think emojione extension likely only choice. What OS/Browser?

Oh, woe is me, for there are no colours in my emoji. One thing to notice though - where can I find that beautiful emoji example in ui examples? Would be cool place to check for emoji support on different browsers/platforms :)

wow! the beautiful colors!

@avivey let me know how this looks now

https://www.tjvantoll.com/2016/06/15/emoji-on-windows/

Well, not non-existent, just black and white line art.

Yeah emoji on Windows is non-existent still. At least, on Windows 10 Chrome / Firefox / Edge it's just what @avivey posted above.

Crazy

In T12139#208257, @epriestley wrote:

Pros

• Users on old versions of Windows or who compiled their own Gentoo don't have occasional missing/fallback emoji.
• Users see the same picture of a smiling cat instead of different pictures of smiling cats.

If I can get most places to appear like Safari shows them, this will probably be good for a v1. The reason I like EmojiOne is mostly aesthetic, they are less busy visually (flatter) and are easier to determine what they are individually. I can also control the size. Let me futz with our emoji remarkup rule and see if I can normalize the display better. Though, not sure that's really possible still given Google search results.

Chrome/Firefox seems to be shrinking them smaller. I think we can maybe cheat that with font-size and the emoji remarkup rule...

This is what I see on my Macbook in Safari:

oh man, at least in Safari they look way better.

I believe Firefox is adopting EmojiOne. If I could CSS style the emojis, it would help. I find them small and hard to identify in text. Basic ones like ❤️ are easy, but all the different emotions are somewhat harder. 😁 vis. 😂 really are hard for me to visually focus on (and on my laptop, which is smaller dpi, is even harder).

Emoji look terrible on nearly every platform / browser

phurl autocomplete might be nice too

All I've learned is: