* bug#54970: 28.1; Some emoji no longer display @ 2022-04-16 13:07 Howard Melman 2022-04-16 14:18 ` Lars Ingebrigtsen 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-16 13:07 UTC (permalink / raw) To: 54970 (I normally use the macport but I was able to reproduce this on vanilla emacs 28.1 from emacsformacosx so please forgive if I get some details wrong.) Using emacs -Q on MacOS 11.6.5: Use C-x 8 RET and select FORK AND KINFE WITH PLATE I don't actually see the character on vanilla emacs but if I put point before it the cursor displays a bit wider if that makes sense. On the macport I see tofu. C-u C-x = with point just before the character shows: ================ position: 319 of 319 (100%), column: 0 character: 🍽 (displayed as 🍽) (codepoint 127869, #o371575, #x1f37d) charset: unicode (Unicode (ISO10646)) code point in charset: 0x1F37D script: symbol syntax: w which means: word category: .:Base to input: type "C-x 8 RET 1f37d" or "C-x 8 RET FORK AND KNIFE WITH PLATE" buffer code: #xF0 #x9F #x8D #xBD file code: #xF0 #x9F #x8D #xBD (encoded by coding system utf-8-unix) display: no font available Character code properties: customize what to show name: FORK AND KNIFE WITH PLATE general-category: So (Symbol, Other) decomposition: (127869) ('🍽') There are text properties here: fontified nil ================ Following the instructions in NEWS I did: (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) But nothing changed. Doing this displayed the emoji character: (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) I gather the difference is that this character is part of script symbol and not emoji. I don't understand the difference and don't know if emacs is wrong about this or if I should know the difference. In other places on macOS and iOS it's just an emoji like any other. I do know that the instructions in NEWS didn't help me display a character that displayed fine for me in the macport of Emacs 27.2. I suspect other "emoji" have the same problem. On the macport with vertico and marginalia enabled (so I see completion candidates and their character displays) I feel that I see tofu for more emojis than Emacs 27 displayed (e.g, 0x1F6CF which is BED). Howard In GNU Emacs 28.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95)) of 2022-04-04 built on builder10-14.lan Windowing system distributor 'Apple', version 10.3.2022 System Description: macOS 11.6.5 Configured using: 'configure --with-ns '--enable-locallisppath=/Library/Application Support/Emacs/${version}/site-lisp:/Library/Application Support/Emacs/site-lisp' --with-modules' Configured features: ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS TOOLKIT_SCROLL_BARS ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue cocoa ns multi-tty make-network-process emacs) Memory information: ((conses 16 50130 8613) (symbols 48 6722 2) (strings 32 18540 1579) (string-bytes 1 611343) (vectors 16 15159) (vector-slots 8 455175 12837) (floats 8 21 40) (intervals 56 209 0) (buffers 992 11)) -- Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 13:07 bug#54970: 28.1; Some emoji no longer display Howard Melman @ 2022-04-16 14:18 ` Lars Ingebrigtsen 2022-04-16 14:55 ` Lars Ingebrigtsen 0 siblings, 1 reply; 60+ messages in thread From: Lars Ingebrigtsen @ 2022-04-16 14:18 UTC (permalink / raw) To: Howard Melman; +Cc: 54970 Howard Melman <hmelman@gmail.com> writes: > (I normally use the macport but I was able to reproduce this on vanilla > emacs 28.1 from emacsformacosx so please forgive if I get some details > wrong.) > > Using emacs -Q on MacOS 11.6.5: > > Use C-x 8 RET and select FORK AND KINFE WITH PLATE > > I don't actually see the character on vanilla emacs but if I put point > before it the cursor displays a bit wider if that makes sense. On the > macport I see tofu. I'm unable to reproduce this on Debian with emacs -Q in 28.1, so I guess it depends on the font selection code? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 14:18 ` Lars Ingebrigtsen @ 2022-04-16 14:55 ` Lars Ingebrigtsen 2022-04-16 15:27 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Lars Ingebrigtsen @ 2022-04-16 14:55 UTC (permalink / raw) To: Howard Melman; +Cc: 54970, Alan Third Lars Ingebrigtsen <larsi@gnus.org> writes: > I'm unable to reproduce this on Debian with emacs -Q in 28.1, so I guess > it depends on the font selection code? But I can reproduce it on Macos. I forget whether this is supposed to work out of the box, or whether you have to set the fontset things on Macos. Alan probably knows; I've added him to the CCs. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 14:55 ` Lars Ingebrigtsen @ 2022-04-16 15:27 ` Howard Melman 2022-04-16 16:02 ` Alan Third 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-16 15:27 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 54970, Alan Third On Apr 16, 2022, at 10:55 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote: > > Lars Ingebrigtsen <larsi@gnus.org> writes: > >> I'm unable to reproduce this on Debian with emacs -Q in 28.1, so I guess >> it depends on the font selection code? > > But I can reproduce it on Macos. I forget whether this is supposed to > work out of the box, or whether you have to set the fontset things on > Macos. Alan probably knows; I've added him to the CCs. For me in vanilla emacs -Q other emojis like 0x1f468 "MAN" and 0x1f415 "DOG" display out of the box in Apple Color Emoji. So I would think this should too. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 15:27 ` Howard Melman @ 2022-04-16 16:02 ` Alan Third 2022-04-16 16:21 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Alan Third @ 2022-04-16 16:02 UTC (permalink / raw) To: Howard Melman; +Cc: Lars Ingebrigtsen, 54970 On Sat, Apr 16, 2022 at 11:27:52AM -0400, Howard Melman wrote: > On Apr 16, 2022, at 10:55 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote: > > > > Lars Ingebrigtsen <larsi@gnus.org> writes: > > > >> I'm unable to reproduce this on Debian with emacs -Q in 28.1, so I guess > >> it depends on the font selection code? > > > > But I can reproduce it on Macos. I forget whether this is supposed to > > work out of the box, or whether you have to set the fontset things on > > Macos. Alan probably knows; I've added him to the CCs. > > For me in vanilla emacs -Q other emojis like 0x1f468 "MAN" and > 0x1f415 "DOG" display out of the box in Apple Color Emoji. > So I would think this should too. I think it's somewhat inconsistent if you don't set the font: (set-fontset-font t 'symbol "Apple Color Emoji") Please let us know if that makes any difference. -- Alan Third ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 16:02 ` Alan Third @ 2022-04-16 16:21 ` Howard Melman 2022-04-16 16:42 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-16 16:21 UTC (permalink / raw) To: Alan Third; +Cc: Lars Ingebrigtsen, 54970 On Apr 16, 2022, at 12:02 PM, Alan Third <alan@idiocy.org> wrote: > > On Sat, Apr 16, 2022 at 11:27:52AM -0400, Howard Melman wrote: >> On Apr 16, 2022, at 10:55 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote: >>> >>> Lars Ingebrigtsen <larsi@gnus.org> writes: >>> >>>> I'm unable to reproduce this on Debian with emacs -Q in 28.1, so I guess >>>> it depends on the font selection code? >>> >>> But I can reproduce it on Macos. I forget whether this is supposed to >>> work out of the box, or whether you have to set the fontset things on >>> Macos. Alan probably knows; I've added him to the CCs. >> >> For me in vanilla emacs -Q other emojis like 0x1f468 "MAN" and >> 0x1f415 "DOG" display out of the box in Apple Color Emoji. >> So I would think this should too. > > I think it's somewhat inconsistent if you don't set the font: > > (set-fontset-font t 'symbol "Apple Color Emoji") > > Please let us know if that makes any difference. As I said in my initial report, that (or something similar) did solve it for me. But the NEWS report said to do this: (set-fontset-font t 'emoji '("My New Emoji Font" . "iso10646-1") nil 'prepend) Which did not work for me, but this did: (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) I'm not clear about what the iso10646-1 part does or if it's needed. And the NEWS entry says: The Emoji characters are now assigned to a special script, 'emoji', so as to make it easier to customize fontsets for Emoji display, as in the above example. (Previously, the Emoji characters were assigned to the 'symbol' script, together with other symbol and punctuation characters.) Which reads to me as conflicting with needing to set the emoji font for 'symbol. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 16:21 ` Howard Melman @ 2022-04-16 16:42 ` Eli Zaretskii 2022-04-16 17:17 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-16 16:42 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, alan, 54970 > From: Howard Melman <hmelman@gmail.com> > Date: Sat, 16 Apr 2022 12:21:20 -0400 > Cc: Lars Ingebrigtsen <larsi@gnus.org>, 54970@debbugs.gnu.org > > > (set-fontset-font t 'symbol "Apple Color Emoji") > > > > Please let us know if that makes any difference. > > As I said in my initial report, that (or something similar) did solve it for me. > > But the NEWS report said to do this: > > (set-fontset-font t 'emoji > '("My New Emoji Font" . "iso10646-1") nil 'prepend) > > Which did not work for me, but this did: > > (set-fontset-font t 'symbol > '("Apple Color Emoji" . "iso10646-1") nil 'prepend) That's because we don't want to advertise the (non-free) Apple font. > I'm not clear about what the iso10646-1 part does or if it's needed. It makes the setting work more reliably in this case. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 16:42 ` Eli Zaretskii @ 2022-04-16 17:17 ` Howard Melman 2022-04-16 18:26 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-16 17:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, Alan Third, 54970 > On Apr 16, 2022, at 12:42 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Howard Melman <hmelman@gmail.com> >> Date: Sat, 16 Apr 2022 12:21:20 -0400 >> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 54970@debbugs.gnu.org >> >>> (set-fontset-font t 'symbol "Apple Color Emoji") >>> >>> Please let us know if that makes any difference. >> >> As I said in my initial report, that (or something similar) did solve it for me. >> >> But the NEWS report said to do this: >> >> (set-fontset-font t 'emoji >> '("My New Emoji Font" . "iso10646-1") nil 'prepend) >> >> Which did not work for me, but this did: >> >> (set-fontset-font t 'symbol >> '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > That's because we don't want to advertise the (non-free) Apple font. That's fine, but the first is for the script symbol 'emoji and the second is for the script symbol 'symbol and using the first with the Apple font didn't work. >> I'm not clear about what the iso10646-1 part does or if it's needed. > > It makes the setting work more reliably in this case. Not in my experience :) What I'm not clear about is why the registry "iso10646-1" is needed if I'm specifying a script for emoji which I think is always unicode. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 17:17 ` Howard Melman @ 2022-04-16 18:26 ` Eli Zaretskii 2022-04-16 19:19 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-16 18:26 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, alan, 54970 > From: Howard Melman <hmelman@gmail.com> > Date: Sat, 16 Apr 2022 13:17:45 -0400 > Cc: Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > > > > On Apr 16, 2022, at 12:42 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > > >> From: Howard Melman <hmelman@gmail.com> > >> Date: Sat, 16 Apr 2022 12:21:20 -0400 > >> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 54970@debbugs.gnu.org > >> > >>> (set-fontset-font t 'symbol "Apple Color Emoji") > >>> > >>> Please let us know if that makes any difference. > >> > >> As I said in my initial report, that (or something similar) did solve it for me. > >> > >> But the NEWS report said to do this: > >> > >> (set-fontset-font t 'emoji > >> '("My New Emoji Font" . "iso10646-1") nil 'prepend) > >> > >> Which did not work for me, but this did: > >> > >> (set-fontset-font t 'symbol > >> '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > > > That's because we don't want to advertise the (non-free) Apple font. > > That's fine, but the first is for the script symbol 'emoji and the second > is for the script symbol 'symbol and using the first with the Apple font > didn't work. Which is how it should be, AFAIU. That character is not in the Unicode Emoji sequences database. > >> I'm not clear about what the iso10646-1 part does or if it's needed. > > > > It makes the setting work more reliably in this case. > > Not in my experience :) What I'm not clear about is why the registry > "iso10646-1" is needed if I'm specifying a script for emoji which I think > is always unicode. Nobody knows. You are welcome to read the font-related code in Emacs, and if you figure that out, please be sure to tell us. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 18:26 ` Eli Zaretskii @ 2022-04-16 19:19 ` Howard Melman 2022-04-16 19:22 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-16 19:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, alan, 54970 > On Apr 16, 2022, at 2:26 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> That character is not in the Unicode Emoji sequences database. It's not? I don't know anything about emojis in Unicode other than it's more complicated than anyone would expect, but I see it in: http://git.savannah.gnu.org/cgit/emacs.git/tree/admin/unidata/emoji-sequences.txt?h=emacs-28 1F37D FE0F ; Basic_Emoji ; fork and knife with plate # E0.7 [1] (🍽️) Or am I misunderstanding something? Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 19:19 ` Howard Melman @ 2022-04-16 19:22 ` Eli Zaretskii 2022-04-16 20:07 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-16 19:22 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, alan, 54970 > From: Howard Melman <hmelman@gmail.com> > Date: Sat, 16 Apr 2022 15:19:25 -0400 > Cc: alan@idiocy.org, > larsi@gnus.org, > 54970@debbugs.gnu.org > > > > On Apr 16, 2022, at 2:26 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > > >> That character is not in the Unicode Emoji sequences database. > > It's not? I don't know anything about emojis in Unicode other than > it's more complicated than anyone would expect, but I see it in: > http://git.savannah.gnu.org/cgit/emacs.git/tree/admin/unidata/emoji-sequences.txt?h=emacs-28 > > 1F37D FE0F ; Basic_Emoji ; fork and knife with plate # E0.7 [1] (🍽️) > > Or am I misunderstanding something? Your recipe didn't mention the U+FE0F codepoint. You only talked about the lone U+1F37D. When followed by U+FE0F, Emacs indeed ought to display the sequence as Emoji, and that should not require you to change the font used for the 'symbol' pseudo-script. Are you saying that isn't happening in your case? ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 19:22 ` Eli Zaretskii @ 2022-04-16 20:07 ` Howard Melman 2022-04-17 5:53 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-16 20:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, alan, 54970 > On Apr 16, 2022, at 3:22 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> >> It's not? I don't know anything about emojis in Unicode other than >> it's more complicated than anyone would expect, but I see it in: >> http://git.savannah.gnu.org/cgit/emacs.git/tree/admin/unidata/emoji-sequences.txt?h=emacs-28 >> >> 1F37D FE0F ; Basic_Emoji ; fork and knife with plate # E0.7 [1] (🍽️) >> >> Or am I misunderstanding something? > > Your recipe didn't mention the U+FE0F codepoint. You only talked > about the lone U+1F37D. When followed by U+FE0F, Emacs indeed ought > to display the sequence as Emoji, and that should not require you to > change the font used for the 'symbol' pseudo-script. Are you saying > that isn't happening in your case? Indeed in Emacs 28 -Q if I C-x 8 RET FORK AND KNIFE WITH PLATE RET C-x 8 RET FE0F RET I see the emoji displayed. If I use the system emoji selector to insert a character into emacs It only puts in "the lone U+1F37D" (at least in emacs where I can check). In other apps this displays as an emoji, in emacs it's a blank. I said, I don't understand this stuff. Is this extra codepoint supposed to be added for me? It doesn't seem like other apps require it. I know this, in Emacs 27 macport I used C-x 8 RET and searched for plate and entered this character into a file and it displayed as an emoji. Several others I entered this way displayed fine too. I upgraded to Emacs 28 and the other characters display fine and this one didn't. I followed the instructions in NEWS and they didn't help. If the answer is just, this kind of emoji is different (though nothing else really exposes to it me as different), then I think the instructions (in NEWS or wherever) should just tell me to (set-fontset-font t 'symbol '("My New Emoji Font" . "iso10646-1") nil 'prepend) and not (set-fontset-font t 'emoji '("My New Emoji Font" . "iso10646-1") nil 'prepend) But I'd really like to understand the difference. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-16 20:07 ` Howard Melman @ 2022-04-17 5:53 ` Eli Zaretskii 2022-04-17 13:34 ` Robert Pluim 2022-04-17 14:35 ` Howard Melman 0 siblings, 2 replies; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 5:53 UTC (permalink / raw) To: Howard Melman, Robert Pluim; +Cc: larsi, alan, 54970 > From: Howard Melman <hmelman@gmail.com> > Date: Sat, 16 Apr 2022 16:07:38 -0400 > Cc: alan@idiocy.org, > larsi@gnus.org, > 54970@debbugs.gnu.org > > > Your recipe didn't mention the U+FE0F codepoint. You only talked > > about the lone U+1F37D. When followed by U+FE0F, Emacs indeed ought > > to display the sequence as Emoji, and that should not require you to > > change the font used for the 'symbol' pseudo-script. Are you saying > > that isn't happening in your case? > > Indeed in Emacs 28 -Q if I > > C-x 8 RET FORK AND KNIFE WITH PLATE RET > C-x 8 RET FE0F RET > > I see the emoji displayed. > > If I use the system emoji selector to insert a character into emacs > It only puts in "the lone U+1F37D" (at least in emacs where I can > check). In other apps this displays as an emoji, in emacs it's a blank. "Blank" meaning what? Emacs should display the character if there's a font on the system available to Emacs that has a glyph for that codepoint. It just might not display it as an Emoji, but as a slightly different symbol, and usually with a different font and without the colors inherent in Emoji display. That's what happens on my system. If that character doesn't display at all for you, maybe your fonts don't support it? The fundamental issue here is that some symbols have both an Emoji presentation and a "text" presentation, and the VARIATION SELECTOR n characters tell the rendering system which presentation to display. The U+FE0F VARIATION SELECTOR 16 character tells Emacs to show the Emoji presentation. Without the variation selectors, Emacs displays as Emoji only characters that are explicitly given the Emoji presentation as the default by the Unicode Character Database files. And AFAICT, U+1F37D is not one of them. (Robert, please correct me if I'm wrong here.) > I said, I don't understand this stuff. Is this extra codepoint supposed > to be added for me? It doesn't seem like other apps require it. Emacs currently doesn't insert the variation selectors automatically, although perhaps the Emoji input method should (or maybe already does, I didn't check). > I know this, in Emacs 27 macport I used C-x 8 RET and searched for plate > and entered this character into a file and it displayed as an emoji. > Several others I entered this way displayed fine too. I upgraded to > Emacs 28 and the other characters display fine and this one didn't. > I followed the instructions in NEWS and they didn't help. Macport Emacs is a separate project that uses its own policies in these somewhat gray areas. > If the answer is just, this kind of emoji is different (though nothing else > really exposes to it me as different), then I think the instructions (in NEWS > or wherever) should just tell me to > > (set-fontset-font t 'symbol '("My New Emoji Font" . "iso10646-1") nil 'prepend) > > and not > > (set-fontset-font t 'emoji '("My New Emoji Font" . "iso10646-1") nil 'prepend) No, that wouldn't be right. We introduced the special 'emoji' pseudo-script in Emacs 28 to solve the problems of being unable to distinguish between Emoji codepoints and the other symbols and punctuation. We definitely do NOT want to use an Emoji font for symbols and punctuation characters and character sequences that aren't Emoji. Moreover, configuring the fontset to use some font for the 'symbol' pseudo-script by default doesn't do what you expect, because Emacs uses the default font for symbols for which the default font has a glyph. So I think the recipe in NEWS is correct, and your expectations were inconsistent with the Emacs support for Emoji, at least with its state in Emacs 28.1. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 5:53 ` Eli Zaretskii @ 2022-04-17 13:34 ` Robert Pluim 2022-04-17 14:35 ` Howard Melman 2022-04-17 22:03 ` Howard Melman 2022-04-17 14:35 ` Howard Melman 1 sibling, 2 replies; 60+ messages in thread From: Robert Pluim @ 2022-04-17 13:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, 54970, Howard Melman, alan >>>>> On Sun, 17 Apr 2022 08:53:37 +0300, Eli Zaretskii <eliz@gnu.org> said: Eli> The fundamental issue here is that some symbols have both an Emoji Eli> presentation and a "text" presentation, and the VARIATION SELECTOR n Eli> characters tell the rendering system which presentation to display. Eli> The U+FE0F VARIATION SELECTOR 16 character tells Emacs to show the Eli> Emoji presentation. Without the variation selectors, Emacs displays Eli> as Emoji only characters that are explicitly given the Emoji Eli> presentation as the default by the Unicode Character Database files. Eli> And AFAICT, U+1F37D is not one of them. Eli> (Robert, please correct me if I'm wrong here.) Thatʼs exactly how it works. See <https://unicode.org/emoji/charts/emoji-style.html> for a listing of the affected codepoints and default styles. >> I said, I don't understand this stuff. Is this extra codepoint supposed >> to be added for me? It doesn't seem like other apps require it. Eli> Emacs currently doesn't insert the variation selectors automatically, Eli> although perhaps the Emoji input method should (or maybe already Eli> does, I didn't check). The stuff Lars added on master puts in variation selectors where needed. Eli> No, that wouldn't be right. We introduced the special 'emoji' Eli> pseudo-script in Emacs 28 to solve the problems of being unable to Eli> distinguish between Emoji codepoints and the other symbols and Eli> punctuation. We definitely do NOT want to use an Emoji font for Eli> symbols and punctuation characters and character sequences that aren't Eli> Emoji. Moreover, configuring the fontset to use some font for the Eli> 'symbol' pseudo-script by default doesn't do what you expect, because Eli> Emacs uses the default font for symbols for which the default font has Eli> a glyph. Modulo `use-default-font-for-symbols' Eli> So I think the recipe in NEWS is correct, and your expectations were Eli> inconsistent with the Emacs support for Emoji, at least with its state Eli> in Emacs 28.1. Iʼm not sure what we could change. I guess we could add a configuration variable that says 'treat every code point that has a default text presentation and an emoji one as emoji', except we already have that: VARIATION SELECTOR 16 Robert -- ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 13:34 ` Robert Pluim @ 2022-04-17 14:35 ` Howard Melman 2022-04-17 15:14 ` Robert Pluim 2022-04-17 22:03 ` Howard Melman 1 sibling, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 14:35 UTC (permalink / raw) To: Robert Pluim; +Cc: Lars Ingebrigtsen, 54970, Alan Third > On Apr 17, 2022, at 9:34 AM, Robert Pluim <rpluim@gmail.com> wrote: > >>>>>> On Sun, 17 Apr 2022 08:53:37 +0300, Eli Zaretskii <eliz@gnu.org> said: > > Eli> The fundamental issue here is that some symbols have both an Emoji > Eli> presentation and a "text" presentation, and the VARIATION SELECTOR n > Eli> characters tell the rendering system which presentation to display. > Eli> The U+FE0F VARIATION SELECTOR 16 character tells Emacs to show the > Eli> Emoji presentation. Without the variation selectors, Emacs displays > Eli> as Emoji only characters that are explicitly given the Emoji > Eli> presentation as the default by the Unicode Character Database files. > Eli> And AFAICT, U+1F37D is not one of them. > > Eli> (Robert, please correct me if I'm wrong here.) > > Thatʼs exactly how it works. See > <https://unicode.org/emoji/charts/emoji-style.html> for a listing of > the affected codepoints and default styles. Thanks for all this info. So on that page, in the second headed section of the table "Emoji Font" is where U+1F37D appears. In the "text-vs" row, which I think is the case of a lone U+1F37D, I see the emoji glyph in my mac browser. The description in that header says: “text+ts” should be monochrome; everything else should be colorful & monospace. which matches what I see. So I think, a lone U+1F37D should be displayed as an "emoji glyph". Can emacs be configured to display these lone codepoints via my emoji font? I gather that's what using the 'symbol script does but also includes more. Can I (or emacs out-of-the-box) be more selective in the call to set-fontset-font or some other api? >>> I said, I don't understand this stuff. Is this extra codepoint supposed >>> to be added for me? It doesn't seem like other apps require it. > > Eli> Emacs currently doesn't insert the variation selectors automatically, > Eli> although perhaps the Emoji input method should (or maybe already > Eli> does, I didn't check). > > The stuff Lars added on master puts in variation selectors where > needed. The emoji input method isn't on 28 so I can't check, but FWIW this seems to not match the behavior I see using the mac system emoji picker which seems to just insert a lone U+1F37D when I pick this emoji. And I'll add, if that's displayed equivalently I'd prefer it, because I wouldn't have to deal with "extra invisible characters" after the glyph when using emacs editing commands (unless this is different behavior in 29 than in 28 when I add the variation selector character). > Eli> No, that wouldn't be right. We introduced the special 'emoji' > Eli> pseudo-script in Emacs 28 to solve the problems of being unable to > Eli> distinguish between Emoji codepoints and the other symbols and > Eli> punctuation. We definitely do NOT want to use an Emoji font for > Eli> symbols and punctuation characters and character sequences that aren't > Eli> Emoji. Moreover, configuring the fontset to use some font for the > Eli> 'symbol' pseudo-script by default doesn't do what you expect, because > Eli> Emacs uses the default font for symbols for which the default font has > Eli> a glyph. > > Modulo `use-default-font-for-symbols' FWIW this variable set to t for me which I think is the default. > Eli> So I think the recipe in NEWS is correct, and your expectations were > Eli> inconsistent with the Emacs support for Emoji, at least with its state > Eli> in Emacs 28.1. > > Iʼm not sure what we could change. I guess we could add a > configuration variable that says 'treat every code point that has a > default text presentation and an emoji one as emoji', except we > already have that: VARIATION SELECTOR 16 I think the section I mentioned above is this case, that things in the "emojiFont" grouping, w/o a variation selector should be presented colorful and monospace (which I take to mean "as emoji"). Am I misunderstanding? Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 14:35 ` Howard Melman @ 2022-04-17 15:14 ` Robert Pluim 2022-04-17 18:44 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Robert Pluim @ 2022-04-17 15:14 UTC (permalink / raw) To: Howard Melman; +Cc: Lars Ingebrigtsen, 54970, Alan Third >>>>> On Sun, 17 Apr 2022 10:35:17 -0400, Howard Melman <hmelman@gmail.com> said: Howard> Thanks for all this info. So on that page, in the second headed section of the Howard> table "Emoji Font" is where U+1F37D appears. In the "text-vs" row, which Howard> I think is the case of a lone U+1F37D, I see the emoji glyph in my mac browser. Howard> The description in that header says: Howard> “text+ts” should be monochrome; everything else should be colorful & monospace. Howard> which matches what I see. So I think, a lone U+1F37D should be displayed Howard> as an "emoji glyph". _If_ you've specified an emoji font for it, which we donʼt do by default, since it has Emoji_Presentation = False, so you should look at the "Plain" section instead. Howard> Can emacs be configured to display these lone codepoints via my emoji font? Howard> I gather that's what using the 'symbol script does but also includes more. Howard> Can I (or emacs out-of-the-box) be more selective in the call to Howard> set-fontset-font or some other api? Yes. Try: (set-fontset-font t #x1f37d '("Apple Color Emoji" . "iso10646-1") nil 'prepend) For a range of codepoints, replace #x1f37d with something like '(#x1f37d . #x1f3aa) >>>> I said, I don't understand this stuff. Is this extra codepoint supposed >>>> to be added for me? It doesn't seem like other apps require it. >> Eli> Emacs currently doesn't insert the variation selectors automatically, Eli> although perhaps the Emoji input method should (or maybe already Eli> does, I didn't check). >> >> The stuff Lars added on master puts in variation selectors where >> needed. Howard> The emoji input method isn't on 28 so I can't check, but FWIW this seems Howard> to not match the behavior I see using the mac system emoji picker Howard> which seems to just insert a lone U+1F37D when I pick this emoji. I donʼt think we should follow what the mac does when it contradicts what Unicode is telling us. Howard> And I'll add, if that's displayed equivalently I'd prefer it, because I wouldn't Howard> have to deal with "extra invisible characters" after the glyph when Howard> using emacs editing commands (unless this is different behavior in 29 Howard> than in 28 when I add the variation selector character). Those characters get composed, so they get treated as a single unit. They really donʼt cause any problems. >> Modulo `use-default-font-for-symbols' Howard> FWIW this variable set to t for me which I think is the default. I meant you should try setting it to 'nil'. Eli> So I think the recipe in NEWS is correct, and your expectations were Eli> inconsistent with the Emacs support for Emoji, at least with its state Eli> in Emacs 28.1. >> >> Iʼm not sure what we could change. I guess we could add a >> configuration variable that says 'treat every code point that has a >> default text presentation and an emoji one as emoji', except we >> already have that: VARIATION SELECTOR 16 Howard> I think the section I mentioned above is this case, that things in the Howard> "emojiFont" grouping, w/o a variation selector should be presented Howard> colorful and monospace (which I take to mean "as emoji"). Am I Howard> misunderstanding? Again: when an emoji font has been specified for the codepoint. Robert -- ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 15:14 ` Robert Pluim @ 2022-04-17 18:44 ` Howard Melman 2022-04-17 18:49 ` Lars Ingebrigtsen 2022-04-17 18:58 ` Eli Zaretskii 0 siblings, 2 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 18:44 UTC (permalink / raw) To: Robert Pluim; +Cc: Lars Ingebrigtsen, 54970, Alan Third [-- Attachment #1: Type: text/plain, Size: 4670 bytes --] > On Apr 17, 2022, at 11:14 AM, Robert Pluim <rpluim@gmail.com> wrote: > >>>>>> On Sun, 17 Apr 2022 10:35:17 -0400, Howard Melman <hmelman@gmail.com> said: > > Howard> Thanks for all this info. So on that page, in the second headed section of the > Howard> table "Emoji Font" is where U+1F37D appears. In the "text-vs" row, which > Howard> I think is the case of a lone U+1F37D, I see the emoji glyph in my mac browser. > Howard> The description in that header says: > > Howard> “text+ts” should be monochrome; everything else should be colorful & monospace. > > Howard> which matches what I see. So I think, a lone U+1F37D should be displayed > Howard> as an "emoji glyph". > > _If_ you've specified an emoji font for it, which we donʼt do by > default, since it has Emoji_Presentation = False, Ok, so you find out that U+1F37D has Emoji_Presentation = False from http://www.unicode.org/Public/emoji/1.0//emoji-data.txt which indicates the default presentation should be text: 1F37D ; text ; L2 ; none ; w # V7.0 (🍽) FORK AND KNIFE WITH PLATE > so you should look at the "Plain" section instead. Ok, looking in the plain section under text-vs on macos 11.6.5 in Safari I see an emoji glyph there too for U+1F37D. This is the plain section and U+1F37D is at the end of the top row in this image. There are a lot of emoji shown in that section but less than in the emojiFont section. > > Howard> Can emacs be configured to display these lone codepoints via my emoji font? > Howard> I gather that's what using the 'symbol script does but also includes more. > Howard> Can I (or emacs out-of-the-box) be more selective in the call to > Howard> set-fontset-font or some other api? > > Yes. Try: > > (set-fontset-font t #x1f37d > '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > For a range of codepoints, replace #x1f37d with something like > '(#x1f37d . #x1f3aa) Thanks, doing these definitely gets me further to where I'd like: (set-fontset-font t '(#x1F170 . #x1F6F3) '("Apple Color Emoji" . "iso10646-1") nil 'prepend) (set-fontset-font t '(#x2139 . #x3299) '("Apple Color Emoji" . "iso10646-1") nil 'prepend) I'm still confused as to why the above works but this didn't: (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) And I as I look at script-representative-chars, emoji is defined to be (emoji 127744 128512) which I think means the hex range x1F300 - x1F600 so shouldn't include x1f37d? Or does it not because the default expression is text? And if so how is that factored into the emoji script symbol passed to set-fontset-font, I don't see how that's defined other than as this range. And when I specify a range directly I get my pretty glyph displayed. > I donʼt think we should follow what the mac does when it contradicts > what Unicode is telling us. I certainly agree with this. I see that https://unicode.org/reports/tr51/#Emoji_Implementation_Notes says: • only fully-qualified emoji zwj sequences should be generated by keyboards and other user input devices. and working through the definition of fully-qualified emoji https://unicode.org/reports/tr51/#def_fully_qualified_emoji a lone U+1F37D is not fully-qualified. If I understand emacs' state correctly, insert-char is doing the right thing because it's just inserting a character. I think I'm picking an emoji but I'm not really, I'm picking a single character (in this case U+1F37D). A later Emacs will have an emoji input method that would be like a real emoji picker that lets me insert a proper fully-qualified sequence. > Howard> And I'll add, if that's displayed equivalently I'd prefer it, because I wouldn't > Howard> have to deal with "extra invisible characters" after the glyph when > Howard> using emacs editing commands (unless this is different behavior in 29 > Howard> than in 28 when I add the variation selector character). > > Those characters get composed, so they get treated as a single > unit. They really donʼt cause any problems. Well C-f and C-b seem to move point between them which is somewhat startling. >>> Modulo `use-default-font-for-symbols' > > Howard> FWIW this variable set to t for me which I think is the default. > > I meant you should try setting it to 'nil'. In an emacs -Q in the scratch buffer I inserted a lone U+1F37D Toggling use-default-font-for-symbols had no effect on its display. Even after I did: (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) Howard [-- Attachment #2.1: Type: text/html, Size: 8164 bytes --] [-- Attachment #2.2: Screen Shot 2022-04-17 at 12.01.23 PM.png --] [-- Type: image/png, Size: 237089 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:44 ` Howard Melman @ 2022-04-17 18:49 ` Lars Ingebrigtsen 2022-04-17 18:56 ` Howard Melman 2022-04-17 18:58 ` Eli Zaretskii 1 sibling, 1 reply; 60+ messages in thread From: Lars Ingebrigtsen @ 2022-04-17 18:49 UTC (permalink / raw) To: Howard Melman; +Cc: Robert Pluim, 54970, Alan Third Howard Melman <hmelman@gmail.com> writes: > I'm still confused as to why the above works but this didn't: > > (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) This works for me: (set-fontset-font t 'symbol '("Apple Color Emoji") nil 'prepend) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:49 ` Lars Ingebrigtsen @ 2022-04-17 18:56 ` Howard Melman 0 siblings, 0 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 18:56 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Robert Pluim, 54970, Alan Third > On Apr 17, 2022, at 2:49 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote: > > Howard Melman <hmelman@gmail.com> writes: > >> I'm still confused as to why the above works but this didn't: >> >> (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > This works for me: > > (set-fontset-font t 'symbol '("Apple Color Emoji") nil 'prepend) Yes, it does for me too. But this started because the NEWS file said to use 'emoji and that didn't work. And as I've learned, I probably don't want to set all symbols to use Apple Color Emoji. But I'm still unclear as to why 'emoji didn't work. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:44 ` Howard Melman 2022-04-17 18:49 ` Lars Ingebrigtsen @ 2022-04-17 18:58 ` Eli Zaretskii 2022-04-17 19:40 ` Howard Melman 1 sibling, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 18:58 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 14:44:25 -0400 > Cc: Eli Zaretskii <eliz@gnu.org>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > I'm still confused as to why the above works but this didn't: > > (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) Because that character is not in the emoji script: (aref char-script-table #x1f37d) => symbol > And I as I look at script-representative-chars, emoji is defined to be (emoji 127744 128512) > which I think means the hex range x1F300 - x1F600 so shouldn't include x1f37d? You misinterpret script-representative-chars. That doesn't mean the range of characters between the values, but only the discrete examples of the script's characters, which Emacs uses to see if a font supports a script well enough to use it. IOW, only those specific codepoints are used as representatives, not any others. > Or does it not because the default expression is text? And if so how is that > factored into the emoji script symbol passed to set-fontset-font, I don't see > how that's defined other than as this range. See lisp/international/charscript.el for how we assign characters to scripts. (It's a file generated from the UCD.) > > Those characters get composed, so they get treated as a single > > unit. They really donʼt cause any problems. > > Well C-f and C-b seem to move point between them which is somewhat startling. No, they shouldn't. If they do, it means you don't have character composition working. "C-u C-x =" should describe the composition of it happened. > >>> Modulo `use-default-font-for-symbols' > > > > Howard> FWIW this variable set to t for me which I think is the default. > > > > I meant you should try setting it to 'nil'. > > In an emacs -Q in the scratch buffer I inserted a lone U+1F37D > Toggling use-default-font-for-symbols had no effect on its display. It will only have effect if the default font has a glyph for that character. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:58 ` Eli Zaretskii @ 2022-04-17 19:40 ` Howard Melman 0 siblings, 0 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 19:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, 54970, rpluim, alan Thanks for the elided info, I get it now. > On Apr 17, 2022, at 2:58 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> >> Well C-f and C-b seem to move point between them which is somewhat startling. > > No, they shouldn't. If they do, it means you don't have character > composition working. "C-u C-x =" should describe the composition of > it happened. Yes I see that. I swear that at the beginning of this when I first used insert-char to add FE0F after 1f37d they didn't compose, but I can't reproduce that now. >> In an emacs -Q in the scratch buffer I inserted a lone U+1F37D >> Toggling use-default-font-for-symbols had no effect on its display. > > It will only have effect if the default font has a glyph for that character. Ah I was confusing default font with default fontset. And I gather that something is loading Apple Color Emoji into my fontset when I type something emacs thinks it can display. Because if I do describe-fontset in a new emacs -Q Apple Color Emoji isn't there, but if I insert the man emoji (which displays) and do describe-fontset again Apple Color Emoji is there. Thanks, I think I'm caught up now. Thanks for the all the handholding. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 13:34 ` Robert Pluim 2022-04-17 14:35 ` Howard Melman @ 2022-04-17 22:03 ` Howard Melman 2022-04-18 5:12 ` Eli Zaretskii 1 sibling, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 22:03 UTC (permalink / raw) To: Robert Pluim; +Cc: larsi, 54970, alan So back to this: > On Apr 17, 2022, at 9:34 AM, Robert Pluim <rpluim@gmail.com> wrote: > > Eli> No, that wouldn't be right. We introduced the special 'emoji' > Eli> pseudo-script in Emacs 28 to solve the problems of being unable to > Eli> distinguish between Emoji codepoints and the other symbols and > Eli> punctuation. We definitely do NOT want to use an Emoji font for > Eli> symbols and punctuation characters and character sequences that aren't > Eli> Emoji. Moreover, configuring the fontset to use some font for the > Eli> 'symbol' pseudo-script by default doesn't do what you expect, because > Eli> Emacs uses the default font for symbols for which the default font has > Eli> a glyph. > > Modulo `use-default-font-for-symbols' > > Eli> So I think the recipe in NEWS is correct, and your expectations were > Eli> inconsistent with the Emacs support for Emoji, at least with its state > Eli> in Emacs 28.1. > > Iʼm not sure what we could change. I guess we could add a > configuration variable that says 'treat every code point that has a > default text presentation and an emoji one as emoji', except we > already have that: VARIATION SELECTOR 16 Yes, I think I would like a configuration variable like that. It's seems like a good application of the Robustness Principle. I also thought perhaps there should be another "script" parallel to 'emoji that included these so I could something like (set-fontset-font t 'emoji-vs '("Apple Color Emoji" . "iso10646-1") nil 'prepend) but now I suspect that's not really the right way? Or is it? Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 22:03 ` Howard Melman @ 2022-04-18 5:12 ` Eli Zaretskii [not found] ` <0AC9BAB0-35AA-4088-BEEB-66D5B0459FC2@gmail.com> 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-18 5:12 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 18:03:38 -0400 > Cc: Eli Zaretskii <eliz@gnu.org>, > alan@idiocy.org, > larsi@gnus.org, > 54970@debbugs.gnu.org > > > Iʼm not sure what we could change. I guess we could add a > > configuration variable that says 'treat every code point that has a > > default text presentation and an emoji one as emoji', except we > > already have that: VARIATION SELECTOR 16 > > Yes, I think I would like a configuration variable like that. It's seems like a good > application of the Robustness Principle. We decided not to use the Emoji presentation of these characters by default for a good reason: there are many symbols that _can_ have Emoji presentation, but they are used frequently in "normal" text. Look at the beginning of admin/unidata/emoji-data.txt, and you will see what I mean: even ASCII characters like '#' and digits can have Emoji presentation, and we definitely don't want them appear as Emoji. Don't forget that Emacs display features like this one are _global_, so if for some insane reason we decide to have digits displayed as Emoji, you will get that everywhere, including on the mode line, for example. So what will that hypothetical variable do? It cannot affect all the characters that _may_ have the Emoji presentation, so we will need to decide which ones to affect and which ones not to affect. If you look at emoji-data.txt, you will realize that the decision is not easy; for example, what about U+2122 TRADE MARK SIGN or U+23F0 ALARM CLOCK or U+262E PEACE SYMBOL? Some people will want them as Emoji, while others won't. So we'd need another variable with a long list of codepoints that are Emoji by default? Such a variable sounds like a PITA to let users customize. So we decided not to do any of that, and instead to go with the default presentation as determined by Unicode. I hope you now understand better why we did that. > I also thought perhaps there should be another "script" parallel to 'emoji that > included these so I could something like > > (set-fontset-font t 'emoji-vs '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > but now I suspect that's not really the right way? Or is it? A character cannot belong to more than one script in Emacs, so that's not possible, AFAIU. And I don't see why it would be necessary, since one can customize the fontset for individual codepoints without using a script symbol. ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <0AC9BAB0-35AA-4088-BEEB-66D5B0459FC2@gmail.com>]
* bug#54970: 28.1; Some emoji no longer display [not found] ` <0AC9BAB0-35AA-4088-BEEB-66D5B0459FC2@gmail.com> @ 2022-04-18 13:19 ` Howard Melman 2022-04-22 21:56 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-18 13:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third Sigh, I'm sorry the screenshots came out so small, my mail program reduced them for space. If you want larger versions of some or all of them I can supply. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-18 13:19 ` Howard Melman @ 2022-04-22 21:56 ` Howard Melman 2022-04-23 7:51 ` Eli Zaretskii 2022-04-23 9:46 ` Eli Zaretskii 0 siblings, 2 replies; 60+ messages in thread From: Howard Melman @ 2022-04-22 21:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third [-- Attachment #1: Type: text/plain, Size: 1930 bytes --] I have two follow up questions. First, is composition supposed to work everywhere? I have the following code to add to the C-x 8 map and I use which-key from gnu elpa but its displayed help isn't composing. It's just a buffer named " *which-key*" and I can switch to it but can't do anything in it to inspect things. It's hard to follow how they're writing to it. I can open a which-key bug but I wanted to understand more about composing and if it's supposed to be enabled everywhere (which-key doesn't reference it at all) Second, I'm using this now for emoji fonts: (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) I saw from a related reddit post that the font Symbola has some other glyphs that seemed of interest. It renders things as plain graphics not as color emoji which is fine (or preferred) for math symbols. I'd like to use Apple Color Emoji first and then if it doesn't support a character fall back on Symbola. I thought to do that with: (set-fontset-font t 'symbol '("Symbola" . "iso10646-1") nil 'prepend) (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) But it didn't work. Most emoji were rending as Symbola. I then removed the first line and restarted emacs (so just my original line is in the init) and emoji were *still* rendered with Symbola. It wasn't until I disabled the font in the mac utility Font Book.app that it went back to full color emoji rendering. I recall a similar issue a year ago trying to get Julia Mono working too. What's the right incantation to do this? I tried with just the 'emoji script on the second call but it didn't help. How and when is emacs searching for fonts to use and how does it relate to the above set-fontset-font calls? It's nice that emacs just finds fonts, but it's unnerving that merely installing a font can break what emacs displays. Howard [-- Attachment #2.1: Type: text/html, Size: 3031 bytes --] [-- Attachment #2.2: Screen Shot 2022-04-22 at 4.33.24 PM.png --] [-- Type: image/png, Size: 210612 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-22 21:56 ` Howard Melman @ 2022-04-23 7:51 ` Eli Zaretskii 2022-04-23 16:35 ` Howard Melman 2022-04-23 9:46 ` Eli Zaretskii 1 sibling, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-23 7:51 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Fri, 22 Apr 2022 17:56:34 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > First, is composition supposed to work everywhere? Yes -- as long as the font used for the characters supports that. In particular, all the characters of a sequence that's expected to be composed should be supported by a single font that is used for the character (usually, but not always, the first character of the composed sequence) that triggers the composition rule. > I have the following > code to add to the C-x 8 map and I use which-key from gnu elpa but its > displayed help isn't composing. It's just a buffer named " *which-key*" > and I can switch to it but can't do anything in it to inspect things. It's hard > to follow how they're writing to it. I can open a which-key bug but I wanted > to understand more about composing and if it's supposed to be enabled > everywhere (which-key doesn't reference it at all) Please discuss this with the developer of which-key, or ask him to join this discussions and answer your questions about which-key. That package is highly non-trivial, weighs in at 2700 lines of Lisp, and defines several faces (which might affect character composition), so it isn't easy to understand what it does and how, and isn't really our job here. If and when the which-key developer decides there's a core bug/issue, please come back and show a recipe starting from "emacs -Q" for reproducing the bug/issue, and we will look into that. > Second, I'm using this now for emoji fonts: > > (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > I saw from a related reddit post that the font Symbola has some other glyphs > that seemed of interest. It renders things as plain graphics not as color > emoji which is fine (or preferred) for math symbols. I'd like to use Apple > Color Emoji first and then if it doesn't support a character fall back on > Symbola. I thought to do that with: > > (set-fontset-font t 'symbol '("Symbola" . "iso10646-1") nil 'prepend) > (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) > > But it didn't work. Most emoji were rending as Symbola. I then removed the > first line and restarted emacs (so just my original line is in the init) and emoji > were *still* rendered with Symbola. It wasn't until I disabled the font in the > mac utility Font Book.app that it went back to full color emoji rendering. I recall > a similar issue a year ago trying to get Julia Mono working too. What was the value of use-default-font-for-symbols? If it was non-nil, Emacs will in general try to ignore the fontset when it needs a font for a character belonging to the 'symbol' pseudo-script. Also, what does the fontset entry for the relevant character(s) say? (Invoke "M-x describe-fontset RET fontset-default RET" and look for the entry that corresponds to the codepoints of the characters you are interested in.) Note that the default fontset with which Emacs starts already includes references to Symbola, even without any customizations. And what else is in your init files, besides those two lines? IOW, you didn't provide enough details to help you understand what happened in your case. You didn't even tell what characters you tried to display, without which it is hard to make any progress here. > What's the right incantation to do this? To do what? > How and when is emacs searching for fonts to use and how does it > relate to the above set-fontset-font calls? This question is too general. In general, Emacs looks for a font when the default font doesn't have a glyph for a character; it first tries to find a loaded font that supports the character, and if not found looks in the fonts specified by the fontsets. > It's nice that emacs just finds fonts, but it's unnerving that > merely installing a font can break what emacs displays. Sorry, I didn't see anything in your report that could be qualified as "breakage". Emacs just used a font other than the one you intended to display some (unnamed) characters, probably because you didn't sufficiently understand the intricacies of setting up fontsets. That doesn't qualify as breakage, IMO. And yes, setting up fontsets is a subtle art. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-23 7:51 ` Eli Zaretskii @ 2022-04-23 16:35 ` Howard Melman 2022-04-23 16:58 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-23 16:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970 > On Apr 23, 2022, at 3:51 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> First, is composition supposed to work everywhere? > > Yes -- as long as the font used for the characters supports that. > Please discuss this with the developer of which-key Ok, I've opened a bug with which-key to do that. Thanks. I had also found the which-key code involved but didn't find any references to composition in it or other obvious things it did to disable it and wanted to confirm that it probably shouldn't have to do anything to enable it. >> Second, I'm using this now for emoji fonts: >> >> (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) >> >> I saw from a related reddit post that the font Symbola has some other glyphs >> that seemed of interest. It renders things as plain graphics not as color >> emoji which is fine (or preferred) for math symbols. I'd like to use Apple >> Color Emoji first and then if it doesn't support a character fall back on >> Symbola. I thought to do that with: >> >> (set-fontset-font t 'symbol '("Symbola" . "iso10646-1") nil 'prepend) >> (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) >> >> But it didn't work. Most emoji were rending as Symbola. I then removed the >> first line and restarted emacs (so just my original line is in the init) and emoji >> were *still* rendered with Symbola. It wasn't until I disabled the font in the >> mac utility Font Book.app that it went back to full color emoji rendering. I recall >> a similar issue a year ago trying to get Julia Mono working too. > > What was the value of use-default-font-for-symbols? If it was > non-nil, Emacs will in general try to ignore the fontset when it needs > a font for a character belonging to the 'symbol' pseudo-script. It is t, which I believe is the default value. The manuals don't mention use-default-font-for-symbols so I didn't know about that. > Also, what does the fontset entry for the relevant character(s) say? > (Invoke "M-x describe-fontset RET fontset-default RET" and look for > the entry that corresponds to the codepoints of the characters you are > interested in.) Note that the default fontset with which Emacs starts > already includes references to Symbola, even without any > customizations. > > And what else is in your init files, besides those two lines? I can reproduce this in emacs -Q so the answer is nothing. Sorry I didn't mention a specific character, but it was a lot of them and it's hard to lookup codepoints for each of them. Here are ones I saw from a file: 🥇 🥈 🥉 💰 ✅ 👍️ 👎️ 👋️ 🤦♂️️ 🤷♂️ ⭐️ 📺️ 🎥 ♠️ ♣️ ♥️ ♦️ 😡 😢 🙄 😂 🤣 😀 🤔 😉 1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣ 6️⃣ 7️⃣ 8️⃣ 9️⃣ 0️⃣ 🔨 🎯 🗡 ❄️ 🔥 ⚡️ ☠️ 💥 🙏🏻 👉 🔭️ 💪 ⏳ 😖 ⏩️ 👬 ⏪️ ♻️ And there were may others I saw doing insert-char with a completion system that showed and rendered the characters. So I worked with 0x1F528 (HAMMER) a level 1 emoji who's default rendering is emoji, not text. Checking describe-fontset for it I see: 📿 .. 🔽 (#x1F4FF .. #x1F53D) -*-Noto Color Emoji-*-*-*-*-*-*-*-*-*-*-iso10646-1 -*-Symbola-*-*-*-*-*-*-*-*-*-*-iso10646-1 -*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1 I didn't realize emacs knew about Symbola (why would I?). And I had forgotten that the scripts symbol and emoji do not overlap at all (because from the previous issue setting the emoji script to use Apple Color Emoji (ACE) didn't cover many characters but setting it for symbol did cover them and seemingly every emoji. It turns out HAMMER is in script emoji, so setting the fontset for 'symbol didn't tell emacs to use ACE for it. With Symbola enabled emacs found it and used it. Without Symbola enabled emacs didn't find it and I guess searched for a font that includes this character and found ACE. So now I'm doing this: (set-fontset-font t 'symbol '("Apple Color Emoji" . "iso10646-1") nil 'prepend) (set-fontset-font t 'emoji '("Apple Color Emoji" . "iso10646-1") nil 'prepend) and it seems to work. I see emojis I've previously used rendered in ACE and I see some characters that ACE doesn't cover, like 0x 2b59 (HEAVY CIRCLED SALTIRE) rendered in Symbola. With Symbola enabled I now need to use both because emacs can find a font other than ACE that can render script emoji. I know the definition of the set of emojis is difficult but also that it doesn't overlap with the intuition of a user not steeped in Unicode. Perhaps this is particularly bad on a mac where ACE is used universally to render emoji and the system emoji picker (shared with iOS) includes as emoji many characters in both the emoji and symbol scripts. And I understand that you don't want to include references to ACE in emacs. I think I would have benefited from a describe-scripts command that some how showed what ranges these scripts cover in a way easier than using C-u C-x = for each character. Or maybe a function scripts-used-in-region that returned a list of the scripts of each character. I do think I and other mac users would benefit from a previously mentioned possibility of a setting handling those emoji who's default rendering is text to either render as emoji or include them in the emoji script (instead of symbol). I'm not really clear on categories in emacs. Maybe an emoji category that included characters from both script emoji and some from script symbol and a way to use it to modify a fontset? The Categories section of the elisp manual doesn't say where emacs uses them but I see them used in properties and regexps and an easy way to regexp search for any character in an emoji category would be nice. Back to the original post in this bug, the NEWS instructions to: (set-fontset-font t 'emoji '("My New Emoji Font" . "iso10646-1") nil 'prepend) confused me because it didn't seem to have any effect on macos. If this (or some other) instruction included "and you may want to do the same for the script symbol though it might include more characters you desire" it would have helped. Particularly if it recommended this for mac users. I don't see a mention of emoji in the emacs manual except in the antinews. Perhaps it could mention that emacs by default knows to look for Noto Color Emoji or Symbola for many emoji characters and how systems without these fonts might be configured effectively. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-23 16:35 ` Howard Melman @ 2022-04-23 16:58 ` Eli Zaretskii 2022-04-23 17:22 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-23 16:58 UTC (permalink / raw) To: Howard Melman; +Cc: 54970 > From: Howard Melman <hmelman@gmail.com> > Date: Sat, 23 Apr 2022 12:35:47 -0400 > Cc: 54970@debbugs.gnu.org > > I know the definition of the set of emojis is difficult but also that it > doesn't overlap with the intuition of a user not steeped in Unicode. > Perhaps this is particularly bad on a mac where ACE is used > universally to render emoji and the system emoji picker (shared > with iOS) includes as emoji many characters in both the emoji > and symbol scripts. And I understand that you don't want to include > references to ACE in emacs. > > I think I would have benefited from a describe-scripts command > that some how showed what ranges these scripts cover in a way > easier than using C-u C-x = for each character. Or maybe a > function scripts-used-in-region that returned a list of the scripts > of each character. These are all very complex technical issues, and I'm not sure the right way of letting users customize Emacs in these respects is to expose all that complexity and advertise it. We should try finding easier, more self-explanatory, customization means and options. > I do think I and other mac users would benefit from a previously > mentioned possibility of a setting handling those emoji who's default > rendering is text to either render as emoji or include them in > the emoji script (instead of symbol). Something to consider for the future, I guess. Emacs 28 is the first release to include a decent support for Emoji, and we are still collecting user experience about what we have. > I'm not really clear on categories in emacs. Maybe an emoji > category that included characters from both script emoji and > some from script symbol and a way to use it to modify a > fontset? The Categories section of the elisp manual doesn't > say where emacs uses them but I see them used in properties > and regexps and an easy way to regexp search for any character > in an emoji category would be nice. Categories are used in regular expressions, but the way fontsets are implemented, we cannot use categories for controlling font selection, except very indirectly and unreliably via character composition rules (which use regexps) -- and that will only affect composed sequences. > Back to the original post in this bug, the NEWS instructions to: > (set-fontset-font t 'emoji '("My New Emoji Font" . "iso10646-1") nil 'prepend) > confused me because it didn't seem to have any effect on macos. > If this (or some other) instruction included "and you may want to do the same > for the script symbol though it might include more characters you > desire" it would have helped. Particularly if it recommended > this for mac users. I don't see a mention of emoji in the emacs > manual except in the antinews. Perhaps it could mention that emacs > by default knows to look for Noto Color Emoji or Symbola for > many emoji characters and how systems without these fonts > might be configured effectively. NEWS describes what we think is the correct setup for Emoji. I'm still not convinced that telling users to customize the font for 'symbol' is a good idea, especially since we prefer symbols and punctuation to be displayed by the default font as much as possible. Maybe this contradicts what macOS users expect, but macOS is not the main platform we want to support. As for mentioning the fonts for which we set up by default -- there are others in the default fontset, and I don't see why those two are to be treated specially. OTOH, mentioning all of them would be too much, because there are many, and they differ by platforms. We should instead strive to make the default setup work seamlessly for everyone, IMO. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-23 16:58 ` Eli Zaretskii @ 2022-04-23 17:22 ` Howard Melman 2022-04-23 17:46 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-23 17:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970 On Apr 23, 2022, at 12:58 PM, Eli Zaretskii <eliz@gnu.org> wrote: > These are all very complex technical issues, and I'm not sure the > right way of letting users customize Emacs in these respects is to > expose all that complexity and advertise it. We should try finding > easier, more self-explanatory, customization means and options. > Emacs 28 is the first > release to include a decent support for Emoji, and we are still > collecting user experience about what we have. Agreed. Fundamentally I think some script or other collection mechanism that covers "emoji" is what's needed. I think what's in Emacs 28 is trying to do that and at least for this mac user still falls short. > NEWS describes what we think is the correct setup for Emoji. I'm > still not convinced that telling users to customize the font for > 'symbol' is a good idea, especially since we prefer symbols and > punctuation to be displayed by the default font as much as possible. I'm still not clear on this. With the set-fontset-font calls I describe I see punctuation (; . ! etc) in Menlo (the font I put in the default and fixed-pitch faces). I assume this is because use-default-font-for-symbols is t which is the default. So at least on my system this preference works out just as desired. > Maybe this contradicts what macOS users expect, but macOS is not the > main platform we want to support. Understood but it's still a platform you do support. > As for mentioning the fonts for which we set up by default -- there > are others in the default fontset, and I don't see why those two are > to be treated specially. OTOH, mentioning all of them would be too > much, because there are many, and they differ by platforms. We should > instead strive to make the default setup work seamlessly for everyone, > IMO. Agreed, but the mac platform is confounded because you can't mention or pre-configure the default font to be used in this case, which is fine. So all I'm asking for is some documentation someplace that would lead a mac user to the correct incantation or some description of the possible limitations encountered. In the absence of "easier, more self-explanatory, customization means and options" this seems like the most reasonable stopgap. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-23 17:22 ` Howard Melman @ 2022-04-23 17:46 ` Eli Zaretskii 2022-04-23 19:12 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-23 17:46 UTC (permalink / raw) To: Howard Melman; +Cc: 54970 > From: Howard Melman <hmelman@gmail.com> > Date: Sat, 23 Apr 2022 13:22:45 -0400 > Cc: 54970@debbugs.gnu.org > > > NEWS describes what we think is the correct setup for Emoji. I'm > > still not convinced that telling users to customize the font for > > 'symbol' is a good idea, especially since we prefer symbols and > > punctuation to be displayed by the default font as much as possible. > > I'm still not clear on this. With the set-fontset-font calls I describe I > see punctuation (; . ! etc) in Menlo (the font I put in the default and > fixed-pitch faces). I assume this is because use-default-font-for-symbols > is t which is the default. So at least on my system this preference works > out just as desired. Yes, but the problematic cases is when the symbols/punctuation coverage of the default font and of the font set up for the Symbols and punctuation blocks overlap, and overlap significantly. > > As for mentioning the fonts for which we set up by default -- there > > are others in the default fontset, and I don't see why those two are > > to be treated specially. OTOH, mentioning all of them would be too > > much, because there are many, and they differ by platforms. We should > > instead strive to make the default setup work seamlessly for everyone, > > IMO. > > Agreed, but the mac platform is confounded because you can't > mention or pre-configure the default font to be used in this case, > which is fine. So all I'm asking for is some documentation someplace > that would lead a mac user to the correct incantation or some description > of the possible limitations encountered. In the absence of "easier, > more self-explanatory, customization means and options" this seems > like the most reasonable stopgap. We did that in NEWS, didn't we? I'd prefer to see whether this is a problem for enough users for us to do something else about it except answering questions. If it turns out we do need that, my first thought would be to encourage people to use describe-fontset to see what they have, and take it from there. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-23 17:46 ` Eli Zaretskii @ 2022-04-23 19:12 ` Howard Melman 0 siblings, 0 replies; 60+ messages in thread From: Howard Melman @ 2022-04-23 19:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970 > On Apr 23, 2022, at 1:46 PM, Eli Zaretskii <eliz@gnu.org> wrote: > Yes, but the problematic cases is when the symbols/punctuation > coverage of the default font and of the font set up for the Symbols > and punctuation blocks overlap, and overlap significantly. > >> Agreed, but the mac platform is confounded because you can't >> mention or pre-configure the default font to be used in this case, >> which is fine. So all I'm asking for is some documentation someplace >> that would lead a mac user to the correct incantation or some description >> of the possible limitations encountered. In the absence of "easier, >> more self-explanatory, customization means and options" this seems >> like the most reasonable stopgap. > > We did that in NEWS, didn't we? Well you just did it for script 'emoji and that didn't cover everything for me. Perhaps most of the issues were the sequences that didn't include 0xFE0F and it would be great if there were a simple way to define all of those in a fontset or if the emoji input stuff on master was available for Emacs 28. There are some others, I think older emoji that are problematic. I think also that Apple Color Emoji doesn't define glyphs for the majority of "problematic" symbols so putting it in the fontset for those codepoints isn't a problem and solves the missing 0xFE0F issue. > I'd prefer to see whether this is a problem for enough users for us to > do something else about it except answering questions. If it turns > out we do need that, my first thought would be to encourage people to > use describe-fontset to see what they have, and take it from there. I'll keep playing with it. Maybe I'm the only emacs user on mac that uses emoji. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-22 21:56 ` Howard Melman 2022-04-23 7:51 ` Eli Zaretskii @ 2022-04-23 9:46 ` Eli Zaretskii 1 sibling, 0 replies; 60+ messages in thread From: Eli Zaretskii @ 2022-04-23 9:46 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Fri, 22 Apr 2022 17:56:34 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > First, is composition supposed to work everywhere? I have the following > code to add to the C-x 8 map and I use which-key from gnu elpa but its > displayed help isn't composing. It's just a buffer named " *which-key*" > and I can switch to it but can't do anything in it to inspect things. I'm not sure I understand the difficulty here. Maybe you didn't set cursor-type to t in that buffer? ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 5:53 ` Eli Zaretskii 2022-04-17 13:34 ` Robert Pluim @ 2022-04-17 14:35 ` Howard Melman 2022-04-17 14:44 ` Eli Zaretskii 1 sibling, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 14:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third [-- Attachment #1: Type: text/plain, Size: 1893 bytes --] > On Apr 17, 2022, at 1:53 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> Indeed in Emacs 28 -Q if I >> >> C-x 8 RET FORK AND KNIFE WITH PLATE RET >> C-x 8 RET FE0F RET >> >> I see the emoji displayed. >> >> If I use the system emoji selector to insert a character into emacs >> It only puts in "the lone U+1F37D" (at least in emacs where I can >> check). In other apps this displays as an emoji, in emacs it's a blank. > > "Blank" meaning what? > > Emacs should display the character if there's a font on the system > available to Emacs that has a glyph for that codepoint. It just might > not display it as an Emoji, but as a slightly different symbol, and > usually with a different font and without the colors inherent in Emoji > display. That's what happens on my system. If that character doesn't > display at all for you, maybe your fonts don't support it? Blank as I described in my original report where I included the output of C-u C-x = which does say there's no font available. Following the recipe with point before the added character it looks like this: with point after the character it looks like this: On the macport I see tofu which I think is better. > Macport Emacs is a separate project that uses its own policies in > these somewhat gray areas. I realize. I originally report this there because it did previously handle emoji better on mac but as of Emacs 28, it's NEWS says: Emoji composition handling is aligned with upstream. You may find some incompatibilities with the previous versions. In email, YAMAMOTO Mitsuharu said to me about this: "I only mentioned composition, but font selection is also affected." When I confirmed it was not displayed by the NS port either I reported it here. So FYI, I think in this area the macport policies are trying to converge with Emacs' policies, though I don't want to speak for them. Howard [-- Attachment #2.1: Type: text/html, Size: 3559 bytes --] [-- Attachment #2.2: Screen Shot 2022-04-17 at 9.34.55 AM.png --] [-- Type: image/png, Size: 11899 bytes --] [-- Attachment #2.3: Screen Shot 2022-04-17 at 9.37.07 AM.png --] [-- Type: image/png, Size: 7518 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 14:35 ` Howard Melman @ 2022-04-17 14:44 ` Eli Zaretskii 2022-04-17 14:50 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 14:44 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 10:35:11 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > > "Blank" meaning what? > > > > > Emacs should display the character if there's a font on the system > > available to Emacs that has a glyph for that codepoint. It just might > > not display it as an Emoji, but as a slightly different symbol, and > > usually with a different font and without the colors inherent in Emoji > > display. That's what happens on my system. If that character doesn't > > display at all for you, maybe your fonts don't support it? > > Blank as I described in my original report where I included the output > of C-u C-x = which does say there's no font available. Following the > recipe with point before the added character it looks like this: > > > > with point after the character it looks like this: > > > > On the macport I see tofu which I think is better. Emacs also displays tofu if it finds no suitable font. What you describe sounds like Emacs found some font that claimed to have a glyph for this codepoint, but the glyph displays as blank. Which is, of course, in contradiction with the "no font available" part, so I admit I don't understand what happened on your system. Was that in "emacs -Q"? ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 14:44 ` Eli Zaretskii @ 2022-04-17 14:50 ` Howard Melman 2022-04-17 15:50 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 14:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third > On Apr 17, 2022, at 10:44 AM, Eli Zaretskii <eliz@gnu.org> wrote: > > Emacs also displays tofu if it finds no suitable font. What you > describe sounds like Emacs found some font that claimed to have a > glyph for this codepoint, but the glyph displays as blank. Which is, > of course, in contradiction with the "no font available" part, so I > admit I don't understand what happened on your system. Was that in > "emacs -Q"? Yes it was. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 14:50 ` Howard Melman @ 2022-04-17 15:50 ` Eli Zaretskii 2022-04-17 15:54 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 15:50 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 10:49:35 -0400 > > > > On Apr 17, 2022, at 10:44 AM, Eli Zaretskii <eliz@gnu.org> wrote: > > > > Emacs also displays tofu if it finds no suitable font. What you > > describe sounds like Emacs found some font that claimed to have a > > glyph for this codepoint, but the glyph displays as blank. Which is, > > of course, in contradiction with the "no font available" part, so I > > admit I don't understand what happened on your system. Was that in > > "emacs -Q"? > > Yes it was. Does this empty display happen with every character for which you have no fonts? For example, what about this string: 𓂋𓏤𓈖𓆎𓅓𓏏𓊖? On my system, characters for which Emacs cannot find a font display as "tofu": small squares that show the codepoint of the character in hex. That's what should happen by default in those cases. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 15:50 ` Eli Zaretskii @ 2022-04-17 15:54 ` Howard Melman 2022-04-17 16:17 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 15:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third [-- Attachment #1: Type: text/plain, Size: 1127 bytes --] > On Apr 17, 2022, at 11:50 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Howard Melman <hmelman@gmail.com> >> Date: Sun, 17 Apr 2022 10:49:35 -0400 >> >> >>> On Apr 17, 2022, at 10:44 AM, Eli Zaretskii <eliz@gnu.org> wrote: >>> >>> Emacs also displays tofu if it finds no suitable font. What you >>> describe sounds like Emacs found some font that claimed to have a >>> glyph for this codepoint, but the glyph displays as blank. Which is, >>> of course, in contradiction with the "no font available" part, so I >>> admit I don't understand what happened on your system. Was that in >>> "emacs -Q"? >> >> Yes it was. > > Does this empty display happen with every character for which you have > no fonts? For example, what about this string: 𓂋𓏤𓈖𓆎𓅓𓏏𓊖? > > On my system, characters for which Emacs cannot find a font display as > "tofu": small squares that show the codepoint of the character in > hex. That's what should happen by default in those cases. I cut and pasted that string from Apple Mail to Emacs 28 -Q on macOS 11.6.5 and saw this: Howard [-- Attachment #2.1: Type: text/html, Size: 2029 bytes --] [-- Attachment #2.2: Screen Shot 2022-04-17 at 11.52.42 AM.png --] [-- Type: image/png, Size: 12930 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 15:54 ` Howard Melman @ 2022-04-17 16:17 ` Eli Zaretskii 2022-04-17 16:48 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 16:17 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 11:54:39 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > > Does this empty display happen with every character for which you have > > no fonts? For example, what about this string: 𓂋𓏤𓈖𓆎𓅓𓏏𓊖? > > > > On my system, characters for which Emacs cannot find a font display as > > "tofu": small squares that show the codepoint of the character in > > hex. That's what should happen by default in those cases. > > I cut and pasted that string from Apple Mail to Emacs 28 -Q on macOS 11.6.5 > and saw this: So the example didn't work, because you do have a font for those characters. Can you find some characters that don't have fonts? For example, do any of the scripts in etc/HELLO show as tofu or "blank"? (I'm trying to understand why you had those blank displays where you should have seen tofu; if you are not interested in trying to figure this out further, I'm fully prepared to stop asking questions.) ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 16:17 ` Eli Zaretskii @ 2022-04-17 16:48 ` Howard Melman 2022-04-17 18:00 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 16:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third [-- Attachment #1: Type: text/plain, Size: 668 bytes --] On Apr 17, 2022, at 12:17 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > So the example didn't work, because you do have a font for those > characters. Can you find some characters that don't have fonts? For > example, do any of the scripts in etc/HELLO show as tofu or "blank"? > > (I'm trying to understand why you had those blank displays where you > should have seen tofu; if you are not interested in trying to figure > this out further, I'm fully prepared to stop asking questions.) I'm willing. FYI, I'm using the prebuilt emacs 28 from https://emacsformacosx.com/ I don't build my own. Here are two images showing the whole HELLO file. [-- Attachment #2.1: Type: text/html, Size: 1522 bytes --] [-- Attachment #2.2: Screen Shot 2022-04-17 at 12.47.15 PM.png --] [-- Type: image/png, Size: 840505 bytes --] [-- Attachment #2.3: Screen Shot 2022-04-17 at 12.47.41 PM.png --] [-- Type: image/png, Size: 258733 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 16:48 ` Howard Melman @ 2022-04-17 18:00 ` Eli Zaretskii 2022-04-17 18:09 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 18:00 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 12:48:32 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > > So the example didn't work, because you do have a font for those > > characters. Can you find some characters that don't have fonts? For > > example, do any of the scripts in etc/HELLO show as tofu or "blank"? > > > > (I'm trying to understand why you had those blank displays where you > > should have seen tofu; if you are not interested in trying to figure > > this out further, I'm fully prepared to stop asking questions.) > > I'm willing. FYI, I'm using the prebuilt emacs 28 from https://emacsformacosx.com/ > I don't build my own. > > Here are two images showing the whole HELLO file. You have too many fonts ;-) It is strange that with so many fonts the U+1F37D couldn't be displayed. Okay, try with codepoints between D800 and DB7F: what does that produce? ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:00 ` Eli Zaretskii @ 2022-04-17 18:09 ` Howard Melman 2022-04-17 18:27 ` Lars Ingebrigtsen 2022-04-17 18:34 ` Eli Zaretskii 0 siblings, 2 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 18:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third On Apr 17, 2022, at 2:00 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > You have too many fonts ;-) It is strange that with so many fonts the > U+1F37D couldn't be displayed. macOS supports lots of languages out of the box :) I'm reading a lot about unicode and fontsets and trying to wrap my head around it. I can't quite answer this yet, the font to display U+1F37D is Apple Color Emoji. I get that emacs might not want to enable that font by default, but emacs does use it by default to show some emoji, though I don't see it listed when I do M-x describe-fontset. > Okay, try with codepoints between D800 and DB7F: what does that produce? I'm sorry I don't follow what you want me to do, can you be more specific? Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:09 ` Howard Melman @ 2022-04-17 18:27 ` Lars Ingebrigtsen 2022-04-17 18:36 ` Eli Zaretskii 2022-04-17 18:34 ` Eli Zaretskii 1 sibling, 1 reply; 60+ messages in thread From: Lars Ingebrigtsen @ 2022-04-17 18:27 UTC (permalink / raw) To: Howard Melman; +Cc: 54970, Alan Third, Robert Pluim Howard Melman <hmelman@gmail.com> writes: > I'm reading a lot about unicode and fontsets and trying to wrap > my head around it. I can't quite answer this yet, the font to display > U+1F37D is Apple Color Emoji. I get that emacs might not want > to enable that font by default, but emacs does use it by default to show > some emoji, though I don't see it listed when I do M-x describe-fontset. I haven't been following this thread closely, but has somebody mentioned that some characters have both a symbol and an emoji expression? My guess is that Apple, by default, displays characters like 🍽 "fork and knife with plate" using the emoji expression. So it has a font with a definition with the non-emoji expression which is just blank. Emacs, by default, uses the symbol expression for the character, unless you tell Emacs to do something else. Other characters have only an emoji expression, and then there's no confusion. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:27 ` Lars Ingebrigtsen @ 2022-04-17 18:36 ` Eli Zaretskii 2022-04-17 18:45 ` Lars Ingebrigtsen 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 18:36 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 54970, hmelman, rpluim, alan > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: Eli Zaretskii <eliz@gnu.org>, Robert Pluim <rpluim@gmail.com>, Alan > Third <alan@idiocy.org>, 54970@debbugs.gnu.org > Date: Sun, 17 Apr 2022 20:27:41 +0200 > > I haven't been following this thread closely, but has somebody mentioned > that some characters have both a symbol and an emoji expression? My > guess is that Apple, by default, displays characters like 🍽 > "fork and knife with plate" using the emoji expression. So it has a > font with a definition with the non-emoji expression which is just > blank. That's what I thought, but "C-u C-x =" says "no font was found", which AFAIU contradicts this theory. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:36 ` Eli Zaretskii @ 2022-04-17 18:45 ` Lars Ingebrigtsen 2022-04-17 18:54 ` Howard Melman 2022-04-17 18:58 ` Eli Zaretskii 0 siblings, 2 replies; 60+ messages in thread From: Lars Ingebrigtsen @ 2022-04-17 18:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970, hmelman, rpluim, alan Eli Zaretskii <eliz@gnu.org> writes: > That's what I thought, but "C-u C-x =" says "no font was found", which > AFAIU contradicts this theory. Huh, indeed. How odd. Why isn't Emacs showing tofu instead of a blank square, then? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:45 ` Lars Ingebrigtsen @ 2022-04-17 18:54 ` Howard Melman 2022-04-17 18:58 ` Eli Zaretskii 1 sibling, 0 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 18:54 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 54970, alan, rpluim > On Apr 17, 2022, at 2:45 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote: > > Eli Zaretskii <eliz@gnu.org> writes: > >> That's what I thought, but "C-u C-x =" says "no font was found", which >> AFAIU contradicts this theory. > > Huh, indeed. How odd. Why isn't Emacs showing tofu instead of a blank > square, then? FWIW the macport of Emacs 28 displays tofu for me for the book character. Below is C-u C-x = for it. The same character displays as blank in vanilla Emacs 28.1 -Q (with the same C-u C-x = output other than the hl-line property) ================== position: 1 of 3 (0%), column: 0 character: 🕮 (displayed as 🕮) (codepoint 128366, #o372556, #x1f56e) charset: unicode (Unicode (ISO10646)) code point in charset: 0x1F56E script: symbol syntax: w which means: word category: .:Base to input: type "C-x 8 RET 1f56e" or "C-x 8 RET BOOK" buffer code: #xF0 #x9F #x95 #xAE file code: #xF0 #x9F #x95 #xAE (encoded by coding system utf-8-unix) display: no font available Character code properties: customize what to show name: BOOK general-category: So (Symbol, Other) decomposition: (128366) ('🕮') There are 2 overlays here: From 1 to 3 face hl-line priority -50 window #<window 3 on *scratch*> From 1 to 1 display "" There are text properties here: fontified nil ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:45 ` Lars Ingebrigtsen 2022-04-17 18:54 ` Howard Melman @ 2022-04-17 18:58 ` Eli Zaretskii 2022-04-17 19:27 ` Alan Third 1 sibling, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 18:58 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 54970, hmelman, rpluim, alan > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: hmelman@gmail.com, rpluim@gmail.com, alan@idiocy.org, > 54970@debbugs.gnu.org > Date: Sun, 17 Apr 2022 20:45:35 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > That's what I thought, but "C-u C-x =" says "no font was found", which > > AFAIU contradicts this theory. > > Huh, indeed. How odd. Why isn't Emacs showing tofu instead of a blank > square, then? No idea. Maybe it's a macOS thing or something? ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:58 ` Eli Zaretskii @ 2022-04-17 19:27 ` Alan Third 2022-04-17 19:47 ` Alan Third 0 siblings, 1 reply; 60+ messages in thread From: Alan Third @ 2022-04-17 19:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970, hmelman, Lars Ingebrigtsen, rpluim On Sun, Apr 17, 2022 at 09:58:56PM +0300, Eli Zaretskii wrote: > > From: Lars Ingebrigtsen <larsi@gnus.org> > > Cc: hmelman@gmail.com, rpluim@gmail.com, alan@idiocy.org, > > 54970@debbugs.gnu.org > > Date: Sun, 17 Apr 2022 20:45:35 +0200 > > > > Eli Zaretskii <eliz@gnu.org> writes: > > > > > That's what I thought, but "C-u C-x =" says "no font was found", which > > > AFAIU contradicts this theory. > > > > Huh, indeed. How odd. Why isn't Emacs showing tofu instead of a blank > > square, then? > > No idea. Maybe it's a macOS thing or something? I'm pretty sure that I've never ever seen NS Emacs on macOS produce anything but a blank square (and it's always a square) for missing characters. I don't understand macfont.m, or Emacs's font handling, well enough to really know what's going on. Looking at the limited number of macOS apps I have, it looks like they all display something different, so I guess the output is application dependent. -- Alan Third ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 19:27 ` Alan Third @ 2022-04-17 19:47 ` Alan Third 2022-04-17 20:34 ` Alan Third 0 siblings, 1 reply; 60+ messages in thread From: Alan Third @ 2022-04-17 19:47 UTC (permalink / raw) To: Eli Zaretskii, Lars Ingebrigtsen, hmelman, rpluim, 54970 On Sun, Apr 17, 2022 at 08:27:45PM +0100, Alan Third wrote: > On Sun, Apr 17, 2022 at 09:58:56PM +0300, Eli Zaretskii wrote: > > No idea. Maybe it's a macOS thing or something? > > I'm pretty sure that I've never ever seen NS Emacs on macOS produce > anything but a blank square (and it's always a square) for missing > characters. Hmm, in fact, is this, from nsterm.m, the culprit? case GLYPHLESS_GLYPH: if (s->for_overlaps || (s->cmp_from > 0 && ! s->first_glyph->u.cmp.automatic)) s->background_filled_p = 1; else ns_maybe_dumpglyphs_background (s, s->first_glyph->type == COMPOSITE_GLYPH); /* ... */ /* Not yet implemented. */ /* ... */ break; -- Alan Third ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 19:47 ` Alan Third @ 2022-04-17 20:34 ` Alan Third 2022-04-17 21:05 ` Howard Melman 2022-04-18 4:29 ` Eli Zaretskii 0 siblings, 2 replies; 60+ messages in thread From: Alan Third @ 2022-04-17 20:34 UTC (permalink / raw) To: Eli Zaretskii, Lars Ingebrigtsen, hmelman, rpluim, 54970 [-- Attachment #1: Type: text/plain, Size: 1150 bytes --] On Sun, Apr 17, 2022 at 08:47:07PM +0100, Alan Third wrote: > On Sun, Apr 17, 2022 at 08:27:45PM +0100, Alan Third wrote: > > On Sun, Apr 17, 2022 at 09:58:56PM +0300, Eli Zaretskii wrote: > > > No idea. Maybe it's a macOS thing or something? > > > > I'm pretty sure that I've never ever seen NS Emacs on macOS produce > > anything but a blank square (and it's always a square) for missing > > characters. > > Hmm, in fact, is this, from nsterm.m, the culprit? > > case GLYPHLESS_GLYPH: > if (s->for_overlaps || (s->cmp_from > 0 > && ! s->first_glyph->u.cmp.automatic)) > s->background_filled_p = 1; > else > ns_maybe_dumpglyphs_background > (s, s->first_glyph->type == COMPOSITE_GLYPH); > /* ... */ > /* Not yet implemented. */ > /* ... */ > break; To answer my own question: yes. Yes it is. Patch attached. It doesn't look to me like it displays quite right, the right hand side of the hex code gets cut off on my Mac and under GNUstep only the first line is displayed, but I can't see any reason for it. Maybe this is better than nothing, though. -- Alan Third [-- Attachment #2: 0001-Fix-glyphless-glyph-display-on-NS-bug-54970.patch --] [-- Type: text/x-diff, Size: 3570 bytes --] From a3f75f63fed67e4a63eb1412d910c9e66c4cc2b8 Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Sun, 17 Apr 2022 21:15:05 +0100 Subject: [PATCH] Fix glyphless glyph display on NS (bug#54970) * src/nsterm.m (ns_draw_glyphless_glyph_string_foreground): New function. (ns_draw_glyph_string): Use the new function. --- src/nsterm.m | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 76 insertions(+), 3 deletions(-) diff --git a/src/nsterm.m b/src/nsterm.m index 550f29212e..18e219949b 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -3945,6 +3945,81 @@ Function modeled after x_draw_glyph_string_box (). } } +/* Draw the foreground of glyph string S for glyphless characters. */ +static void +ns_draw_glyphless_glyph_string_foreground (struct glyph_string *s) +{ + struct glyph *glyph = s->first_glyph; + unsigned char2b[8]; + int x, i, j; + + /* If first glyph of S has a left box line, start drawing the text + of S to the right of that box line. */ + if (s->face && s->face->box != FACE_NO_BOX + && s->first_glyph->left_box_line_p) + x = s->x + max (s->face->box_vertical_line_width, 0); + else + x = s->x; + + s->char2b = char2b; + + for (i = 0; i < s->nchars; i++, glyph++) + { + char buf[7]; + char *str = NULL; + int len = glyph->u.glyphless.len; + + if (glyph->u.glyphless.method == GLYPHLESS_DISPLAY_ACRONYM) + { + if (len > 0 + && CHAR_TABLE_P (Vglyphless_char_display) + && (CHAR_TABLE_EXTRA_SLOTS (XCHAR_TABLE (Vglyphless_char_display)) + >= 1)) + { + Lisp_Object acronym + = (! glyph->u.glyphless.for_no_font + ? CHAR_TABLE_REF (Vglyphless_char_display, + glyph->u.glyphless.ch) + : XCHAR_TABLE (Vglyphless_char_display)->extras[0]); + if (STRINGP (acronym)) + str = SSDATA (acronym); + } + } + else if (glyph->u.glyphless.method == GLYPHLESS_DISPLAY_HEX_CODE) + { + unsigned int ch = glyph->u.glyphless.ch; + eassume (ch <= MAX_CHAR); + sprintf (buf, "%0*X", ch < 0x10000 ? 4 : 6, ch); + str = buf; + } + + if (str) + { + int upper_len = (len + 1) / 2; + + /* It is assured that all LEN characters in STR is ASCII. */ + for (j = 0; j < len; j++) + char2b[j] = s->font->driver->encode_char (s->font, str[j]) & 0xFFFF; + s->font->driver->draw (s, 0, upper_len, + x + glyph->slice.glyphless.upper_xoff, + s->ybase + glyph->slice.glyphless.upper_yoff, + false); + s->font->driver->draw (s, upper_len, len, + x + glyph->slice.glyphless.lower_xoff, + s->ybase + glyph->slice.glyphless.lower_yoff, + false); + } + if (glyph->u.glyphless.method != GLYPHLESS_DISPLAY_THIN_SPACE) + ns_draw_box (NSMakeRect (x, s->ybase - glyph->ascent, + glyph->pixel_width - 1, + glyph->ascent + glyph->descent - 1), + 1, 1, + [NSColor colorWithUnsignedLong:NS_FACE_FOREGROUND (s->face)], + YES, YES); + x += glyph->pixel_width; + } +} + static void ns_draw_glyph_string (struct glyph_string *s) /* -------------------------------------------------------------------------- @@ -4058,9 +4133,7 @@ Function modeled after x_draw_glyph_string_box (). else ns_maybe_dumpglyphs_background (s, s->first_glyph->type == COMPOSITE_GLYPH); - /* ... */ - /* Not yet implemented. */ - /* ... */ + ns_draw_glyphless_glyph_string_foreground (s); break; default: -- 2.35.1 ^ permalink raw reply related [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 20:34 ` Alan Third @ 2022-04-17 21:05 ` Howard Melman 2022-04-18 4:29 ` Eli Zaretskii 1 sibling, 0 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 21:05 UTC (permalink / raw) To: Alan Third; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim > On Apr 17, 2022, at 4:34 PM, Alan Third <alan@idiocy.org> wrote: > > Patch attached. Glad there's progress, but I don't build my own emacs so I can't apply this patch to test it. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 20:34 ` Alan Third 2022-04-17 21:05 ` Howard Melman @ 2022-04-18 4:29 ` Eli Zaretskii 2022-04-18 13:19 ` Alan Third 1 sibling, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-18 4:29 UTC (permalink / raw) To: Alan Third; +Cc: 54970, hmelman, larsi, rpluim > Date: Sun, 17 Apr 2022 21:34:52 +0100 > From: Alan Third <alan@idiocy.org> > > > case GLYPHLESS_GLYPH: > > if (s->for_overlaps || (s->cmp_from > 0 > > && ! s->first_glyph->u.cmp.automatic)) > > s->background_filled_p = 1; > > else > > ns_maybe_dumpglyphs_background > > (s, s->first_glyph->type == COMPOSITE_GLYPH); > > /* ... */ > > /* Not yet implemented. */ > > /* ... */ > > break; > > To answer my own question: yes. Yes it is. > > Patch attached. > > It doesn't look to me like it displays quite right, the right hand > side of the hex code gets cut off on my Mac and under GNUstep only the > first line is displayed, but I can't see any reason for it. Can you show screenshots? I'm not sure I understand the description of the display problems that this code yields. The font used for the hex code should be a smaller one, and that is determined elsewhere in the display code, so maybe that part also needs some fix in the NS build? Thanks. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-18 4:29 ` Eli Zaretskii @ 2022-04-18 13:19 ` Alan Third 2022-04-18 14:23 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Alan Third @ 2022-04-18 13:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970, hmelman, larsi, rpluim [-- Attachment #1: Type: text/plain, Size: 1678 bytes --] On Mon, Apr 18, 2022 at 07:29:00AM +0300, Eli Zaretskii wrote: > > Date: Sun, 17 Apr 2022 21:34:52 +0100 > > From: Alan Third <alan@idiocy.org> > > > > > case GLYPHLESS_GLYPH: > > > if (s->for_overlaps || (s->cmp_from > 0 > > > && ! s->first_glyph->u.cmp.automatic)) > > > s->background_filled_p = 1; > > > else > > > ns_maybe_dumpglyphs_background > > > (s, s->first_glyph->type == COMPOSITE_GLYPH); > > > /* ... */ > > > /* Not yet implemented. */ > > > /* ... */ > > > break; > > > > To answer my own question: yes. Yes it is. > > > > Patch attached. > > > > It doesn't look to me like it displays quite right, the right hand > > side of the hex code gets cut off on my Mac and under GNUstep only the > > first line is displayed, but I can't see any reason for it. > > Can you show screenshots? I'm not sure I understand the description > of the display problems that this code yields. > > The font used for the hex code should be a smaller one, and that is > determined elsewhere in the display code, so maybe that part also > needs some fix in the NS build? I've changed my mind about on the Mac. The hex code isn't centred, but it is readable. I found a couple of bugs in nsfont.m, which is the GNUstep font backend, and now the only problem is that the upper and lower text are drawn in almost the same location. I suspect some error in how the font backend is calculating the ascent and descent or something. I don't see what's wrong, though. Screenshot for GNUstep attached. In this example upper_yoff and lower_yoff are -14 and -13, respectively. Po Lu, any ideas? -- Alan Third [-- Attachment #2: 10FFFF.png --] [-- Type: image/png, Size: 1167 bytes --] [-- Attachment #3: v2-0001-Fix-glyphless-glyph-display-on-NS-bug-54970.patch --] [-- Type: text/x-diff, Size: 4598 bytes --] From e2c482042bf45a3f7b924b0f298876d84576df1d Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Sun, 17 Apr 2022 21:15:05 +0100 Subject: [PATCH v2] Fix glyphless glyph display on NS (bug#54970) * src/nsterm.m (ns_draw_glyphless_glyph_string_foreground): New function. (ns_draw_glyph_string): Use the new function. * src/nsfont.m (nsfont_draw): Fix the location the glyphs are drawn, and also which glyphs are drawn. --- src/nsfont.m | 10 +++---- src/nsterm.m | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 80 insertions(+), 9 deletions(-) diff --git a/src/nsfont.m b/src/nsfont.m index f3c8a82930..6915fd217d 100644 --- a/src/nsfont.m +++ b/src/nsfont.m @@ -1176,15 +1176,15 @@ is false when (FROM > 0 || TO < S->nchars). */ face = s->face; - r.origin.x = s->x; + r.origin.x = x; if (s->face->box != FACE_NO_BOX && s->first_glyph->left_box_line_p) r.origin.x += max (s->face->box_vertical_line_width, 0); - r.origin.y = s->y; + r.origin.y = y; r.size.height = FONT_HEIGHT (font); - for (int i = from; i < to; ++i) - c[i] = s->char2b[i]; + for (int i = 0; i < len; ++i) + c[i] = s->char2b[i + from]; /* Fill background if requested. */ if (with_background && !isComposite) @@ -1210,8 +1210,6 @@ is false when (FROM > 0 || TO < S->nchars). */ } /* set up for character rendering */ - r.origin.y = y; - if (s->hl == DRAW_CURSOR) col = FRAME_BACKGROUND_COLOR (s->f); else diff --git a/src/nsterm.m b/src/nsterm.m index 550f29212e..5a6a4d663b 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -3945,6 +3945,81 @@ Function modeled after x_draw_glyph_string_box (). } } +/* Draw the foreground of glyph string S for glyphless characters. */ +static void +ns_draw_glyphless_glyph_string_foreground (struct glyph_string *s) +{ + struct glyph *glyph = s->first_glyph; + NSGlyph char2b[8]; + int x, i, j; + + /* If first glyph of S has a left box line, start drawing the text + of S to the right of that box line. */ + if (s->face && s->face->box != FACE_NO_BOX + && s->first_glyph->left_box_line_p) + x = s->x + max (s->face->box_vertical_line_width, 0); + else + x = s->x; + + s->char2b = char2b; + + for (i = 0; i < s->nchars; i++, glyph++) + { + char buf[7]; + char *str = NULL; + int len = glyph->u.glyphless.len; + + if (glyph->u.glyphless.method == GLYPHLESS_DISPLAY_ACRONYM) + { + if (len > 0 + && CHAR_TABLE_P (Vglyphless_char_display) + && (CHAR_TABLE_EXTRA_SLOTS (XCHAR_TABLE (Vglyphless_char_display)) + >= 1)) + { + Lisp_Object acronym + = (! glyph->u.glyphless.for_no_font + ? CHAR_TABLE_REF (Vglyphless_char_display, + glyph->u.glyphless.ch) + : XCHAR_TABLE (Vglyphless_char_display)->extras[0]); + if (STRINGP (acronym)) + str = SSDATA (acronym); + } + } + else if (glyph->u.glyphless.method == GLYPHLESS_DISPLAY_HEX_CODE) + { + unsigned int ch = glyph->u.glyphless.ch; + eassume (ch <= MAX_CHAR); + sprintf (buf, "%0*X", ch < 0x10000 ? 4 : 6, ch); + str = buf; + } + + if (str) + { + int upper_len = (len + 1) / 2; + + /* It is assured that all LEN characters in STR is ASCII. */ + for (j = 0; j < len; j++) + char2b[j] = s->font->driver->encode_char (s->font, str[j]) & 0xFFFF; + s->font->driver->draw (s, 0, upper_len, + x + glyph->slice.glyphless.upper_xoff, + s->ybase + glyph->slice.glyphless.upper_yoff, + false); + s->font->driver->draw (s, upper_len, len, + x + glyph->slice.glyphless.lower_xoff, + s->ybase + glyph->slice.glyphless.lower_yoff, + false); + } + if (glyph->u.glyphless.method != GLYPHLESS_DISPLAY_THIN_SPACE) + ns_draw_box (NSMakeRect (x, s->ybase - glyph->ascent, + glyph->pixel_width - 1, + glyph->ascent + glyph->descent - 1), + 1, 1, + [NSColor colorWithUnsignedLong:NS_FACE_FOREGROUND (s->face)], + YES, YES); + x += glyph->pixel_width; + } +} + static void ns_draw_glyph_string (struct glyph_string *s) /* -------------------------------------------------------------------------- @@ -4058,9 +4133,7 @@ Function modeled after x_draw_glyph_string_box (). else ns_maybe_dumpglyphs_background (s, s->first_glyph->type == COMPOSITE_GLYPH); - /* ... */ - /* Not yet implemented. */ - /* ... */ + ns_draw_glyphless_glyph_string_foreground (s); break; default: -- 2.35.1 ^ permalink raw reply related [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-18 13:19 ` Alan Third @ 2022-04-18 14:23 ` Eli Zaretskii 2022-04-18 19:28 ` Alan Third 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-18 14:23 UTC (permalink / raw) To: Alan Third; +Cc: 54970, hmelman, larsi, rpluim > Date: Mon, 18 Apr 2022 14:19:24 +0100 > From: Alan Third <alan@idiocy.org> > Cc: larsi@gnus.org, hmelman@gmail.com, rpluim@gmail.com, > 54970@debbugs.gnu.org > > I've changed my mind about on the Mac. The hex code isn't centred, but > it is readable. > > I found a couple of bugs in nsfont.m, which is the GNUstep font > backend, and now the only problem is that the upper and lower text are > drawn in almost the same location. I suspect some error in how the > font backend is calculating the ascent and descent or something. I > don't see what's wrong, though. > > Screenshot for GNUstep attached. In this example upper_yoff and > lower_yoff are -14 and -13, respectively. If the y offsets are wrong, you should step through produce_glyphless_glyph, where they are calculated. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-18 14:23 ` Eli Zaretskii @ 2022-04-18 19:28 ` Alan Third 2022-04-19 1:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 60+ messages in thread From: Alan Third @ 2022-04-18 19:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 54970, hmelman, larsi, rpluim On Mon, Apr 18, 2022 at 05:23:49PM +0300, Eli Zaretskii wrote: > > Date: Mon, 18 Apr 2022 14:19:24 +0100 > > From: Alan Third <alan@idiocy.org> > > Cc: larsi@gnus.org, hmelman@gmail.com, rpluim@gmail.com, > > 54970@debbugs.gnu.org > > > > I've changed my mind about on the Mac. The hex code isn't centred, but > > it is readable. > > > > I found a couple of bugs in nsfont.m, which is the GNUstep font > > backend, and now the only problem is that the upper and lower text are > > drawn in almost the same location. I suspect some error in how the > > font backend is calculating the ascent and descent or something. I > > don't see what's wrong, though. > > > > Screenshot for GNUstep attached. In this example upper_yoff and > > lower_yoff are -14 and -13, respectively. > > If the y offsets are wrong, you should step through > produce_glyphless_glyph, where they are calculated. It turns out that ascent and descent were reversed. This is one of the biggest problems with the GNUstep port, the ns font backend was broken even when it was merged in and it's only got further out of step as time has passed. No wonder the decision was made, however long ago, to get rid of it on macOS. Pushed to master. -- Alan Third ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-18 19:28 ` Alan Third @ 2022-04-19 1:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-04-19 3:51 ` Alan Third 0 siblings, 1 reply; 60+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-19 1:04 UTC (permalink / raw) To: Alan Third; +Cc: 54970, Eli Zaretskii, hmelman, larsi, rpluim Alan Third <alan@idiocy.org> writes: > It turns out that ascent and descent were reversed. I thought I fixed all of those last year, but clearly I was wrong. Thanks for catching that bug. > This is one of the biggest problems with the GNUstep port, the ns font > backend was broken even when it was merged in and it's only got > further out of step as time has passed. Well, I tried my best. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-19 1:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-19 3:51 ` Alan Third 0 siblings, 0 replies; 60+ messages in thread From: Alan Third @ 2022-04-19 3:51 UTC (permalink / raw) To: Po Lu; +Cc: larsi, 54970, hmelman, rpluim On Tue, Apr 19, 2022 at 09:04:51AM +0800, Po Lu wrote: > Alan Third <alan@idiocy.org> writes: > > > It turns out that ascent and descent were reversed. > > I thought I fixed all of those last year, but clearly I was wrong. > Thanks for catching that bug. I also fixed two other bugs I found. I think there are just so many small mistakes right through it that we'll never find them all. > > This is one of the biggest problems with the GNUstep port, the ns font > > backend was broken even when it was merged in and it's only got > > further out of step as time has passed. > > Well, I tried my best. Definitely not your fault! It's much better than it was just a year ago. -- Alan Third ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:09 ` Howard Melman 2022-04-17 18:27 ` Lars Ingebrigtsen @ 2022-04-17 18:34 ` Eli Zaretskii 2022-04-17 18:46 ` Howard Melman 1 sibling, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 18:34 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 14:09:25 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > I'm reading a lot about unicode and fontsets and trying to wrap > my head around it. I can't quite answer this yet, the font to display > U+1F37D is Apple Color Emoji. I get that emacs might not want > to enable that font by default, but emacs does use it by default to show > some emoji, though I don't see it listed when I do M-x describe-fontset. The question is why didn't Emacs find that font when asked to display U+1F37D, and why did that produce the "blank" display instead of the expected tofu. > > Okay, try with codepoints between D800 and DB7F: what does that produce? > > I'm sorry I don't follow what you want me to do, can you be more specific? "C-x 8 RET d800 RET" and tell what you get. ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:34 ` Eli Zaretskii @ 2022-04-17 18:46 ` Howard Melman 2022-04-17 19:00 ` Eli Zaretskii 0 siblings, 1 reply; 60+ messages in thread From: Howard Melman @ 2022-04-17 18:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third [-- Attachment #1: Type: text/plain, Size: 1089 bytes --] > On Apr 17, 2022, at 2:34 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Howard Melman <hmelman@gmail.com> >> Date: Sun, 17 Apr 2022 14:09:25 -0400 >> Cc: Robert Pluim <rpluim@gmail.com>, >> Alan Third <alan@idiocy.org>, >> Lars Ingebrigtsen <larsi@gnus.org>, >> 54970@debbugs.gnu.org >> >> I'm reading a lot about unicode and fontsets and trying to wrap >> my head around it. I can't quite answer this yet, the font to display >> U+1F37D is Apple Color Emoji. I get that emacs might not want >> to enable that font by default, but emacs does use it by default to show >> some emoji, though I don't see it listed when I do M-x describe-fontset. > > The question is why didn't Emacs find that font when asked to display > U+1F37D, and why did that produce the "blank" display instead of the > expected tofu. > >>> Okay, try with codepoints between D800 and DB7F: what does that produce? >> >> I'm sorry I don't follow what you want me to do, can you be more specific? > > "C-x 8 RET d800 RET" and tell what you get. Sorry, same thing. db7f is the same as well. Hoawrd [-- Attachment #2.1: Type: text/html, Size: 2284 bytes --] [-- Attachment #2.2: Screen Shot 2022-04-17 at 2.45.29 PM.png --] [-- Type: image/png, Size: 11158 bytes --] ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 18:46 ` Howard Melman @ 2022-04-17 19:00 ` Eli Zaretskii 2022-04-17 19:47 ` Howard Melman 0 siblings, 1 reply; 60+ messages in thread From: Eli Zaretskii @ 2022-04-17 19:00 UTC (permalink / raw) To: Howard Melman; +Cc: larsi, 54970, rpluim, alan > From: Howard Melman <hmelman@gmail.com> > Date: Sun, 17 Apr 2022 14:46:25 -0400 > Cc: Robert Pluim <rpluim@gmail.com>, > Alan Third <alan@idiocy.org>, > Lars Ingebrigtsen <larsi@gnus.org>, > 54970@debbugs.gnu.org > > > "C-x 8 RET d800 RET" and tell what you get. > > > > Sorry, same thing. db7f is the same as well. And if you customize glyphless-char-display-control to something non-default, does it affect how these codepoints are displayed? ^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#54970: 28.1; Some emoji no longer display 2022-04-17 19:00 ` Eli Zaretskii @ 2022-04-17 19:47 ` Howard Melman 0 siblings, 0 replies; 60+ messages in thread From: Howard Melman @ 2022-04-17 19:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 54970, Robert Pluim, Alan Third On Apr 17, 2022, at 3:00 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > And if you customize glyphless-char-display-control to something > non-default, does it affect how these codepoints are displayed? It does not seem to. I put the BOOK character in *scratch* and opened customize-option for glyphless-char-display-control and changed the no-font option several times using Set For Current Session and didn't see the character in *scratch* change at all. Howard ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2022-04-23 19:12 UTC | newest] Thread overview: 60+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-04-16 13:07 bug#54970: 28.1; Some emoji no longer display Howard Melman 2022-04-16 14:18 ` Lars Ingebrigtsen 2022-04-16 14:55 ` Lars Ingebrigtsen 2022-04-16 15:27 ` Howard Melman 2022-04-16 16:02 ` Alan Third 2022-04-16 16:21 ` Howard Melman 2022-04-16 16:42 ` Eli Zaretskii 2022-04-16 17:17 ` Howard Melman 2022-04-16 18:26 ` Eli Zaretskii 2022-04-16 19:19 ` Howard Melman 2022-04-16 19:22 ` Eli Zaretskii 2022-04-16 20:07 ` Howard Melman 2022-04-17 5:53 ` Eli Zaretskii 2022-04-17 13:34 ` Robert Pluim 2022-04-17 14:35 ` Howard Melman 2022-04-17 15:14 ` Robert Pluim 2022-04-17 18:44 ` Howard Melman 2022-04-17 18:49 ` Lars Ingebrigtsen 2022-04-17 18:56 ` Howard Melman 2022-04-17 18:58 ` Eli Zaretskii 2022-04-17 19:40 ` Howard Melman 2022-04-17 22:03 ` Howard Melman 2022-04-18 5:12 ` Eli Zaretskii [not found] ` <0AC9BAB0-35AA-4088-BEEB-66D5B0459FC2@gmail.com> 2022-04-18 13:19 ` Howard Melman 2022-04-22 21:56 ` Howard Melman 2022-04-23 7:51 ` Eli Zaretskii 2022-04-23 16:35 ` Howard Melman 2022-04-23 16:58 ` Eli Zaretskii 2022-04-23 17:22 ` Howard Melman 2022-04-23 17:46 ` Eli Zaretskii 2022-04-23 19:12 ` Howard Melman 2022-04-23 9:46 ` Eli Zaretskii 2022-04-17 14:35 ` Howard Melman 2022-04-17 14:44 ` Eli Zaretskii 2022-04-17 14:50 ` Howard Melman 2022-04-17 15:50 ` Eli Zaretskii 2022-04-17 15:54 ` Howard Melman 2022-04-17 16:17 ` Eli Zaretskii 2022-04-17 16:48 ` Howard Melman 2022-04-17 18:00 ` Eli Zaretskii 2022-04-17 18:09 ` Howard Melman 2022-04-17 18:27 ` Lars Ingebrigtsen 2022-04-17 18:36 ` Eli Zaretskii 2022-04-17 18:45 ` Lars Ingebrigtsen 2022-04-17 18:54 ` Howard Melman 2022-04-17 18:58 ` Eli Zaretskii 2022-04-17 19:27 ` Alan Third 2022-04-17 19:47 ` Alan Third 2022-04-17 20:34 ` Alan Third 2022-04-17 21:05 ` Howard Melman 2022-04-18 4:29 ` Eli Zaretskii 2022-04-18 13:19 ` Alan Third 2022-04-18 14:23 ` Eli Zaretskii 2022-04-18 19:28 ` Alan Third 2022-04-19 1:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-04-19 3:51 ` Alan Third 2022-04-17 18:34 ` Eli Zaretskii 2022-04-17 18:46 ` Howard Melman 2022-04-17 19:00 ` Eli Zaretskii 2022-04-17 19:47 ` Howard Melman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.