{"action":"created","issue":{"url":"https://api.github.com/repos/doxygen/doxygen/issues/6691","repository_url":"https://api.github.com/repos/doxygen/doxygen","labels_url":"https://api.github.com/repos/doxygen/doxygen/issues/6691/labels{/name}","comments_url":"https://api.github.com/repos/doxygen/doxygen/issues/6691/comments","events_url":"https://api.github.com/repos/doxygen/doxygen/issues/6691/events","html_url":"https://github.com/doxygen/doxygen/issues/6691","id":392426311,"node_id":"MDU6SXNzdWUzOTI0MjYzMTE=","number":6691,"title":"Multiple issues with emoji matching","user":{"login":"mosra","id":344828,"node_id":"MDQ6VXNlcjM0NDgyOA==","avatar_url":"https://avatars3.githubusercontent.com/u/344828?v=4","gravatar_id":"","url":"https://api.github.com/users/mosra","html_url":"https://github.com/mosra","followers_url":"https://api.github.com/users/mosra/followers","following_url":"https://api.github.com/users/mosra/following{/other_user}","gists_url":"https://api.github.com/users/mosra/gists{/gist_id}","starred_url":"https://api.github.com/users/mosra/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mosra/subscriptions","organizations_url":"https://api.github.com/users/mosra/orgs","repos_url":"https://api.github.com/users/mosra/repos","events_url":"https://api.github.com/users/mosra/events{/privacy}","received_events_url":"https://api.github.com/users/mosra/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-12-19T03:29:09Z","updated_at":"2018-12-21T09:47:29Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Similar to #6612, related to emoji support (#6517) added in #6534 by @albert-github. I have multiple false positives on emoji being detected in [Magnum](https://magnum.graphics) documentation. One example is this:\r\n\r\n```cpp\r\n\r\n/**\r\n…\r\n\r\nAspect ratio    | CSS class (landscape/portrait)\r\n--------------- | ------------------------------\r\n1:1             | `.aspect-1-1` \r\n4:3 (1.33:1)    | `.aspect-4-3` (default) / `.aspect-3-4`\r\n3:2 (1.5:1)     | `.aspect-3-2` / `.aspect-2-3`\r\n16:9 (1.78:1)   | `.aspect-16-9` / `.aspect-9-16`\r\n2:1             | `.aspect-2-1` / `.aspect-1-2`\r\n\r\n…\r\n*/\r\n```\r\n\r\nproducing absolutely unwanted and totally bogus warnings such as:\r\n\r\n```\r\nplatforms-html5.dox:293: warning: Unsupported emoji ':3 (1.33:' found\r\nplatforms-html5.dox:297: warning: Unsupported emoji ':2 (1.5:' found\r\nplatforms-html5.dox:301: warning: Unsupported emoji ':9 (1.78:' found\r\n```\r\n\r\nAnother is in code snippets like\r\n\r\n```cpp\r\n/**\r\n… `Platform::*Application::viewportEvent(const Vector2i&)` …\r\n*/\r\n```\r\n\r\nwhere the asterisk is a wildcard for multiple types such as `Sdl2Application`, `GlfwApplication` etc., producing \r\n\r\n```\r\nchangelog.dox:661: warning: Unsupported emoji ':*Application:' found\r\n```\r\n\r\nSome suggestions about how to fix this:\r\n\r\n- match emoji names as `[a-zA-Z0-9_-]` and nothing else (I don't think I ever encountered any other characters)\r\n- don't accept a space in a emoji name (*seriously?!*)\r\n- don't *ever* look for emojis in code snippets and inline code (I doubt there's any use case for that, if really needed, people can always insert the matching unicode character directly)\r\n- have emojis **opt-in** via a config option, because adding `\\:` everywhere just because there's a new feature with dubious use is absolutely *not* acceptable"},"comment":{"url":"https://api.github.com/repos/doxygen/doxygen/issues/comments/449336126","html_url":"https://github.com/doxygen/doxygen/issues/6691#issuecomment-449336126","issue_url":"https://api.github.com/repos/doxygen/doxygen/issues/6691","id":449336126,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0OTMzNjEyNg==","user":{"login":"mosra","id":344828,"node_id":"MDQ6VXNlcjM0NDgyOA==","avatar_url":"https://avatars3.githubusercontent.com/u/344828?v=4","gravatar_id":"","url":"https://api.github.com/users/mosra","html_url":"https://github.com/mosra","followers_url":"https://api.github.com/users/mosra/followers","following_url":"https://api.github.com/users/mosra/following{/other_user}","gists_url":"https://api.github.com/users/mosra/gists{/gist_id}","starred_url":"https://api.github.com/users/mosra/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mosra/subscriptions","organizations_url":"https://api.github.com/users/mosra/orgs","repos_url":"https://api.github.com/users/mosra/repos","events_url":"https://api.github.com/users/mosra/events{/privacy}","received_events_url":"https://api.github.com/users/mosra/received_events","type":"User","site_admin":false},"created_at":"2018-12-21T09:47:29Z","updated_at":"2018-12-21T09:47:29Z","author_association":"CONTRIBUTOR","body":"Let's step back a bit:\r\n\r\n- Do you seriously think someone would hand-enter `:japanese \"congratulations\" button:` for an emoji name? Or any other \"unicode short emoji name\" containing spaces? I doubt that.\r\n- There's a reason why the list of short names introduced by GitHub and adopted by GitLab, Gitter, Slack and others has the name character set restricted to `[a-zA-Z0-9_+-]`. Because everything else has way too many false positives. Again, **especially spaces**.\r\n- What's more likely when I want to insert a random emoji to the text?\r\n    a. I search for it on google or use an emoji keyboard on my system and copy-paste the Unicode representation of it\r\n    b. I search for it on google and instead of copy-pasting the Unicode representation that's [directly on the results page](https://www.google.com/search?q=congratulations%20emoji) I spend extra time looking up the canonical \"unicode short emoji name\" so I can then copy the text, wrap it in `:` and then hope the parser catches it and parses correctly?\r\n\r\n> probably there is no use of emoji in code snippets etc. but it quite difficult to filter them out.\r\n\r\nSeriously? There's already code in place that doesn't convert HTML tags that are inside code snippets. So I guess similar logic could be reused for emoji as well. \r\n\r\nThere are also markup formats such as reStructuredText (used by [Breathe](https://breathe.readthedocs.io/en/latest/) to add arbitrary contents to Doxygen code blocks), which looks like this -- note that basically every occurence of its text role command would qualify as emoji -- and you *don't want* these to be converted to emojis:\r\n\r\n```rst\r\n…\r\n\r\n-   To maintain accessibility easier, makes it possible to enforce :rst:`:alt:`\r\n    text for every image and figure by setting :py:`M_IMAGES_REQUIRE_ALT_TEXT`\r\n    to :py:`True`.\r\n\r\nYou can add `additional CSS classes <{filename}/css/components.rst#images>`_ to\r\nimages or figures via the :rst:`:class:` or :rst:`:figclass:` options,\r\nrespectively. If you want the image or figure to be clickable, use the\r\n:rst:`:target:` option. The alt text can be specified using the :rst:`:alt:`\r\noption for both images and figures.\r\n\r\n…\r\n```\r\n\r\nNo matter the legacy-ness of the existing documentation, from now on after every modification I have to go through all my output and check it for presence of rogue emoji. Not to mention that in some contexts and use cases having emoji present in the output would be *absolutely unacceptable*. So what I propose is:\r\n\r\n- restrict the \"Markdown emoji\" to just what GitHub Flavored Markdown supports and *not more*, ideally under an *opt-in* config option so tools like Breathe continue to work properly\r\n- and, for inserting random other emoji, introduce a new Doxygen-specific command `@emoji`, that accepts the long-name. Or, *better*, introduce a new command `@unicode`, accepting (a sequence of) UTF-32 codepoints, so people can use it not only for emoji but also for much more useful things like adding `×`, `÷` and other characters that are not readily available on most keyboards."}}
{"actor":{"display_login":"mosra"}}