* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces @ 2024-10-11 16:18 xuan 2024-10-12 8:02 ` Eli Zaretskii 2024-10-29 23:14 ` Tim Ruffing 0 siblings, 2 replies; 90+ messages in thread From: xuan @ 2024-10-11 16:18 UTC (permalink / raw) To: 73752 [-- Attachment #1: Type: text/plain, Size: 5970 bytes --] Setup: 1. install `ligature.el` from melpa. 2. start `emacs -Q` and execute the attached script or simply use the attached script as the `init.el`. 3. open the attached `init.el` file and execute `init-faces` or hit "C-#" to start randomizing the font faces, 4. eventually you will see some characters gets rendered with extra spaces (sample screenshots provided below), hit "C-!" to stop the randomization, 5. hitting "C-return" will randomize font once, which might be useful for you find debug, Expected behavior: the fonts are rendered consistently without extra spacing, Observed behavior: the fonts are rendered with extra spacing randomly, Related information: I previously reported this bug here: https://github.com/mickeynp/ligature.el/issues/56. In GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.0) of 2024-07-16 built on 27527c2e06f843c0962737354e0b3cf7 System Description: Fedora Linux 40 (Sway) Configured using: 'configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-cairo --with-dbus --with-gif --with-gpm=no --with-harfbuzz --with-jpeg --with-json --with-modules --with-native-compilation=aot --with-pgtk --with-png --with-rsvg --with-sqlite3 --with-tiff --with-tree-sitter --with-webp --with-xpm --with-xwidgets build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' LDFLAGS=-Wl,-z,relro PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig CXX=g++ 'CXXFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: ELisp/l Minor modes in effect: global-ligature-mode: t ligature-mode: t 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 line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr warnings icons rx ligature cl-extra help-mode use-package-core ligature-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd 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 nadvice seq simple cl-generic indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads xwidget-internal dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo gtk pgtk multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 108675 14724) (symbols 48 8830 0) (strings 32 27784 2658) (string-bytes 1 906120) (vectors 16 22224) (vector-slots 8 441624 17378) (floats 8 45 30) (intervals 56 736 1) (buffers 984 12)) [-- Attachment #2.1: Type: text/html, Size: 748 bytes --] [-- Attachment #2.2: 83k2iR0RkF0vUnlj.png --] [-- Type: image/png, Size: 5035 bytes --] [-- Attachment #2.3: Type: text/html, Size: 189 bytes --] [-- Attachment #2.4: vj0A4vBxR2UgLHU2.png --] [-- Type: image/png, Size: 1199 bytes --] [-- Attachment #2.5: Type: text/html, Size: 189 bytes --] [-- Attachment #2.6: dknFd3G9YDiGAGQ9.png --] [-- Type: image/png, Size: 1323 bytes --] [-- Attachment #2.7: Type: text/html, Size: 189 bytes --] [-- Attachment #2.8: uM000GtbhXhDurze.png --] [-- Type: image/png, Size: 1330 bytes --] [-- Attachment #2.9: Type: text/html, Size: 6959 bytes --] [-- Attachment #2.10: init.el --] [-- Type: application/octet-stream, Size: 3667 bytes --] ;; -*- lexical-binding: t; -*- (setq inhibit-startup-screen t) ;; starting font (setq default-font (font-spec :family "JetBrains Mono" :size 16 :weight 'regular)) (set-face-attribute 'default nil :width 'normal :weight 'normal :slant 'normal :font default-font) (use-package ligature :config (ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!=" "=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!" "??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>" "<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####" "#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$" "$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--" "-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>" "==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|" "<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~" "~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||" "|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::=" ":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???" "<:<" ";;;")) (global-ligature-mode t)) ;; ("\\\"o" ?ö) ;; ("^^+" ?⁺) ("__+" ?₊) ("^^-" ?⁻) ;; ("__0" ?₀) ("__1" ?₁) ("__2" ?₂) ("__3" ?₃) ("__4" ?₄) ;; ("__5" ?₅) ("__6" ?₆) ("__7" ?₇) ("__8" ?₈) ("__9" ?₉) ;; ("__a" ?ₐ) ("__e" ?ₑ) ("__h" ?ₕ) ("__i" ?ᵢ) ("__k" ?ₖ) ;; ("__l" ?ₗ) ("__m" ?ₘ) ("__n" ?ₙ) ("__o" ?ₒ) ("__p" ?ₚ) ;; ("__r" ?ᵣ) ("__s" ?ₛ) ("__t" ?ₜ) ("__u" ?ᵤ) ("__v" ?ᵥ) ("__x" ?ₓ)) (setq faces '((face1 . "--") (face2 . "__") (face3 . "=:=") (face4 . "??") (face5 . "<<") (face6 . "#{") (face7 . "$>") (face8 . "-->") (face9 . "==>") (face10 . "<=|") (face11 . "~@") (face12 . "||>") (face13 . "<:<"))) (defun init-faces () (interactive) (dolist (face faces) (make-face (car face)) (highlight-lines-matching-regexp (cdr face) (car face)) (run-at-time nil 1 #'random-faces))) (defun random-from-list (l) (nth (random (length l)) l)) (defun random-face (face) (interactive) (let* ((weight (random-from-list '(light normal medium bold))) (slant (random-from-list '(normal italic))) (height (random-from-list '(120 125 115 110 130))) ) (set-face-attribute face nil :weight weight :slant slant :height height))) (defun random-faces () (interactive) (dolist (face faces) (random-face (car face)))) (global-set-key (kbd "C-#") #'init-faces) (global-set-key (kbd "C-!") (lambda () (interactive) (cancel-function-timers #'random-faces))) (global-set-key (kbd "<C-return>") #'random-faces) (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(package-selected-packages '(ligature))) (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ) [-- Attachment #2.11: Type: text/html, Size: 162 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-11 16:18 bug#73752: 29.4; Ligatures are randomly rendered with extra spaces xuan @ 2024-10-12 8:02 ` Eli Zaretskii 2024-10-12 16:09 ` Yixuan Chen 2024-10-29 23:14 ` Tim Ruffing 1 sibling, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-12 8:02 UTC (permalink / raw) To: xuan; +Cc: 73752 > From: xuan@xlk.me > Date: Fri, 11 Oct 2024 12:18:57 -0400 > > Setup: > > 1. install `ligature.el` from melpa. > > 2. start `emacs -Q` and execute the attached script or simply use the attached script as the `init.el`. > > 3. open the attached `init.el` file and execute `init-faces` or hit "C-#" to start randomizing the font faces, > > 4. eventually you will see some characters gets rendered with extra spaces (sample screenshots provided below), hit "C-!" to stop the randomization, > > 5. hitting "C-return" will randomize font once, which might be useful for you find debug, I cannot reproduce the problem on my system. I've let Emacs randomize the fonts for quite some time, and everything keeps rendering correctly without the extra spaces. When you say "eventually", how long do you typically wait until the problem appears? (As two deviations from your init.el, I used a different font (Cascadia Code), since I don't have JetBrains Mono installed; and I replaces use-package with the equivalent Lisp, since I don't want to install ligatures.el on this system. I don't think these two deviations should matter, but I mention them FTR.) I think this might be system-dependent. Can someone try this in a Cairo build on GNU/Linux and see if the problem reproduces? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-12 8:02 ` Eli Zaretskii @ 2024-10-12 16:09 ` Yixuan Chen 2024-10-27 10:21 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-12 16:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 73752 On 10/12/24 04:02, Eli Zaretskii wrote: > I cannot reproduce the problem on my system. I've let Emacs randomize > the fonts for quite some time, and everything keeps rendering > correctly without the extra spaces. When you say "eventually", how > long do you typically wait until the problem appears? It took me 5 seconds at most, and usually happened immediately. > (As two deviations from your init.el, I used a different font > (Cascadia Code), since I don't have JetBrains Mono installed; and I > replaces use-package with the equivalent Lisp, since I don't want to > install ligatures.el on this system. I don't think these two > deviations should matter, but I mention them FTR.) I can replicate the same problem (and even worse in some cases) using Cascadia Code. The `use-package` should be replaceable, except you want to keep the list of ligature strings formatted in the same way. I'm not fluent in Elisp or emacs API, so my dumb way of randomization is achieved through regexp matching over the ligature strings. If they are re-organized in some way (say merged into one huge line), it might break the randomization. > I think this might be system-dependent. Can someone try this in a > Cairo build on GNU/Linux and see if the problem reproduces? Potentially, I'm using emacs-pgtk on wayland. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-12 16:09 ` Yixuan Chen @ 2024-10-27 10:21 ` Eli Zaretskii 2024-10-27 16:19 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 10:21 UTC (permalink / raw) To: Yixuan Chen, Po Lu; +Cc: 73752 Ping! Unless someone can debug this, I'm going to close this bug as unreproducible. > Date: Sat, 12 Oct 2024 12:09:02 -0400 > Cc: 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > On 10/12/24 04:02, Eli Zaretskii wrote: > > I cannot reproduce the problem on my system. I've let Emacs randomize > > the fonts for quite some time, and everything keeps rendering > > correctly without the extra spaces. When you say "eventually", how > > long do you typically wait until the problem appears? > > It took me 5 seconds at most, and usually happened immediately. > > > (As two deviations from your init.el, I used a different font > > (Cascadia Code), since I don't have JetBrains Mono installed; and I > > replaces use-package with the equivalent Lisp, since I don't want to > > install ligatures.el on this system. I don't think these two > > deviations should matter, but I mention them FTR.) > > I can replicate the same problem (and even worse in some cases) using > Cascadia Code. > > The `use-package` should be replaceable, except you want to keep the > list of ligature strings formatted in the same way. I'm not fluent in > Elisp or emacs API, so my dumb way of randomization is achieved through > regexp matching over the ligature strings. If they are re-organized in > some way (say merged into one huge line), it might break the randomization. > > > I think this might be system-dependent. Can someone try this in a > > Cairo build on GNU/Linux and see if the problem reproduces? > > Potentially, I'm using emacs-pgtk on wayland. > ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 10:21 ` Eli Zaretskii @ 2024-10-27 16:19 ` Visuwesh 2024-10-27 17:19 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-10-27 16:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, 73752, Yixuan Chen [-- Attachment #1: Type: text/plain, Size: 1145 bytes --] [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote: > Ping! Unless someone can debug this, I'm going to close this bug as > unreproducible. I can reproduce this with Cascadia Code but it took a lot more than "5 seconds." I see no extra spaces but I see misalignment, it is not as bad as it was reported in https://github.com/mickeynp/ligature.el/issues/56 by others. I tried it with JetBrains Mono but failed to reproduce. I have a suspicion that it might be related to bug#54646 where I face(d) a similar issue with Tamil text. FWIW, I experienced a similar misalignment (exactly) once with Julia Mono for the sequence LATIN SMALL LETTER A (a) + COMBINING CIRCUMFLEX ACCENT where the accent was a little off to the side. Since I run Emacs as a daemon, closing all GUI frames and opening a fresh new one made the misalignment go away. I am attaching two images "good.png" and "misaligned.png" to illustrate the issue. [ I hope the images aren't too big. ] In the "misaligned" Emacs instance, some combination of font weight+size+slant do not exhibit the misalignment. [-- Attachment #2: misaligned.png --] [-- Type: image/png, Size: 104838 bytes --] [-- Attachment #3: good.png --] [-- Type: image/png, Size: 105566 bytes --] [-- Attachment #4: Type: text/plain, Size: 2471 bytes --] M-x report-emacs-bug RET reports: In GNU Emacs 31.0.50 (build 15, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.0, Xaw scroll bars) of 2024-10-17 built on astatine Repository revision: fada04cfc788a486265c9da6636611986b48ae49 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101011 System Description: Debian GNU/Linux trixie/sid Configured using: 'configure --with-sound=alsa --with-x-toolkit=lucid --without-xaw3d --without-gconf --without-libsystemd --with-cairo CFLAGS=-g3' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LC_MONETARY: ta_IN.UTF-8 value of $LC_NUMERIC: ta_IN.UTF-8 value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix >> Date: Sat, 12 Oct 2024 12:09:02 -0400 >> Cc: 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >> On 10/12/24 04:02, Eli Zaretskii wrote: >> > I cannot reproduce the problem on my system. I've let Emacs randomize >> > the fonts for quite some time, and everything keeps rendering >> > correctly without the extra spaces. When you say "eventually", how >> > long do you typically wait until the problem appears? >> >> It took me 5 seconds at most, and usually happened immediately. >> >> > (As two deviations from your init.el, I used a different font >> > (Cascadia Code), since I don't have JetBrains Mono installed; and I >> > replaces use-package with the equivalent Lisp, since I don't want to >> > install ligatures.el on this system. I don't think these two >> > deviations should matter, but I mention them FTR.) >> >> I can replicate the same problem (and even worse in some cases) using >> Cascadia Code. >> >> The `use-package` should be replaceable, except you want to keep the >> list of ligature strings formatted in the same way. I'm not fluent in >> Elisp or emacs API, so my dumb way of randomization is achieved through >> regexp matching over the ligature strings. If they are re-organized in >> some way (say merged into one huge line), it might break the randomization. >> >> > I think this might be system-dependent. Can someone try this in a >> > Cairo build on GNU/Linux and see if the problem reproduces? >> >> Potentially, I'm using emacs-pgtk on wayland. >> ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 16:19 ` Visuwesh @ 2024-10-27 17:19 ` Eli Zaretskii 2024-10-27 17:27 ` Eli Zaretskii 2024-10-27 17:29 ` Yixuan Chen 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 17:19 UTC (permalink / raw) To: Visuwesh; +Cc: luangruo, 73752, xuan > From: Visuwesh <visuweshm@gmail.com> > Cc: Yixuan Chen <xuan@xlk.me>, Po Lu <luangruo@yahoo.com>, > 73752@debbugs.gnu.org > Date: Sun, 27 Oct 2024 21:49:32 +0530 > > [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote: > > > Ping! Unless someone can debug this, I'm going to close this bug as > > unreproducible. > > I can reproduce this with Cascadia Code but it took a lot more than "5 > seconds." I see no extra spaces but I see misalignment, it is not as > bad as it was reported in > > https://github.com/mickeynp/ligature.el/issues/56 > > by others. I tried it with JetBrains Mono but failed to reproduce. I > have a suspicion that it might be related to bug#54646 where I face(d) a > similar issue with Tamil text. FWIW, I experienced a similar > misalignment (exactly) once with Julia Mono for the sequence > > LATIN SMALL LETTER A (a) + COMBINING CIRCUMFLEX ACCENT > > where the accent was a little off to the side. Since I run Emacs as a > daemon, closing all GUI frames and opening a fresh new one made the > misalignment go away. > > I am attaching two images "good.png" and "misaligned.png" to illustrate > the issue. [ I hope the images aren't too big. ] It's quite clear from the image that the "misaligned" line uses a font with a different slant/weight/height value. If that is the reason, I guess the problem is with composition caching, but why is that an issue in real life? Do real-life Lisp programs modify face font attributes so frequently? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:19 ` Eli Zaretskii @ 2024-10-27 17:27 ` Eli Zaretskii 2024-10-27 17:39 ` Yixuan Chen 2024-10-28 4:26 ` Visuwesh 2024-10-27 17:29 ` Yixuan Chen 1 sibling, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 17:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan, visuweshm > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Sun, 27 Oct 2024 19:19:48 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > It's quite clear from the image that the "misaligned" line uses a font > with a different slant/weight/height value. If that is the reason, I > guess the problem is with composition caching, but why is that an > issue in real life? Do real-life Lisp programs modify face font > attributes so frequently? Or maybe I don't understand the original problem. The bug report says "extra spaces", but eacg font has its own metrics of the SPC glyph, so highlighting a line with a given face can affect the metrics of the whitespace. Why is this surprising? Or what did I miss? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:27 ` Eli Zaretskii @ 2024-10-27 17:39 ` Yixuan Chen 2024-10-27 17:43 ` Eli Zaretskii 2024-10-28 4:26 ` Visuwesh 1 sibling, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 17:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm On 10/27/24 13:27, Eli Zaretskii wrote: > Or maybe I don't understand the original problem. The bug report says > "extra spaces", but eacg font has its own metrics of the SPC glyph, so > highlighting a line with a given face can affect the metrics of the > whitespace. Why is this surprising? Or what did I miss? The problem is that the "space" being rendered is different in the following two case: - if the default font is set to a specific combination of attributes (say 16, bold, normal) from start, it renders all the characters with one version of spacing. Let's call this version of spacing the "expected" spacing, - if the default font is some other combination of attributes (say 16, regular, normal), and one line is set to the attribute of (16, bold, normal). There is a **probability** that this line will render with a different version of spacing than the "expected" spacing. In my setup, this different spacing is extra wide. Ultimately, I believe the following should be true: if one line is rendered with **the same font face attributes**, it should always be rendered in **the same way**, regardless when, where, and how its attributes are assigned. This is not the case for emacs right now, and thus I consider it a bug. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:39 ` Yixuan Chen @ 2024-10-27 17:43 ` Eli Zaretskii 2024-10-27 17:46 ` Yixuan Chen 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 17:43 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Sun, 27 Oct 2024 13:39:56 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > On 10/27/24 13:27, Eli Zaretskii wrote: > > Or maybe I don't understand the original problem. The bug report says > > "extra spaces", but eacg font has its own metrics of the SPC glyph, so > > highlighting a line with a given face can affect the metrics of the > > whitespace. Why is this surprising? Or what did I miss? > > The problem is that the "space" being rendered is different in the > following two case: > > - if the default font is set to a specific combination of attributes > (say 16, bold, normal) from start, it renders all the characters with > one version of spacing. Let's call this version of spacing the > "expected" spacing, > - if the default font is some other combination of attributes (say 16, > regular, normal), and one line is set to the attribute of (16, bold, > normal). There is a **probability** that this line will render with a > different version of spacing than the "expected" spacing. In my setup, > this different spacing is extra wide. > > Ultimately, I believe the following should be true: if one line is > rendered with **the same font face attributes**, it should always be > rendered in **the same way**, regardless when, where, and how its > attributes are assigned. This is not the case for emacs right now, and > thus I consider it a bug. Sorry, I still don't understand. Your code does (highlight-lines-matching-regexp (cdr face) (car face)) This potentially shows each line in a different face, and thus can affect the metrics of the SPC character glyph which is what the indentation is made of. So why is this a problem, let alone a bug? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:43 ` Eli Zaretskii @ 2024-10-27 17:46 ` Yixuan Chen 2024-10-27 19:14 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 17:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm > Sorry, I still don't understand. Your code does > > (highlight-lines-matching-regexp (cdr face) (car face)) > > This potentially shows each line in a different face, and thus can > affect the metrics of the SPC character glyph which is what the > indentation is made of. So why is this a problem, let alone a bug? The problem is executing that line at 10PM today may render the font one way, while executing that line at 6AM tomorrow (with exactly the same "face" variable) may render the font a different way, even if all the other variables remains the same. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:46 ` Yixuan Chen @ 2024-10-27 19:14 ` Eli Zaretskii 2024-10-27 19:36 ` Yixuan Chen 2024-10-27 19:41 ` Yixuan Chen 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 19:14 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Sun, 27 Oct 2024 13:46:55 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > > Sorry, I still don't understand. Your code does > > > > (highlight-lines-matching-regexp (cdr face) (car face)) > > > > This potentially shows each line in a different face, and thus can > > affect the metrics of the SPC character glyph which is what the > > indentation is made of. So why is this a problem, let alone a bug? > > The problem is executing that line at 10PM today may render the font one > way, while executing that line at 6AM tomorrow (with exactly the same > "face" variable) may render the font a different way, even if all the > other variables remains the same. But you modify the faces in a random fashion, so why is this a surprise that it is not deterministic? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 19:14 ` Eli Zaretskii @ 2024-10-27 19:36 ` Yixuan Chen 2024-10-27 19:44 ` Eli Zaretskii 2024-10-27 19:41 ` Yixuan Chen 1 sibling, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 19:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm On 10/27/24 15:14, Eli Zaretskii wrote: >> Date: Sun, 27 Oct 2024 13:46:55 -0400 >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >>> Sorry, I still don't understand. Your code does >>> >>> (highlight-lines-matching-regexp (cdr face) (car face)) >>> >>> This potentially shows each line in a different face, and thus can >>> affect the metrics of the SPC character glyph which is what the >>> indentation is made of. So why is this a problem, let alone a bug? >> >> The problem is executing that line at 10PM today may render the font one >> way, while executing that line at 6AM tomorrow (with exactly the same >> "face" variable) may render the font a different way, even if all the >> other variables remains the same. > > But you modify the faces in a random fashion, so why is this a > surprise that it is not deterministic? I said, > ... (with exactly the same "face" variable) ... even if all the > other variables remains the same. Yes, this script is modifying the scripts in a random fashion, but let's imagine this: 1. the first time I open emacs, start the script and it randomizes the first line to a combination of face attributes (let's say (16, bold, regular)) in 5 seconds after going through 50 different combinations, it looks one way. 2. I restart emacs, start the script and it randomizes the first line to the same combination of face attributes (16, bold, regular) in 5 minutes after going through 3000 combinations, it looks differently from the first time, Do you agree that in both cases that single line should look the same? And they should always look the same as long as the randomization hits (16, bold, regular) on that line regardless of time and previous history? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 19:36 ` Yixuan Chen @ 2024-10-27 19:44 ` Eli Zaretskii 2024-10-27 19:47 ` Yixuan Chen 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 19:44 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Sun, 27 Oct 2024 15:36:06 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > On 10/27/24 15:14, Eli Zaretskii wrote: > >> Date: Sun, 27 Oct 2024 13:46:55 -0400 > >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > >> From: Yixuan Chen <xuan@xlk.me> > >> > >>> Sorry, I still don't understand. Your code does > >>> > >>> (highlight-lines-matching-regexp (cdr face) (car face)) > >>> > >>> This potentially shows each line in a different face, and thus can > >>> affect the metrics of the SPC character glyph which is what the > >>> indentation is made of. So why is this a problem, let alone a bug? > >> > >> The problem is executing that line at 10PM today may render the font one > >> way, while executing that line at 6AM tomorrow (with exactly the same > >> "face" variable) may render the font a different way, even if all the > >> other variables remains the same. > > > > But you modify the faces in a random fashion, so why is this a > > surprise that it is not deterministic? > > I said, > > > ... (with exactly the same "face" variable) ... even if all the > > other variables remains the same. > > Yes, this script is modifying the scripts in a random fashion, but let's > imagine this: > > 1. the first time I open emacs, start the script and it randomizes the > first line to a combination of face attributes (let's say (16, bold, > regular)) in 5 seconds after going through 50 different combinations, it > looks one way. > > 2. I restart emacs, start the script and it randomizes the first line to > the same combination of face attributes (16, bold, regular) in 5 minutes > after going through 3000 combinations, it looks differently from the > first time, > > Do you agree that in both cases that single line should look the same? > And they should always look the same as long as the randomization hits > (16, bold, regular) on that line regardless of time and previous history? That depends when redisplay kicks in, between your face randomizations. Among other factors. And I still fail to understand why this largely artificial program is important to investigate. Are there any real-life cases where you see the same face displayed differently when ligatures are involved? If not, what useful stuff will we learn by digging into this, especially since reproducing the problem is so hard? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 19:44 ` Eli Zaretskii @ 2024-10-27 19:47 ` Yixuan Chen 2024-10-27 20:11 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 19:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm On 10/27/24 15:44, Eli Zaretskii wrote: >> Date: Sun, 27 Oct 2024 15:36:06 -0400 >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >> On 10/27/24 15:14, Eli Zaretskii wrote: >>>> Date: Sun, 27 Oct 2024 13:46:55 -0400 >>>> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >>>> From: Yixuan Chen <xuan@xlk.me> >>>> >>>>> Sorry, I still don't understand. Your code does >>>>> >>>>> (highlight-lines-matching-regexp (cdr face) (car face)) >>>>> >>>>> This potentially shows each line in a different face, and thus can >>>>> affect the metrics of the SPC character glyph which is what the >>>>> indentation is made of. So why is this a problem, let alone a bug? >>>> >>>> The problem is executing that line at 10PM today may render the font one >>>> way, while executing that line at 6AM tomorrow (with exactly the same >>>> "face" variable) may render the font a different way, even if all the >>>> other variables remains the same. >>> >>> But you modify the faces in a random fashion, so why is this a >>> surprise that it is not deterministic? >> >> I said, >> >> > ... (with exactly the same "face" variable) ... even if all the >> > other variables remains the same. >> >> Yes, this script is modifying the scripts in a random fashion, but let's >> imagine this: >> >> 1. the first time I open emacs, start the script and it randomizes the >> first line to a combination of face attributes (let's say (16, bold, >> regular)) in 5 seconds after going through 50 different combinations, it >> looks one way. >> >> 2. I restart emacs, start the script and it randomizes the first line to >> the same combination of face attributes (16, bold, regular) in 5 minutes >> after going through 3000 combinations, it looks differently from the >> first time, >> >> Do you agree that in both cases that single line should look the same? >> And they should always look the same as long as the randomization hits >> (16, bold, regular) on that line regardless of time and previous history? > > That depends when redisplay kicks in, between your face > randomizations. Among other factors. > > And I still fail to understand why this largely artificial program is > important to investigate. Are there any real-life cases where you see > the same face displayed differently when ligatures are involved? If > not, what useful stuff will we learn by digging into this, especially > since reproducing the problem is so hard? Maybe you missed one of my previous email, let me copy paste what I said again, > It's not about frequency, but probably total number of font face > attribute changes. The lisp code I submitted was changing the attributes > rapidly just to recreate the problem faster. In real-life, this problem > happens with normal emacs configuration, usually within half an hour. > > For reference, here > (https://github.com/LukeXuan/dot-files/tree/e6067ec232ea34e01fb9a1f1a358d1c328d47c50/.config/doom) > is my emacs configuration on top of doom. I primarily write LaTeX and > Coq and this problem occurs every 30 minutes or so. The solution is to > either restart emacs (what I used to do) or disable ligature altogether > (what I do now). > ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 19:47 ` Yixuan Chen @ 2024-10-27 20:11 ` Eli Zaretskii 0 siblings, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 20:11 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Sun, 27 Oct 2024 15:47:57 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > > It's not about frequency, but probably total number of font face > > attribute changes. The lisp code I submitted was changing the attributes > > rapidly just to recreate the problem faster. In real-life, this problem > > happens with normal emacs configuration, usually within half an hour. What is "the problem which happens within half an hour" in real-life? And what causes "font face attribute changes" in that case? Also, can you reproduce the problem at will, and then leave that session running so I could ask you to report some details and perform some experiments? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 19:14 ` Eli Zaretskii 2024-10-27 19:36 ` Yixuan Chen @ 2024-10-27 19:41 ` Yixuan Chen 2024-10-27 20:07 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 19:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm On 10/27/24 15:14, Eli Zaretskii wrote: >> Date: Sun, 27 Oct 2024 13:46:55 -0400 >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >>> Sorry, I still don't understand. Your code does >>> >>> (highlight-lines-matching-regexp (cdr face) (car face)) >>> >>> This potentially shows each line in a different face, and thus can >>> affect the metrics of the SPC character glyph which is what the >>> indentation is made of. So why is this a problem, let alone a bug? >> >> The problem is executing that line at 10PM today may render the font one >> way, while executing that line at 6AM tomorrow (with exactly the same >> "face" variable) may render the font a different way, even if all the >> other variables remains the same. > > But you modify the faces in a random fashion, so why is this a > surprise that it is not deterministic? Just in case my last explanation wasn't clear enough: by "with exactly the same face variable", I'm saying that when the randomizer picks the same font attribute (the same everything), there is a chance it will render that line differently. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 19:41 ` Yixuan Chen @ 2024-10-27 20:07 ` Eli Zaretskii 2024-10-27 20:32 ` Yixuan Chen 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-27 20:07 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Sun, 27 Oct 2024 15:41:06 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > On 10/27/24 15:14, Eli Zaretskii wrote: > >> Date: Sun, 27 Oct 2024 13:46:55 -0400 > >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > >> From: Yixuan Chen <xuan@xlk.me> > >> > >>> Sorry, I still don't understand. Your code does > >>> > >>> (highlight-lines-matching-regexp (cdr face) (car face)) > >>> > >>> This potentially shows each line in a different face, and thus can > >>> affect the metrics of the SPC character glyph which is what the > >>> indentation is made of. So why is this a problem, let alone a bug? > >> > >> The problem is executing that line at 10PM today may render the font one > >> way, while executing that line at 6AM tomorrow (with exactly the same > >> "face" variable) may render the font a different way, even if all the > >> other variables remains the same. > > > > But you modify the faces in a random fashion, so why is this a > > surprise that it is not deterministic? > > Just in case my last explanation wasn't clear enough: by "with exactly > the same face variable", I'm saying that when the randomizer picks the > same font attribute (the same everything), there is a chance it will > render that line differently. That's not what I see in the images I've been shown. The lines that have different indentation have either different slant or different weight. To convince me that this is really happening (although I'm unable to understand how it could, given how Emacs faces work), you will need to show some code which generates such a situation in a reproducible manner, and then show me by using "M-x describe-text-properties" and "C-u C-x =" that indeed the same characters in the same face are shown on different lines with different metrics. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 20:07 ` Eli Zaretskii @ 2024-10-27 20:32 ` Yixuan Chen 2024-10-28 14:25 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 20:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm [-- Attachment #1: Type: text/plain, Size: 3949 bytes --] On 10/27/24 16:07, Eli Zaretskii wrote: > To convince me that this is really happening (although I'm unable to > understand how it could, given how Emacs faces work), you will need to > show some code which generates such a situation in a reproducible > manner, and then show me by using "M-x describe-text-properties" and > "C-u C-x =" that indeed the same characters in the same face are shown > on different lines with different metrics. OK, here you go. > you will need to show some code which generates such a situation in a reproducible manner The same script I submitted in this bug. "screenshot1.png" shows the bugged display. Here's the result of "describe-text-properties", > There are text properties here: > face (face12 font-lock-string-face) > fontified t In case you want to know what the face12 is, > Face: face12 (sample) (customize this face) > > Documentation: > Not documented as a face. > > > Family: unspecified > Foundry: unspecified > Width: unspecified > Height: 125 > Weight: medium > Slant: italic > Foreground: unspecified > DistantForeground: unspecified > Background: unspecified > Underline: unspecified > Overline: unspecified > Strike-through: unspecified > Box: unspecified > Inverse: unspecified > Stipple: unspecified > Font: unspecified > Fontset: unspecified > Extend: unspecified > Inherit: unspecified and here's the result of "C-x C-u =": > position: 1277 of 3527 (36%), column: 34 > character: > (displayed as >) (codepoint 62, #o76, #x3e) > charset: ascii (ASCII (ISO646 IRV)) > code point in charset: 0x3E > script: latin > syntax: _ which means: symbol > category: .:Base, a:ASCII, l:Latin, r:Roman > to input: type "C-x 8 RET 3e" or "C-x 8 RET GREATER-THAN SIGN" > buffer code: #x3E > file code: #x3E (encoded by coding system utf-8-unix) > display: by this font (glyph code): > ftcrhb:-SAJA-Cascadia Code-regular-italic-normal-*-17-*-*-*-m-0-iso10646-1 (#x3AC) > > Character code properties: customize what to show > name: GREATER-THAN SIGN > general-category: Sm (Symbol, Math) > decomposition: (62) ('>') > > There are text properties here: > face (face12 font-lock-string-face) > fontified t In a separate fresh new emacs window, I execute the following command: (set-face-attribute 'default nil :weight 'medium :slant 'italic :height 125) "screenshot2.png" shows how it looks this time (the normal display). the result of "describe-text-properties": > There are text properties here: > face font-lock-string-face > fontified nil and "C-u C-x =": > position: 1277 of 3527 (36%), column: 34 > character: > (displayed as >) (codepoint 62, #o76, #x3e) > charset: ascii (ASCII (ISO646 IRV)) > code point in charset: 0x3E > script: latin > syntax: _ which means: symbol > category: .:Base, a:ASCII, l:Latin, r:Roman > to input: type "C-x 8 RET 3e" or "C-x 8 RET GREATER-THAN SIGN" > buffer code: #x3E > file code: #x3E (encoded by coding system utf-8-unix) > display: by this font (glyph code): > ftcrhb:-SAJA-Cascadia Code-regular-italic-normal-*-17-*-*-*-m-0-iso10646-1 (#x3AC) > > Character code properties: customize what to show > name: GREATER-THAN SIGN > general-category: Sm (Symbol, Math) > decomposition: (62) ('>') > > There are text properties here: > face font-lock-string-face > fontified t If you want more information, I will keep both emacs window open for the next two hours. [-- Attachment #2: screenshot1.png --] [-- Type: image/png, Size: 15002 bytes --] [-- Attachment #3: screenshot2.png --] [-- Type: image/png, Size: 13496 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 20:32 ` Yixuan Chen @ 2024-10-28 14:25 ` Eli Zaretskii 2024-10-28 14:44 ` Yixuan Chen 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 14:25 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Sun, 27 Oct 2024 16:32:34 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > On 10/27/24 16:07, Eli Zaretskii wrote: > > To convince me that this is really happening (although I'm unable to > > understand how it could, given how Emacs faces work), you will need to > > show some code which generates such a situation in a reproducible > > manner, and then show me by using "M-x describe-text-properties" and > > "C-u C-x =" that indeed the same characters in the same face are shown > > on different lines with different metrics. > > OK, here you go. Not exactly what I asked for, or understood how the problem manifests itself... > "screenshot1.png" shows the bugged display. Here's the result of > "describe-text-properties", > > There are text properties here: > > face (face12 font-lock-string-face) > > fontified t But this is a completely different issue. There's no indentation here, right? You are saying that in the "bad" display there's some extra space between the ligature and the following quote, right? Is that extra space a real SPC glyph or is it just that the ligature is considered "wider"? What happens if you put the cursor on the ▷ ligature in the "bad" display -- does the block cursor then take up all the space up to the next quote? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 14:25 ` Eli Zaretskii @ 2024-10-28 14:44 ` Yixuan Chen 2024-10-28 14:47 ` Yixuan Chen 2024-10-28 15:05 ` Eli Zaretskii 0 siblings, 2 replies; 90+ messages in thread From: Yixuan Chen @ 2024-10-28 14:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm [-- Attachment #1: Type: text/plain, Size: 2126 bytes --] On 10/28/24 10:25, Eli Zaretskii wrote: >> Date: Sun, 27 Oct 2024 16:32:34 -0400 >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >> On 10/27/24 16:07, Eli Zaretskii wrote: >>> To convince me that this is really happening (although I'm unable to >>> understand how it could, given how Emacs faces work), you will need to >>> show some code which generates such a situation in a reproducible >>> manner, and then show me by using "M-x describe-text-properties" and >>> "C-u C-x =" that indeed the same characters in the same face are shown >>> on different lines with different metrics. >> >> OK, here you go. > > Not exactly what I asked for, or understood how the problem manifests > itself... > >> "screenshot1.png" shows the bugged display. Here's the result of >> "describe-text-properties", >>> There are text properties here: >>> face (face12 font-lock-string-face) >>> fontified t > > But this is a completely different issue. There's no indentation > here, right? You are saying that in the "bad" display there's some > extra space between the ligature and the following quote, right? Maybe my use of words were terrible. The problem I want to report was never about indentation. It was always about the "extra space between the ligature and the following character" (and sometimes also some extra space between the ligature and the character, although not in this instance). > Is > that extra space a real SPC glyph or is it just that the ligature is > considered "wider"? What happens if you put the cursor on the ▷ > ligature in the "bad" display -- does the block cursor then take up > all the space up to the next quote? It's not a real SPC glyph. It's a single character ▷ (or ligature/glyph I should call it? the underlying text is "|||>"). I attached five screenshots, where the block cursor is at ", |, |, |, >, " respectively. Noticeably, the block cursor for the first | character (1_bar.png) is extra wide, and the block cursors for the following characters looks offset from where they are. [-- Attachment #2: 0_quote.png --] [-- Type: image/png, Size: 1816 bytes --] [-- Attachment #3: 1_bar.png --] [-- Type: image/png, Size: 1607 bytes --] [-- Attachment #4: 2_bar.png --] [-- Type: image/png, Size: 1597 bytes --] [-- Attachment #5: 3_bar.png --] [-- Type: image/png, Size: 1352 bytes --] [-- Attachment #6: 4_gt.png --] [-- Type: image/png, Size: 1454 bytes --] [-- Attachment #7: 5_quote.png --] [-- Type: image/png, Size: 1364 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 14:44 ` Yixuan Chen @ 2024-10-28 14:47 ` Yixuan Chen 2024-10-28 15:05 ` Eli Zaretskii 1 sibling, 0 replies; 90+ messages in thread From: Yixuan Chen @ 2024-10-28 14:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm Also, this morning someone mentioned on the github issue I linked above stating that he/she encountered a similar problem, and switching from cairo to Xft fixed the problem. I don't know if it's related, but you might want to know. I use wayland myself and xwayland doesn't support fractional scaling, so that's not a feasible solution for me. On 10/28/24 10:44, Yixuan Chen wrote: > > > On 10/28/24 10:25, Eli Zaretskii wrote: >>> Date: Sun, 27 Oct 2024 16:32:34 -0400 >>> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >>> From: Yixuan Chen <xuan@xlk.me> >>> >>> On 10/27/24 16:07, Eli Zaretskii wrote: >>>> To convince me that this is really happening (although I'm unable to >>>> understand how it could, given how Emacs faces work), you will need to >>>> show some code which generates such a situation in a reproducible >>>> manner, and then show me by using "M-x describe-text-properties" and >>>> "C-u C-x =" that indeed the same characters in the same face are shown >>>> on different lines with different metrics. >>> >>> OK, here you go. >> >> Not exactly what I asked for, or understood how the problem manifests >> itself... >> >>> "screenshot1.png" shows the bugged display. Here's the result of >>> "describe-text-properties", >>>> There are text properties here: >>>> face (face12 font-lock-string-face) >>>> fontified t >> >> But this is a completely different issue. There's no indentation >> here, right? You are saying that in the "bad" display there's some >> extra space between the ligature and the following quote, right? > > Maybe my use of words were terrible. The problem I want to report was > never about indentation. It was always about the "extra space between > the ligature and the following character" (and sometimes also some extra > space between the ligature and the character, although not in this > instance). > >> Is >> that extra space a real SPC glyph or is it just that the ligature is >> considered "wider"? What happens if you put the cursor on the ▷ >> ligature in the "bad" display -- does the block cursor then take up >> all the space up to the next quote? > > It's not a real SPC glyph. It's a single character ▷ (or ligature/glyph > I should call it? the underlying text is "|||>"). I attached five > screenshots, where the block cursor is at ", |, |, |, >, " respectively. > Noticeably, the block cursor for the first | character (1_bar.png) is > extra wide, and the block cursors for the following characters looks > offset from where they are. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 14:44 ` Yixuan Chen 2024-10-28 14:47 ` Yixuan Chen @ 2024-10-28 15:05 ` Eli Zaretskii 2024-10-28 15:20 ` Yixuan Chen 1 sibling, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 15:05 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm [-- Attachment #1: Type: text/plain, Size: 990 bytes --] > Date: Mon, 28 Oct 2024 10:44:23 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > > Is > > that extra space a real SPC glyph or is it just that the ligature is > > considered "wider"? What happens if you put the cursor on the ▷ > > ligature in the "bad" display -- does the block cursor then take up > > all the space up to the next quote? > > It's not a real SPC glyph. It's a single character ▷ (or ligature/glyph > I should call it? the underlying text is "|||>"). I attached five > screenshots, where the block cursor is at ", |, |, |, >, " respectively. > Noticeably, the block cursor for the first | character (1_bar.png) is > extra wide, and the block cursors for the following characters looks > offset from where they are. According to the screenshots, it actually looks like it's a real SPC glyph or something. What does "C-u C-x =" show when the block cursor is shown as below? [-- Attachment #2: 4_gt.png --] [-- Type: image/png, Size: 1454 bytes --] [-- Attachment #3: Type: text/plain, Size: 172 bytes --] Actually, how about showing what "C-u C-x =" says in each of the 6 positions you show? And then show what "C-u C-x =" says in the same 6 positions in the "good" display? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 15:05 ` Eli Zaretskii @ 2024-10-28 15:20 ` Yixuan Chen 2024-10-28 17:19 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-28 15:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm [-- Attachment #1: Type: text/plain, Size: 2322 bytes --] On 10/28/24 11:05, Eli Zaretskii wrote: >> Date: Mon, 28 Oct 2024 10:44:23 -0400 >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >>> Is >>> that extra space a real SPC glyph or is it just that the ligature is >>> considered "wider"? What happens if you put the cursor on the ▷ >>> ligature in the "bad" display -- does the block cursor then take up >>> all the space up to the next quote? >> >> It's not a real SPC glyph. It's a single character ▷ (or ligature/glyph >> I should call it? the underlying text is "|||>"). I attached five >> screenshots, where the block cursor is at ", |, |, |, >, " respectively. >> Noticeably, the block cursor for the first | character (1_bar.png) is >> extra wide, and the block cursors for the following characters looks >> offset from where they are. > > According to the screenshots, it actually looks like it's a real SPC > glyph or something. What does "C-u C-x =" show when the block cursor > is shown as below? It shows > position: 1277 of 3527 (36%), column: 34 > character: > (displayed as >) (codepoint 62, #o76, #x3e) > charset: ascii (ASCII (ISO646 IRV)) > code point in charset: 0x3E > script: latin > syntax: _ which means: symbol > category: .:Base, a:ASCII, l:Latin, r:Roman > to input: type "C-x 8 RET 3e" or "C-x 8 RET GREATER-THAN SIGN" > buffer code: #x3E > file code: #x3E (encoded by coding system utf-8-unix) > display: by this font (glyph code): > ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x810) > > Character code properties: customize what to show > name: GREATER-THAN SIGN > general-category: Sm (Symbol, Math) > decomposition: (62) ('>') > > There are text properties here: > face (face12 font-lock-string-face) > fontified t > Actually, how about showing what "C-u C-x =" says in each of the 6 > positions you show? And then show what "C-u C-x =" says in the same 6 > positions in the "good" display? See "bad.txt" for the output of the bad emacs display, and "good.txt" for the output of good emacs display. I also attached the block cursor screenshots for good emacs display. [-- Attachment #2: good.txt --] [-- Type: text/plain, Size: 5447 bytes --] 0: position: 1273 of 3535 (36%), column: 30 character: " (displayed as ") (codepoint 34, #o42, #x22) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x22 script: latin syntax: " which means: string category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 22" or "C-x 8 RET QUOTATION MARK" buffer code: #x22 file code: #x22 (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x779) Character code properties: customize what to show name: QUOTATION MARK general-category: Po (Punctuation, Other) decomposition: (34) ('"') There are text properties here: face (face12 font-lock-string-face) fontified t 1: position: 1274 of 3535 (36%), column: 31 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') There are text properties here: face (face12 font-lock-string-face) fontified t 2: position: 1275 of 3535 (36%), column: 32 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') There are text properties here: face (face12 font-lock-string-face) fontified t 3: position: 1276 of 3535 (36%), column: 33 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') There are text properties here: face (face12 font-lock-string-face) fontified t 4: position: 1277 of 3535 (36%), column: 34 character: > (displayed as >) (codepoint 62, #o76, #x3e) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x3E script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 3e" or "C-x 8 RET GREATER-THAN SIGN" buffer code: #x3E file code: #x3E (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x810) Character code properties: customize what to show name: GREATER-THAN SIGN general-category: Sm (Symbol, Math) decomposition: (62) ('>') There are text properties here: face (face12 font-lock-string-face) fontified t 5: position: 1278 of 3535 (36%), column: 35 character: " (displayed as ") (codepoint 34, #o42, #x22) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x22 script: latin syntax: " which means: string category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 22" or "C-x 8 RET QUOTATION MARK" buffer code: #x22 file code: #x22 (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x779) Character code properties: customize what to show name: QUOTATION MARK general-category: Po (Punctuation, Other) decomposition: (34) ('"') There are text properties here: face (face12 font-lock-string-face) fontified t [-- Attachment #3: bad.txt --] [-- Type: text/plain, Size: 5446 bytes --] 0: position: 1273 of 3527 (36%), column: 30 character: " (displayed as ") (codepoint 34, #o42, #x22) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x22 script: latin syntax: " which means: string category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 22" or "C-x 8 RET QUOTATION MARK" buffer code: #x22 file code: #x22 (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x779) Character code properties: customize what to show name: QUOTATION MARK general-category: Po (Punctuation, Other) decomposition: (34) ('"') 1: There are text properties here: face (face12 font-lock-string-face) fontified t position: 1274 of 3527 (36%), column: 31 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') 2: There are text properties here: face (face12 font-lock-string-face) fontified t position: 1274 of 3527 (36%), column: 31 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') 3: There are text properties here: face (face12 font-lock-string-face) fontified t position: 1276 of 3527 (36%), column: 33 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') There are text properties here: face (face12 font-lock-string-face) fontified t 4: position: 1277 of 3527 (36%), column: 34 character: > (displayed as >) (codepoint 62, #o76, #x3e) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x3E script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 3e" or "C-x 8 RET GREATER-THAN SIGN" buffer code: #x3E file code: #x3E (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x810) Character code properties: customize what to show name: GREATER-THAN SIGN general-category: Sm (Symbol, Math) decomposition: (62) ('>') There are text properties here: face (face12 font-lock-string-face) fontified t 5: position: 1278 of 3527 (36%), column: 35 character: " (displayed as ") (codepoint 34, #o42, #x22) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x22 script: latin syntax: " which means: string category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 22" or "C-x 8 RET QUOTATION MARK" buffer code: #x22 file code: #x22 (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x779) Character code properties: customize what to show name: QUOTATION MARK general-category: Po (Punctuation, Other) decomposition: (34) ('"') There are text properties here: face (face12 font-lock-string-face) fontified t [-- Attachment #4: 0.png --] [-- Type: image/png, Size: 1630 bytes --] [-- Attachment #5: 1.png --] [-- Type: image/png, Size: 1625 bytes --] [-- Attachment #6: 2.png --] [-- Type: image/png, Size: 1314 bytes --] [-- Attachment #7: 3.png --] [-- Type: image/png, Size: 1934 bytes --] [-- Attachment #8: 4.png --] [-- Type: image/png, Size: 1788 bytes --] [-- Attachment #9: 5.png --] [-- Type: image/png, Size: 1458 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 15:20 ` Yixuan Chen @ 2024-10-28 17:19 ` Eli Zaretskii 2024-10-28 17:26 ` Eli Zaretskii 2024-10-28 17:28 ` Yixuan Chen 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 17:19 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Mon, 28 Oct 2024 11:20:29 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > > Actually, how about showing what "C-u C-x =" says in each of the 6 > > positions you show? And then show what "C-u C-x =" says in the same 6 > > positions in the "good" display? > > See "bad.txt" for the output of the bad emacs display, and "good.txt" > for the output of good emacs display. I also attached the block cursor > screenshots for good emacs display. Thanks. It's basically the same, as far as Emacs thinks, but do you have any idea why EOB is different between these two cases (3535 vs 3527)? Also, Emacs thinks that the second | character is at the same buffer position and the same columns as the previous one -- any idea why? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 17:19 ` Eli Zaretskii @ 2024-10-28 17:26 ` Eli Zaretskii 2024-10-28 17:28 ` Yixuan Chen 1 sibling, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 17:26 UTC (permalink / raw) To: xuan; +Cc: luangruo, 73752, visuweshm > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, visuweshm@gmail.com > Date: Mon, 28 Oct 2024 19:19:19 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > Also, Emacs thinks that the second | character is at the same buffer > position and the same columns as the previous one -- any idea why? That's in the "bad" output, I should say. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 17:19 ` Eli Zaretskii 2024-10-28 17:26 ` Eli Zaretskii @ 2024-10-28 17:28 ` Yixuan Chen 2024-10-28 18:41 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-28 17:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, visuweshm On 10/28/24 13:19, Eli Zaretskii wrote: >> Date: Mon, 28 Oct 2024 11:20:29 -0400 >> Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org >> From: Yixuan Chen <xuan@xlk.me> >> >>> Actually, how about showing what "C-u C-x =" says in each of the 6 >>> positions you show? And then show what "C-u C-x =" says in the same 6 >>> positions in the "good" display? >> >> See "bad.txt" for the output of the bad emacs display, and "good.txt" >> for the output of good emacs display. I also attached the block cursor >> screenshots for good emacs display. > > Thanks. It's basically the same, as far as Emacs thinks, but do you > have any idea why EOB is different between these two cases (3535 vs > 3527)? Between the two versions (after bad.txt before good.txt), I made this change to the script: line 51 is modified from (run-at-time nil 1 #'random-faces))) to ;; (run-at-time nil 1 #'random-faces) )) so that I can manually set the face to face12. That's why EOB of "good.txt" is slightly larger. > Also, Emacs thinks that the second | character is at the same buffer > position and the same columns as the previous one -- any idea why? I'm sorry, that's me being bad at mouse and copy-pasting. This is the correct output for the second | character in "bad.txt". position: 1275 of 3527 (36%), column: 32 character: | (displayed as |) (codepoint 124, #o174, #x7c) charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x7C script: latin syntax: _ which means: symbol category: .:Base, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE" buffer code: #x7C file code: #x7C (encoded by coding system utf-8-unix) display: by this font (glyph code): ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x9F6) Character code properties: customize what to show name: VERTICAL LINE old-name: VERTICAL BAR general-category: Sm (Symbol, Math) decomposition: (124) ('|') There are text properties here: face (face12 font-lock-string-face) fontified t It seems like I simply pasted the output for the first bar character twice. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 17:28 ` Yixuan Chen @ 2024-10-28 18:41 ` Eli Zaretskii 0 siblings, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 18:41 UTC (permalink / raw) To: Yixuan Chen; +Cc: luangruo, 73752, visuweshm > Date: Mon, 28 Oct 2024 13:28:14 -0400 > Cc: visuweshm@gmail.com, luangruo@yahoo.com, 73752@debbugs.gnu.org > From: Yixuan Chen <xuan@xlk.me> > > > Thanks. It's basically the same, as far as Emacs thinks, but do you > > have any idea why EOB is different between these two cases (3535 vs > > 3527)? > > Between the two versions (after bad.txt before good.txt), I made this > change to the script: line 51 is modified from > > (run-at-time nil 1 #'random-faces))) > to > ;; (run-at-time nil 1 #'random-faces) > )) > > so that I can manually set the face to face12. That's why EOB of > "good.txt" is slightly larger. > > > Also, Emacs thinks that the second | character is at the same buffer > > position and the same columns as the previous one -- any idea why? > > I'm sorry, that's me being bad at mouse and copy-pasting. This is the > correct output for the second | character in "bad.txt". OK, so Emacs really thinks the two buffers are identical, faces, fonts, and all the rest. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:27 ` Eli Zaretskii 2024-10-27 17:39 ` Yixuan Chen @ 2024-10-28 4:26 ` Visuwesh 2024-10-28 14:59 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-10-28 4:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote: >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Sun, 27 Oct 2024 19:19:48 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> >> It's quite clear from the image that the "misaligned" line uses a font >> with a different slant/weight/height value. If that is the reason, I >> guess the problem is with composition caching, but why is that an >> issue in real life? Do real-life Lisp programs modify face font >> attributes so frequently? Real-life Lisp programs certainly do not change face font attributes so often but I believe the script does it so to reproduce the issue quickly. In a regular Emacs session, it is enough for the same text to be shown in different font sizes (as a consequence of using C-x C-+) and font weights to eventually exhibit this misalignment IME. > Or maybe I don't understand the original problem. The bug report says > "extra spaces", but eacg font has its own metrics of the SPC glyph, so > highlighting a line with a given face can affect the metrics of the > whitespace. Why is this surprising? Or what did I miss? I do not understand the technical details but the width of the glyph used to draw it is not the one that should be used for the underlying font (weight, size, etc. included) which leads to this misalignment. To make it more clear, let's say that =:= is shaped for a font X with a specific weight, size, etc. At a later point in time, the width of the glyph corresponding to X is used to draw =:= with font Y of same family. This leads to the observed misalignment AFAIU. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 4:26 ` Visuwesh @ 2024-10-28 14:59 ` Eli Zaretskii 2024-10-28 15:24 ` Yixuan Chen 2024-10-28 16:18 ` Visuwesh 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 14:59 UTC (permalink / raw) To: Visuwesh; +Cc: luangruo, 73752, xuan > From: Visuwesh <visuweshm@gmail.com> > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Mon, 28 Oct 2024 09:56:13 +0530 > > Real-life Lisp programs certainly do not change face font attributes so > often but I believe the script does it so to reproduce the issue > quickly. In a regular Emacs session, it is enough for the same text to > be shown in different font sizes (as a consequence of using C-x C-+) and > font weights to eventually exhibit this misalignment IME. You need to catch this situation in some reproducible recipe. Because up front I don't understand how is this possible: we cache each composition with its font object, which includes the font size (and also slant, weight, etc.), so a different variant of the same font ought to match only cache entries that use the exact same font. Or maybe I don't understand well enough what composition_gstring_put_cache does to compute the hash of a glyph-string header (which is the hash key for a composition)? > I do not understand the technical details but the width of the glyph > used to draw it is not the one that should be used for the underlying > font (weight, size, etc. included) which leads to this misalignment. Which seems to indicate that we somehow use a different font's metric. > To make it more clear, let's say that =:= is shaped for a font X with a > specific weight, size, etc. At a later point in time, the width of the > glyph corresponding to X is used to draw =:= with font Y of same family. > This leads to the observed misalignment AFAIU. But how can this happen? Without a reproducible recipe, which can be reproduced without waiting for too long, it is very hard to investigate this. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 14:59 ` Eli Zaretskii @ 2024-10-28 15:24 ` Yixuan Chen 2024-10-28 16:18 ` Visuwesh 1 sibling, 0 replies; 90+ messages in thread From: Yixuan Chen @ 2024-10-28 15:24 UTC (permalink / raw) To: Eli Zaretskii, Visuwesh; +Cc: luangruo, 73752 On 10/28/24 10:59, Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Mon, 28 Oct 2024 09:56:13 +0530 >> >> Real-life Lisp programs certainly do not change face font attributes so >> often but I believe the script does it so to reproduce the issue >> quickly. In a regular Emacs session, it is enough for the same text to >> be shown in different font sizes (as a consequence of using C-x C-+) and >> font weights to eventually exhibit this misalignment IME. > > You need to catch this situation in some reproducible recipe. Because > up front I don't understand how is this possible: we cache each > composition with its font object, which includes the font size (and > also slant, weight, etc.), so a different variant of the same font > ought to match only cache entries that use the exact same font. Or > maybe I don't understand well enough what > composition_gstring_put_cache does to compute the hash of a > glyph-string header (which is the hash key for a composition)? > >> I do not understand the technical details but the width of the glyph >> used to draw it is not the one that should be used for the underlying >> font (weight, size, etc. included) which leads to this misalignment. > > Which seems to indicate that we somehow use a different font's metric. > >> To make it more clear, let's say that =:= is shaped for a font X with a >> specific weight, size, etc. At a later point in time, the width of the >> glyph corresponding to X is used to draw =:= with font Y of same family. >> This leads to the observed misalignment AFAIU. > > But how can this happen? Without a reproducible recipe, which can be > reproduced without waiting for too long, it is very hard to > investigate this. Just my uninformed opinion. Considering, - the fact that it's hard to reproduce the problem (the script I submitted is the best way to trigger the problem to my knowledge since it reproduces on multiple people's emacs consistently), - the non-deterministic nature of this bug, - changing fonts rapidly seems to help triggering the bug, - my personal research bias, This sounds like a concurrency problem, such as some kind of race condition leading to cache being over-written or else. But I have zero idea on how emacs works internally, so I can be completely wrong. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 14:59 ` Eli Zaretskii 2024-10-28 15:24 ` Yixuan Chen @ 2024-10-28 16:18 ` Visuwesh 2024-10-28 17:13 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-10-28 16:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [திங்கள் அக்டோபர் 28, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Mon, 28 Oct 2024 09:56:13 +0530 >> >> Real-life Lisp programs certainly do not change face font attributes so >> often but I believe the script does it so to reproduce the issue >> quickly. In a regular Emacs session, it is enough for the same text to >> be shown in different font sizes (as a consequence of using C-x C-+) and >> font weights to eventually exhibit this misalignment IME. > > You need to catch this situation in some reproducible recipe. Because > up front I don't understand how is this possible: we cache each > composition with its font object, which includes the font size (and > also slant, weight, etc.), so a different variant of the same font > ought to match only cache entries that use the exact same font. Or > maybe I don't understand well enough what > composition_gstring_put_cache does to compute the hash of a > glyph-string header (which is the hash key for a composition)? Is this hash dependent on the font driver? IME and from what I see from other issues in ligature.el's GitHub issue page, the problem seems to be specific to Cairo builds which would also explain why you are not able to reproduce this. Also, do we clear the composition cache when all the GUI frames of an Emacs daemon are deleted? The misalignment goes away when I close all the GUI frames of the daemon, and open a fresh new GUI frame. >> I do not understand the technical details but the width of the glyph >> used to draw it is not the one that should be used for the underlying >> font (weight, size, etc. included) which leads to this misalignment. > > Which seems to indicate that we somehow use a different font's metric. That is my impression, yes. >> To make it more clear, let's say that =:= is shaped for a font X with a >> specific weight, size, etc. At a later point in time, the width of the >> glyph corresponding to X is used to draw =:= with font Y of same family. >> This leads to the observed misalignment AFAIU. > > But how can this happen? Without a reproducible recipe, which can be > reproduced without waiting for too long, it is very hard to > investigate this. I have no idea. This is not easy to reproduce and seems to be heavily dependent on the configuration. Although I use a Cairo build (with Lucid toolkit), the misalignment is not as severe as OP says and it takes a lot more time to reproduce as well. I could never come up with a reproducer that takes less time. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 16:18 ` Visuwesh @ 2024-10-28 17:13 ` Eli Zaretskii 2024-10-29 10:59 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-28 17:13 UTC (permalink / raw) To: Visuwesh; +Cc: luangruo, 73752, xuan > From: Visuwesh <visuweshm@gmail.com> > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Mon, 28 Oct 2024 21:48:26 +0530 > > > You need to catch this situation in some reproducible recipe. Because > > up front I don't understand how is this possible: we cache each > > composition with its font object, which includes the font size (and > > also slant, weight, etc.), so a different variant of the same font > > ought to match only cache entries that use the exact same font. Or > > maybe I don't understand well enough what > > composition_gstring_put_cache does to compute the hash of a > > glyph-string header (which is the hash key for a composition)? > > Is this hash dependent on the font driver? No. Only the font used for the composed characters is recorded, not the font backend which opened it. But fonts are managed by the font backend, so maybe there's some leakage by that way. > Also, do we clear the composition cache when all the GUI frames of an > Emacs daemon are deleted? No, we don't, not directly. But we clear the face cache, and that removes the data of the fonts referred by the face cache from the composition cache. So it's quite possible the composition cache is left empty when all the frames are deleted. > The misalignment goes away when I close all > the GUI frames of the daemon, and open a fresh new GUI frame. Next time this happens, try one of these two: M-: (clear-face-cache t) RET M-: (clear-composition-cache) RET and see if any of them corrects the problematic display. Btw, how frequently do you use different frames, and how likely are you to have different definitions for the same faces on different frames in the same Emacs session at the same time? > > But how can this happen? Without a reproducible recipe, which can be > > reproduced without waiting for too long, it is very hard to > > investigate this. > > I have no idea. This is not easy to reproduce and seems to be heavily > dependent on the configuration. Although I use a Cairo build (with > Lucid toolkit), the misalignment is not as severe as OP says and it > takes a lot more time to reproduce as well. I could never come up with > a reproducer that takes less time. The only way I see to investigate this is to wait for this to happen, then attach GDB to Emacs and look at the problematic compositions in the cache, comparing them to the corresponding compositions in a fresh Emacs session. I can tell what to look for with GDB, if that helps. If we see that two compositions that should be identical differ by their font objects, say, we'd at least have a lead and a starting point for further debugging. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-28 17:13 ` Eli Zaretskii @ 2024-10-29 10:59 ` Visuwesh 2024-10-29 13:04 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-10-29 10:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [திங்கள் அக்டோபர் 28, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Mon, 28 Oct 2024 21:48:26 +0530 >> >> > You need to catch this situation in some reproducible recipe. Because >> > up front I don't understand how is this possible: we cache each >> > composition with its font object, which includes the font size (and >> > also slant, weight, etc.), so a different variant of the same font >> > ought to match only cache entries that use the exact same font. Or >> > maybe I don't understand well enough what >> > composition_gstring_put_cache does to compute the hash of a >> > glyph-string header (which is the hash key for a composition)? >> >> Is this hash dependent on the font driver? > > No. Only the font used for the composed characters is recorded, not > the font backend which opened it. But fonts are managed by the font > backend, so maybe there's some leakage by that way. OK, thanks. I wonder if we could compare the value returned by font-info if something has gone wrong with the font object used to compute the hash for the glyph? >> Also, do we clear the composition cache when all the GUI frames of an >> Emacs daemon are deleted? > > No, we don't, not directly. But we clear the face cache, and that > removes the data of the fonts referred by the face cache from the > composition cache. So it's quite possible the composition cache is > left empty when all the frames are deleted. Thanks that would explain it but then... >> The misalignment goes away when I close all >> the GUI frames of the daemon, and open a fresh new GUI frame. > > Next time this happens, try one of these two: > > M-: (clear-face-cache t) RET > M-: (clear-composition-cache) RET > > and see if any of them corrects the problematic display. neither of them helped in the past. I tried to if they help again but failed to reproduce the problem today. > Btw, how frequently do you use different frames, Quite often, I would say. I usually have two frames but it can go upwards of 5 to 6 if I have a mouse attached to my laptop. > and how likely are you to have different definitions for the same > faces on different frames in the same Emacs session at the same time? I don't quite understand this question. Are you asking if I have any "frame-specific" face attributes i.e., non-nil FRAME argument in set-face-attribute? If so, no. >> > But how can this happen? Without a reproducible recipe, which can be >> > reproduced without waiting for too long, it is very hard to >> > investigate this. >> >> I have no idea. This is not easy to reproduce and seems to be heavily >> dependent on the configuration. Although I use a Cairo build (with >> Lucid toolkit), the misalignment is not as severe as OP says and it >> takes a lot more time to reproduce as well. I could never come up with >> a reproducer that takes less time. > > The only way I see to investigate this is to wait for this to happen, > then attach GDB to Emacs and look at the problematic compositions in > the cache, comparing them to the corresponding compositions in a fresh > Emacs session. I can tell what to look for with GDB, if that helps. That would help. But given how hard it is to reproduce this issue on my end, I don't know when I can get back... > If we see that two compositions that should be identical differ by > their font objects, say, we'd at least have a lead and a starting > point for further debugging. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 10:59 ` Visuwesh @ 2024-10-29 13:04 ` Eli Zaretskii 2024-10-29 13:54 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-29 13:04 UTC (permalink / raw) To: Visuwesh; +Cc: luangruo, 73752, xuan > From: Visuwesh <visuweshm@gmail.com> > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Tue, 29 Oct 2024 16:29:48 +0530 > > >> Is this hash dependent on the font driver? > > > > No. Only the font used for the composed characters is recorded, not > > the font backend which opened it. But fonts are managed by the font > > backend, so maybe there's some leakage by that way. > > OK, thanks. I wonder if we could compare the value returned by > font-info if something has gone wrong with the font object used to > compute the hash for the glyph? That would not be the first thing I'd look at. According to the screenshots, it is more likely that a wrong cache entry is used for a composition, which uses the "wrong" font variant. IOW, the font used itself is fine, it just is not the font that's supposed to be used with the composed characters in that place. So I would first look at the font object stored in the header of the cached composition. > > Btw, how frequently do you use different frames, > > Quite often, I would say. I usually have two frames but it can go > upwards of 5 to 6 if I have a mouse attached to my laptop. > > > and how likely are you to have different definitions for the same > > faces on different frames in the same Emacs session at the same time? > > I don't quite understand this question. Are you asking if I have any > "frame-specific" face attributes i.e., non-nil FRAME argument in > set-face-attribute? Yes. > If so, no. OK, so one more theory eats dust (we don't record the frame in the composition cache). > > The only way I see to investigate this is to wait for this to happen, > > then attach GDB to Emacs and look at the problematic compositions in > > the cache, comparing them to the corresponding compositions in a fresh > > Emacs session. I can tell what to look for with GDB, if that helps. > > That would help. But given how hard it is to reproduce this issue on my > end, I don't know when I can get back... It would not be useful for me to give instructions before you actually hit the problem (because the code will change until then), so if you want to try this, get back to me when you do reproduce the problem (and then attach GDB and leave the Emacs session under GDB for any investigations I'd ask you to do). Thanks. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 13:04 ` Eli Zaretskii @ 2024-10-29 13:54 ` Visuwesh 2024-10-29 14:00 ` Visuwesh 2024-10-29 15:38 ` Eli Zaretskii 0 siblings, 2 replies; 90+ messages in thread From: Visuwesh @ 2024-10-29 13:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [-- Attachment #1: Type: text/plain, Size: 2787 bytes --] [செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Tue, 29 Oct 2024 16:29:48 +0530 >> >> >> Is this hash dependent on the font driver? >> > >> > No. Only the font used for the composed characters is recorded, not >> > the font backend which opened it. But fonts are managed by the font >> > backend, so maybe there's some leakage by that way. >> >> OK, thanks. I wonder if we could compare the value returned by >> font-info if something has gone wrong with the font object used to >> compute the hash for the glyph? > > That would not be the first thing I'd look at. According to the > screenshots, it is more likely that a wrong cache entry is used for a > composition, which uses the "wrong" font variant. IOW, the font used > itself is fine, it just is not the font that's supposed to be used > with the composed characters in that place. > > So I would first look at the font object stored in the header of the > cached composition. > >> > Btw, how frequently do you use different frames, >> >> Quite often, I would say. I usually have two frames but it can go >> upwards of 5 to 6 if I have a mouse attached to my laptop. >> >> > and how likely are you to have different definitions for the same >> > faces on different frames in the same Emacs session at the same time? >> >> I don't quite understand this question. Are you asking if I have any >> "frame-specific" face attributes i.e., non-nil FRAME argument in >> set-face-attribute? > > Yes. > >> If so, no. > > OK, so one more theory eats dust (we don't record the frame in the > composition cache). > >> > The only way I see to investigate this is to wait for this to happen, >> > then attach GDB to Emacs and look at the problematic compositions in >> > the cache, comparing them to the corresponding compositions in a fresh >> > Emacs session. I can tell what to look for with GDB, if that helps. >> >> That would help. But given how hard it is to reproduce this issue on my >> end, I don't know when I can get back... > > It would not be useful for me to give instructions before you actually > hit the problem (because the code will change until then), so if you > want to try this, get back to me when you do reproduce the problem > (and then attach GDB and leave the Emacs session under GDB for any > investigations I'd ask you to do). I seem to have run into the issue. The attached images "cascadia-code-bold-15-good" and "-bad.png" are the desired and misaligned composite text of "-->" rendered in Cascadia Code bold 15 font. The same text is composed fine with Cascadia Code bold 17. [-- Attachment #2: cascadia-bold-15-good.png --] [-- Type: image/png, Size: 636 bytes --] [-- Attachment #3: cascadia-bold-15-bad.png --] [-- Type: image/png, Size: 632 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 13:54 ` Visuwesh @ 2024-10-29 14:00 ` Visuwesh 2024-10-29 15:38 ` Eli Zaretskii 1 sibling, 0 replies; 90+ messages in thread From: Visuwesh @ 2024-10-29 14:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [செவ்வாய் அக்டோபர் 29, 2024] Visuwesh wrote: Just to make myself clear, the "good" image is from a fresh emacs -Q session. I still have the "bad" one open. > [செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote: > >>> From: Visuwesh <visuweshm@gmail.com> >>> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >>> Date: Tue, 29 Oct 2024 16:29:48 +0530 >>> >>> >> Is this hash dependent on the font driver? >>> > >>> > No. Only the font used for the composed characters is recorded, not >>> > the font backend which opened it. But fonts are managed by the font >>> > backend, so maybe there's some leakage by that way. >>> >>> OK, thanks. I wonder if we could compare the value returned by >>> font-info if something has gone wrong with the font object used to >>> compute the hash for the glyph? >> >> That would not be the first thing I'd look at. According to the >> screenshots, it is more likely that a wrong cache entry is used for a >> composition, which uses the "wrong" font variant. IOW, the font used >> itself is fine, it just is not the font that's supposed to be used >> with the composed characters in that place. >> >> So I would first look at the font object stored in the header of the >> cached composition. >> >>> > Btw, how frequently do you use different frames, >>> >>> Quite often, I would say. I usually have two frames but it can go >>> upwards of 5 to 6 if I have a mouse attached to my laptop. >>> >>> > and how likely are you to have different definitions for the same >>> > faces on different frames in the same Emacs session at the same time? >>> >>> I don't quite understand this question. Are you asking if I have any >>> "frame-specific" face attributes i.e., non-nil FRAME argument in >>> set-face-attribute? >> >> Yes. >> >>> If so, no. >> >> OK, so one more theory eats dust (we don't record the frame in the >> composition cache). >> >>> > The only way I see to investigate this is to wait for this to happen, >>> > then attach GDB to Emacs and look at the problematic compositions in >>> > the cache, comparing them to the corresponding compositions in a fresh >>> > Emacs session. I can tell what to look for with GDB, if that helps. >>> >>> That would help. But given how hard it is to reproduce this issue on my >>> end, I don't know when I can get back... >> >> It would not be useful for me to give instructions before you actually >> hit the problem (because the code will change until then), so if you >> want to try this, get back to me when you do reproduce the problem >> (and then attach GDB and leave the Emacs session under GDB for any >> investigations I'd ask you to do). > > I seem to have run into the issue. The attached images > "cascadia-code-bold-15-good" and "-bad.png" are the desired and > misaligned composite text of "-->" rendered in Cascadia Code bold 15 > font. The same text is composed fine with Cascadia Code bold 17. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 13:54 ` Visuwesh 2024-10-29 14:00 ` Visuwesh @ 2024-10-29 15:38 ` Eli Zaretskii 2024-10-29 16:46 ` Visuwesh 2024-10-29 16:51 ` Eli Zaretskii 1 sibling, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-29 15:38 UTC (permalink / raw) To: Visuwesh; +Cc: luangruo, 73752, xuan > From: Visuwesh <visuweshm@gmail.com> > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Tue, 29 Oct 2024 19:24:26 +0530 > > I seem to have run into the issue. The attached images > "cascadia-code-bold-15-good" and "-bad.png" are the desired and > misaligned composite text of "-->" rendered in Cascadia Code bold 15 > font. The same text is composed fine with Cascadia Code bold 17. I'm not sure this is the same issue we are talking about, but here are the instructions anyway: . Move the cursor to where this ligature is displayed . Use "C-x =" to display the buffer position of the ligature . Attaching GDB to Emacs, then type these commands: (gdb) source /path/to/emacs/src/.gdbinit (gdb) thread 1 (gdb) break set_cursor_from_row (gdb) continue The breakpoint in set_cursor_from_row will break soon enough. The first time it breaks, just type "continue". Second time it breaks, type: (gdb) pgrow This will show you the entire screen line (a.k.a. "glyph row") where the cursor is displayed, which is also the screen line of the ligature. Here's how a similar line with ligatures looks here: (gdb) pgrow TEXT: 80 glyphs 0 0: CHAR[ ] pos=857 blev=0,btyp=L w=9 a+d=17+4 MB 1 9: CHAR[ ] pos=858 blev=0,btyp=L w=9 a+d=17+4 MB 2 18: CHAR[ ] pos=859 blev=0,btyp=L w=9 a+d=17+4 MB 3 27: CHAR[ ] pos=860 blev=0,btyp=L w=9 a+d=17+4 MB 4 36: CHAR[ ] pos=861 blev=0,btyp=L w=9 a+d=17+4 MB 5 45: CHAR[ ] pos=862 blev=0,btyp=L w=9 a+d=17+4 MB 6 54: CHAR[ ] pos=863 blev=0,btyp=L w=9 a+d=17+4 MB 7 63: CHAR[ ] pos=864 blev=0,btyp=L w=9 a+d=17+4 MB 8 72: CHAR[ ] pos=865 blev=0,btyp=L w=9 a+d=17+4 MB 9 81: CHAR[ ] pos=866 blev=0,btyp=L w=9 a+d=17+4 MB 10 90: CHAR[ ] pos=867 blev=0,btyp=L w=9 a+d=17+4 MB 11 99: CHAR[ ] pos=868 blev=0,btyp=L w=9 a+d=17+4 MB 12 108: CHAR[ ] pos=869 blev=0,btyp=L w=9 a+d=17+4 MB 13 117: CHAR[ ] pos=870 blev=0,btyp=L w=9 a+d=17+4 MB 14 126: CHAR[ ] pos=871 blev=0,btyp=L w=9 a+d=17+4 MB 15 135: CHAR[ ] pos=872 blev=0,btyp=L w=9 a+d=17+4 MB 16 144: CHAR[ ] pos=873 blev=0,btyp=L w=9 a+d=17+4 MB 17 153: CHAR[ ] pos=874 blev=0,btyp=L w=9 a+d=17+4 MB 18 162: CHAR[ ] pos=875 blev=0,btyp=L w=9 a+d=17+4 MB 19 171: CHAR[ ] pos=876 blev=0,btyp=L w=9 a+d=17+4 MB 20 180: CHAR[ ] pos=877 blev=0,btyp=L w=9 a+d=17+4 MB 21 189: CHAR[ ] pos=878 blev=0,btyp=L w=9 a+d=17+4 MB 22 198: CHAR[ ] pos=879 blev=0,btyp=L w=9 a+d=17+4 MB 23 207: CHAR[ ] pos=880 blev=0,btyp=L w=9 a+d=17+4 MB 24 216: CHAR[ ] pos=881 blev=0,btyp=L w=9 a+d=17+4 MB 25 225: CHAR[ ] pos=882 blev=0,btyp=L w=9 a+d=17+4 MB 26 234: CHAR[ ] pos=883 blev=0,btyp=L w=9 a+d=17+4 MB 27 243: CHAR[ ] pos=884 blev=0,btyp=L w=9 a+d=17+4 MB 28 252: CHAR[ ] pos=885 blev=0,btyp=L w=9 a+d=17+4 MB 29 261: CHAR[ ] pos=886 blev=0,btyp=L w=9 a+d=17+4 MB 30 270: CHAR["] pos=887 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 31 279: COMP[69 (0..0)] pos=888 w=9 a+d=17+4 face=24 MB 32 288: COMP[69 (1..1)] pos=889 w=9 a+d=17+4 face=24 MB 33 297: COMP[69 (2..2)] pos=890 w=9 a+d=17+4 face=24 MB 34 306: CHAR["] pos=891 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 35 315: CHAR[ ] pos=892 blev=0,btyp=L w=9 a+d=17+4 MB 36 324: CHAR["] pos=893 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 37 333: COMP[70 (0..0)] pos=894 w=9 a+d=17+4 face=24 MB 38 342: COMP[70 (1..1)] pos=895 w=9 a+d=17+4 face=24 MB 39 351: CHAR["] pos=896 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 40 360: CHAR[ ] pos=897 blev=0,btyp=L w=9 a+d=17+4 MB 41 369: CHAR["] pos=898 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 42 378: COMP[71 (0..0)] pos=899 w=9 a+d=17+4 face=24 MB 43 387: COMP[71 (1..1)] pos=900 w=9 a+d=17+4 face=24 MB 44 396: COMP[71 (2..2)] pos=901 w=9 a+d=17+4 face=24 MB 45 405: CHAR["] pos=902 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 46 414: CHAR[ ] pos=903 blev=0,btyp=L w=9 a+d=17+4 MB 47 423: CHAR["] pos=904 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 48 432: COMP[72 (0..0)] pos=905 w=9 a+d=17+4 face=24 MB 49 441: COMP[72 (1..1)] pos=906 w=9 a+d=17+4 face=24 MB 50 450: COMP[72 (2..2)] pos=907 w=9 a+d=17+4 face=24 MB 51 459: CHAR["] pos=908 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 52 468: CHAR[ ] pos=909 blev=0,btyp=L w=9 a+d=17+4 MB 53 477: CHAR["] pos=910 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 54 486: COMP[73 (0..0)] pos=911 w=9 a+d=17+4 face=24 MB 55 495: COMP[73 (1..1)] pos=912 w=9 a+d=17+4 face=24 MB 56 504: CHAR["] pos=913 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 57 513: CHAR[ ] pos=914 blev=0,btyp=L w=9 a+d=17+4 MB 58 522: CHAR["] pos=915 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 59 531: COMP[74 (0..0)] pos=916 w=9 a+d=17+4 face=24 MB 60 540: COMP[74 (1..1)] pos=917 w=9 a+d=17+4 face=24 MB 61 549: COMP[74 (2..2)] pos=918 w=9 a+d=17+4 face=24 MB 62 558: CHAR["] pos=919 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 63 567: CHAR[ ] pos=920 blev=0,btyp=L w=9 a+d=17+4 MB 64 576: CHAR["] pos=921 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 65 585: COMP[75 (0..0)] pos=922 w=9 a+d=17+4 face=24 MB 66 594: COMP[75 (1..1)] pos=923 w=9 a+d=17+4 face=24 MB 67 603: COMP[75 (2..2)] pos=924 w=9 a+d=17+4 face=24 MB 68 612: CHAR["] pos=925 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 69 621: CHAR[ ] pos=926 blev=0,btyp=L w=9 a+d=17+4 MB 70 630: CHAR["] pos=927 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 71 639: COMP[76 (0..0)] pos=928 w=9 a+d=17+4 face=24 MB 72 648: COMP[76 (1..1)] pos=929 w=9 a+d=17+4 face=24 MB 73 657: COMP[76 (2..2)] pos=930 w=9 a+d=17+4 face=24 MB 74 666: CHAR["] pos=931 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 75 675: CHAR[ ] pos=932 blev=0,btyp=L w=9 a+d=17+4 MB 76 684: CHAR["] pos=933 blev=0,btyp=L w=9 a+d=17+4 face=23 MB 77 693: COMP[77 (0..0)] pos=934 w=9 a+d=17+4 face=24 MB 78 702: COMP[77 (1..1)] pos=935 w=9 a+d=17+4 face=24 MB 79 711: COMP[77 (2..2)] pos=936 w=9 a+d=17+4 face=24 MB Each line here describes a glyph on display. Where it says "CHAR[X]", that's a character glyph of character X. Where it says "COMP[n (i..j)]", that's a composition whose cached ID is n, and i and j are the characters in the composed sequence represented by this glyph. The "pos=NNNN" part is the buffer position from where each glyph came. Find the cache ID of the composition which shows the problematic ligature by its buffer position which you displayed at the beginning. Let's assume that the ID of that composition is 69 (from the glyph row shown above). Then type: (gdb) pp composition_gstring_from_id(69) This will show the composition cached at slot 116. The structure of the composition is described in the doc string of composition-get-gstring. Here's what I get here for the ligature cached at slot 69: (gdb) pp composition_gstring_from_id(69) [[#<font-object "-outline-Cascadia Code-regular-normal-normal-mono-16-*-*-*-c-*-iso8859-1"> 45 45 62] 69 [0 0 45 1970 9 1 10 17 4 nil] [1 1 45 1969 9 0 10 17 4 nil] [2 2 62 2728 9 0 9 17 4 nil]] It clearly shows the font used to display the 3 glyphs of this ligature and the data of the 3 glyphs themselves. The idea is then to compare what you get from the "bad" display with what you get for the same ligature in a fresh Emacs session, where the display should be good. Let me know if you need more help or more detailed instructions or have questions. Thanks. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 15:38 ` Eli Zaretskii @ 2024-10-29 16:46 ` Visuwesh 2024-10-29 17:45 ` Eli Zaretskii 2024-10-29 16:51 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-10-29 16:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Tue, 29 Oct 2024 19:24:26 +0530 >> >> I seem to have run into the issue. The attached images >> "cascadia-code-bold-15-good" and "-bad.png" are the desired and >> misaligned composite text of "-->" rendered in Cascadia Code bold 15 >> font. The same text is composed fine with Cascadia Code bold 17. > > I'm not sure this is the same issue we are talking about, but here are > the instructions anyway: > > . Move the cursor to where this ligature is displayed > . Use "C-x =" to display the buffer position of the ligature > . Attaching GDB to Emacs, then type these commands: > > (gdb) source /path/to/emacs/src/.gdbinit > (gdb) thread 1 > (gdb) break set_cursor_from_row > (gdb) continue > > The breakpoint in set_cursor_from_row will break soon enough. The > first time it breaks, just type "continue". Second time it breaks, > type: > > (gdb) pgrow > > This will show you the entire screen line (a.k.a. "glyph row") where > the cursor is displayed, which is also the screen line of the > ligature. Here's how a similar line with ligatures looks here: > > (gdb) pgrow > TEXT: 80 glyphs > 0 0: CHAR[ ] pos=857 blev=0,btyp=L w=9 a+d=17+4 MB > 1 9: CHAR[ ] pos=858 blev=0,btyp=L w=9 a+d=17+4 MB > 2 18: CHAR[ ] pos=859 blev=0,btyp=L w=9 a+d=17+4 MB > 3 27: CHAR[ ] pos=860 blev=0,btyp=L w=9 a+d=17+4 MB > 4 36: CHAR[ ] pos=861 blev=0,btyp=L w=9 a+d=17+4 MB > 5 45: CHAR[ ] pos=862 blev=0,btyp=L w=9 a+d=17+4 MB > 6 54: CHAR[ ] pos=863 blev=0,btyp=L w=9 a+d=17+4 MB > 7 63: CHAR[ ] pos=864 blev=0,btyp=L w=9 a+d=17+4 MB > 8 72: CHAR[ ] pos=865 blev=0,btyp=L w=9 a+d=17+4 MB > 9 81: CHAR[ ] pos=866 blev=0,btyp=L w=9 a+d=17+4 MB > 10 90: CHAR[ ] pos=867 blev=0,btyp=L w=9 a+d=17+4 MB > 11 99: CHAR[ ] pos=868 blev=0,btyp=L w=9 a+d=17+4 MB > 12 108: CHAR[ ] pos=869 blev=0,btyp=L w=9 a+d=17+4 MB > 13 117: CHAR[ ] pos=870 blev=0,btyp=L w=9 a+d=17+4 MB > 14 126: CHAR[ ] pos=871 blev=0,btyp=L w=9 a+d=17+4 MB > 15 135: CHAR[ ] pos=872 blev=0,btyp=L w=9 a+d=17+4 MB > 16 144: CHAR[ ] pos=873 blev=0,btyp=L w=9 a+d=17+4 MB > 17 153: CHAR[ ] pos=874 blev=0,btyp=L w=9 a+d=17+4 MB > 18 162: CHAR[ ] pos=875 blev=0,btyp=L w=9 a+d=17+4 MB > 19 171: CHAR[ ] pos=876 blev=0,btyp=L w=9 a+d=17+4 MB > 20 180: CHAR[ ] pos=877 blev=0,btyp=L w=9 a+d=17+4 MB > 21 189: CHAR[ ] pos=878 blev=0,btyp=L w=9 a+d=17+4 MB > 22 198: CHAR[ ] pos=879 blev=0,btyp=L w=9 a+d=17+4 MB > 23 207: CHAR[ ] pos=880 blev=0,btyp=L w=9 a+d=17+4 MB > 24 216: CHAR[ ] pos=881 blev=0,btyp=L w=9 a+d=17+4 MB > 25 225: CHAR[ ] pos=882 blev=0,btyp=L w=9 a+d=17+4 MB > 26 234: CHAR[ ] pos=883 blev=0,btyp=L w=9 a+d=17+4 MB > 27 243: CHAR[ ] pos=884 blev=0,btyp=L w=9 a+d=17+4 MB > 28 252: CHAR[ ] pos=885 blev=0,btyp=L w=9 a+d=17+4 MB > 29 261: CHAR[ ] pos=886 blev=0,btyp=L w=9 a+d=17+4 MB > 30 270: CHAR["] pos=887 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 31 279: COMP[69 (0..0)] pos=888 w=9 a+d=17+4 face=24 MB > 32 288: COMP[69 (1..1)] pos=889 w=9 a+d=17+4 face=24 MB > 33 297: COMP[69 (2..2)] pos=890 w=9 a+d=17+4 face=24 MB > 34 306: CHAR["] pos=891 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 35 315: CHAR[ ] pos=892 blev=0,btyp=L w=9 a+d=17+4 MB > 36 324: CHAR["] pos=893 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 37 333: COMP[70 (0..0)] pos=894 w=9 a+d=17+4 face=24 MB > 38 342: COMP[70 (1..1)] pos=895 w=9 a+d=17+4 face=24 MB > 39 351: CHAR["] pos=896 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 40 360: CHAR[ ] pos=897 blev=0,btyp=L w=9 a+d=17+4 MB > 41 369: CHAR["] pos=898 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 42 378: COMP[71 (0..0)] pos=899 w=9 a+d=17+4 face=24 MB > 43 387: COMP[71 (1..1)] pos=900 w=9 a+d=17+4 face=24 MB > 44 396: COMP[71 (2..2)] pos=901 w=9 a+d=17+4 face=24 MB > 45 405: CHAR["] pos=902 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 46 414: CHAR[ ] pos=903 blev=0,btyp=L w=9 a+d=17+4 MB > 47 423: CHAR["] pos=904 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 48 432: COMP[72 (0..0)] pos=905 w=9 a+d=17+4 face=24 MB > 49 441: COMP[72 (1..1)] pos=906 w=9 a+d=17+4 face=24 MB > 50 450: COMP[72 (2..2)] pos=907 w=9 a+d=17+4 face=24 MB > 51 459: CHAR["] pos=908 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 52 468: CHAR[ ] pos=909 blev=0,btyp=L w=9 a+d=17+4 MB > 53 477: CHAR["] pos=910 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 54 486: COMP[73 (0..0)] pos=911 w=9 a+d=17+4 face=24 MB > 55 495: COMP[73 (1..1)] pos=912 w=9 a+d=17+4 face=24 MB > 56 504: CHAR["] pos=913 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 57 513: CHAR[ ] pos=914 blev=0,btyp=L w=9 a+d=17+4 MB > 58 522: CHAR["] pos=915 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 59 531: COMP[74 (0..0)] pos=916 w=9 a+d=17+4 face=24 MB > 60 540: COMP[74 (1..1)] pos=917 w=9 a+d=17+4 face=24 MB > 61 549: COMP[74 (2..2)] pos=918 w=9 a+d=17+4 face=24 MB > 62 558: CHAR["] pos=919 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 63 567: CHAR[ ] pos=920 blev=0,btyp=L w=9 a+d=17+4 MB > 64 576: CHAR["] pos=921 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 65 585: COMP[75 (0..0)] pos=922 w=9 a+d=17+4 face=24 MB > 66 594: COMP[75 (1..1)] pos=923 w=9 a+d=17+4 face=24 MB > 67 603: COMP[75 (2..2)] pos=924 w=9 a+d=17+4 face=24 MB > 68 612: CHAR["] pos=925 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 69 621: CHAR[ ] pos=926 blev=0,btyp=L w=9 a+d=17+4 MB > 70 630: CHAR["] pos=927 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 71 639: COMP[76 (0..0)] pos=928 w=9 a+d=17+4 face=24 MB > 72 648: COMP[76 (1..1)] pos=929 w=9 a+d=17+4 face=24 MB > 73 657: COMP[76 (2..2)] pos=930 w=9 a+d=17+4 face=24 MB > 74 666: CHAR["] pos=931 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 75 675: CHAR[ ] pos=932 blev=0,btyp=L w=9 a+d=17+4 MB > 76 684: CHAR["] pos=933 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > 77 693: COMP[77 (0..0)] pos=934 w=9 a+d=17+4 face=24 MB > 78 702: COMP[77 (1..1)] pos=935 w=9 a+d=17+4 face=24 MB > 79 711: COMP[77 (2..2)] pos=936 w=9 a+d=17+4 face=24 MB > > Each line here describes a glyph on display. Where it says "CHAR[X]", > that's a character glyph of character X. Where it says > "COMP[n (i..j)]", that's a composition whose cached ID is n, and i and > j are the characters in the composed sequence represented by this > glyph. > > The "pos=NNNN" part is the buffer position from where each glyph came. > > Find the cache ID of the composition which shows the problematic > ligature by its buffer position which you displayed at the beginning. > Let's assume that the ID of that composition is 69 (from the glyph > row shown above). Then type: > > (gdb) pp composition_gstring_from_id(69) > > This will show the composition cached at slot 116. The structure of > the composition is described in the doc string of > composition-get-gstring. Here's what I get here for the ligature > cached at slot 69: > > (gdb) pp composition_gstring_from_id(69) > [[#<font-object "-outline-Cascadia Code-regular-normal-normal-mono-16-*-*-*-c-*-iso8859-1"> 45 45 62] 69 [0 0 45 1970 9 1 10 17 4 nil] [1 1 45 1969 9 0 10 17 4 nil] [2 2 62 2728 9 0 9 17 4 nil]] > > It clearly shows the font used to display the 3 glyphs of this > ligature and the data of the 3 glyphs themselves. > > The idea is then to compare what you get from the "bad" display with > what you get for the same ligature in a fresh Emacs session, where the > display should be good. > > Let me know if you need more help or more detailed instructions or > have questions. > > Thanks. Thank you very much for the clear instructions. I was testing this in a fresh Emacs session. And (gdb) pp composition_gstring_from_id(ID) seems to show nothing? (gdb) c Continuing. Thread 1 "emacs" hit Breakpoint 3, set_cursor_from_row (w=0x55b8c994f338, row=0x55b8c9e20410, matrix=0x55b8c9960480, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:18217 18217 struct glyph *glyph = row->glyphs[TEXT_AREA]; (gdb) pgrow TEXT: 4 glyphs 0 0: COMP[16 (0..0)] pos=5 w=9 a+d=14+4 face=28 MB 1 9: COMP[16 (1..1)] pos=6 w=9 a+d=14+4 face=28 MB 2 18: COMP[16 (2..2)] pos=7 w=9 a+d=14+4 face=28 MB 3 27: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=14+4 MB (gdb) pp composition_gstring_from_id(16) (gdb) p composition_gstring_from_id(16) $1 = XIL(0x55b8cada607d) Am I missing something? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 16:46 ` Visuwesh @ 2024-10-29 17:45 ` Eli Zaretskii 2024-10-30 5:43 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-29 17:45 UTC (permalink / raw) To: Visuwesh; +Cc: luangruo, 73752, xuan > From: Visuwesh <visuweshm@gmail.com> > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Tue, 29 Oct 2024 22:16:01 +0530 > > [செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote: > > >> From: Visuwesh <visuweshm@gmail.com> > >> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > >> Date: Tue, 29 Oct 2024 19:24:26 +0530 > >> > >> I seem to have run into the issue. The attached images > >> "cascadia-code-bold-15-good" and "-bad.png" are the desired and > >> misaligned composite text of "-->" rendered in Cascadia Code bold 15 > >> font. The same text is composed fine with Cascadia Code bold 17. > > > > I'm not sure this is the same issue we are talking about, but here are > > the instructions anyway: > > > > . Move the cursor to where this ligature is displayed > > . Use "C-x =" to display the buffer position of the ligature > > . Attaching GDB to Emacs, then type these commands: > > > > (gdb) source /path/to/emacs/src/.gdbinit > > (gdb) thread 1 > > (gdb) break set_cursor_from_row > > (gdb) continue > > > > The breakpoint in set_cursor_from_row will break soon enough. The > > first time it breaks, just type "continue". Second time it breaks, > > type: > > > > (gdb) pgrow > > > > This will show you the entire screen line (a.k.a. "glyph row") where > > the cursor is displayed, which is also the screen line of the > > ligature. Here's how a similar line with ligatures looks here: > > > > (gdb) pgrow > > TEXT: 80 glyphs > > 0 0: CHAR[ ] pos=857 blev=0,btyp=L w=9 a+d=17+4 MB > > 1 9: CHAR[ ] pos=858 blev=0,btyp=L w=9 a+d=17+4 MB > > 2 18: CHAR[ ] pos=859 blev=0,btyp=L w=9 a+d=17+4 MB > > 3 27: CHAR[ ] pos=860 blev=0,btyp=L w=9 a+d=17+4 MB > > 4 36: CHAR[ ] pos=861 blev=0,btyp=L w=9 a+d=17+4 MB > > 5 45: CHAR[ ] pos=862 blev=0,btyp=L w=9 a+d=17+4 MB > > 6 54: CHAR[ ] pos=863 blev=0,btyp=L w=9 a+d=17+4 MB > > 7 63: CHAR[ ] pos=864 blev=0,btyp=L w=9 a+d=17+4 MB > > 8 72: CHAR[ ] pos=865 blev=0,btyp=L w=9 a+d=17+4 MB > > 9 81: CHAR[ ] pos=866 blev=0,btyp=L w=9 a+d=17+4 MB > > 10 90: CHAR[ ] pos=867 blev=0,btyp=L w=9 a+d=17+4 MB > > 11 99: CHAR[ ] pos=868 blev=0,btyp=L w=9 a+d=17+4 MB > > 12 108: CHAR[ ] pos=869 blev=0,btyp=L w=9 a+d=17+4 MB > > 13 117: CHAR[ ] pos=870 blev=0,btyp=L w=9 a+d=17+4 MB > > 14 126: CHAR[ ] pos=871 blev=0,btyp=L w=9 a+d=17+4 MB > > 15 135: CHAR[ ] pos=872 blev=0,btyp=L w=9 a+d=17+4 MB > > 16 144: CHAR[ ] pos=873 blev=0,btyp=L w=9 a+d=17+4 MB > > 17 153: CHAR[ ] pos=874 blev=0,btyp=L w=9 a+d=17+4 MB > > 18 162: CHAR[ ] pos=875 blev=0,btyp=L w=9 a+d=17+4 MB > > 19 171: CHAR[ ] pos=876 blev=0,btyp=L w=9 a+d=17+4 MB > > 20 180: CHAR[ ] pos=877 blev=0,btyp=L w=9 a+d=17+4 MB > > 21 189: CHAR[ ] pos=878 blev=0,btyp=L w=9 a+d=17+4 MB > > 22 198: CHAR[ ] pos=879 blev=0,btyp=L w=9 a+d=17+4 MB > > 23 207: CHAR[ ] pos=880 blev=0,btyp=L w=9 a+d=17+4 MB > > 24 216: CHAR[ ] pos=881 blev=0,btyp=L w=9 a+d=17+4 MB > > 25 225: CHAR[ ] pos=882 blev=0,btyp=L w=9 a+d=17+4 MB > > 26 234: CHAR[ ] pos=883 blev=0,btyp=L w=9 a+d=17+4 MB > > 27 243: CHAR[ ] pos=884 blev=0,btyp=L w=9 a+d=17+4 MB > > 28 252: CHAR[ ] pos=885 blev=0,btyp=L w=9 a+d=17+4 MB > > 29 261: CHAR[ ] pos=886 blev=0,btyp=L w=9 a+d=17+4 MB > > 30 270: CHAR["] pos=887 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 31 279: COMP[69 (0..0)] pos=888 w=9 a+d=17+4 face=24 MB > > 32 288: COMP[69 (1..1)] pos=889 w=9 a+d=17+4 face=24 MB > > 33 297: COMP[69 (2..2)] pos=890 w=9 a+d=17+4 face=24 MB > > 34 306: CHAR["] pos=891 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 35 315: CHAR[ ] pos=892 blev=0,btyp=L w=9 a+d=17+4 MB > > 36 324: CHAR["] pos=893 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 37 333: COMP[70 (0..0)] pos=894 w=9 a+d=17+4 face=24 MB > > 38 342: COMP[70 (1..1)] pos=895 w=9 a+d=17+4 face=24 MB > > 39 351: CHAR["] pos=896 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 40 360: CHAR[ ] pos=897 blev=0,btyp=L w=9 a+d=17+4 MB > > 41 369: CHAR["] pos=898 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 42 378: COMP[71 (0..0)] pos=899 w=9 a+d=17+4 face=24 MB > > 43 387: COMP[71 (1..1)] pos=900 w=9 a+d=17+4 face=24 MB > > 44 396: COMP[71 (2..2)] pos=901 w=9 a+d=17+4 face=24 MB > > 45 405: CHAR["] pos=902 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 46 414: CHAR[ ] pos=903 blev=0,btyp=L w=9 a+d=17+4 MB > > 47 423: CHAR["] pos=904 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 48 432: COMP[72 (0..0)] pos=905 w=9 a+d=17+4 face=24 MB > > 49 441: COMP[72 (1..1)] pos=906 w=9 a+d=17+4 face=24 MB > > 50 450: COMP[72 (2..2)] pos=907 w=9 a+d=17+4 face=24 MB > > 51 459: CHAR["] pos=908 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 52 468: CHAR[ ] pos=909 blev=0,btyp=L w=9 a+d=17+4 MB > > 53 477: CHAR["] pos=910 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 54 486: COMP[73 (0..0)] pos=911 w=9 a+d=17+4 face=24 MB > > 55 495: COMP[73 (1..1)] pos=912 w=9 a+d=17+4 face=24 MB > > 56 504: CHAR["] pos=913 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 57 513: CHAR[ ] pos=914 blev=0,btyp=L w=9 a+d=17+4 MB > > 58 522: CHAR["] pos=915 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 59 531: COMP[74 (0..0)] pos=916 w=9 a+d=17+4 face=24 MB > > 60 540: COMP[74 (1..1)] pos=917 w=9 a+d=17+4 face=24 MB > > 61 549: COMP[74 (2..2)] pos=918 w=9 a+d=17+4 face=24 MB > > 62 558: CHAR["] pos=919 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 63 567: CHAR[ ] pos=920 blev=0,btyp=L w=9 a+d=17+4 MB > > 64 576: CHAR["] pos=921 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 65 585: COMP[75 (0..0)] pos=922 w=9 a+d=17+4 face=24 MB > > 66 594: COMP[75 (1..1)] pos=923 w=9 a+d=17+4 face=24 MB > > 67 603: COMP[75 (2..2)] pos=924 w=9 a+d=17+4 face=24 MB > > 68 612: CHAR["] pos=925 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 69 621: CHAR[ ] pos=926 blev=0,btyp=L w=9 a+d=17+4 MB > > 70 630: CHAR["] pos=927 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 71 639: COMP[76 (0..0)] pos=928 w=9 a+d=17+4 face=24 MB > > 72 648: COMP[76 (1..1)] pos=929 w=9 a+d=17+4 face=24 MB > > 73 657: COMP[76 (2..2)] pos=930 w=9 a+d=17+4 face=24 MB > > 74 666: CHAR["] pos=931 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 75 675: CHAR[ ] pos=932 blev=0,btyp=L w=9 a+d=17+4 MB > > 76 684: CHAR["] pos=933 blev=0,btyp=L w=9 a+d=17+4 face=23 MB > > 77 693: COMP[77 (0..0)] pos=934 w=9 a+d=17+4 face=24 MB > > 78 702: COMP[77 (1..1)] pos=935 w=9 a+d=17+4 face=24 MB > > 79 711: COMP[77 (2..2)] pos=936 w=9 a+d=17+4 face=24 MB > > > > Each line here describes a glyph on display. Where it says "CHAR[X]", > > that's a character glyph of character X. Where it says > > "COMP[n (i..j)]", that's a composition whose cached ID is n, and i and > > j are the characters in the composed sequence represented by this > > glyph. > > > > The "pos=NNNN" part is the buffer position from where each glyph came. > > > > Find the cache ID of the composition which shows the problematic > > ligature by its buffer position which you displayed at the beginning. > > Let's assume that the ID of that composition is 69 (from the glyph > > row shown above). Then type: > > > > (gdb) pp composition_gstring_from_id(69) > > > > This will show the composition cached at slot 116. The structure of > > the composition is described in the doc string of > > composition-get-gstring. Here's what I get here for the ligature > > cached at slot 69: > > > > (gdb) pp composition_gstring_from_id(69) > > [[#<font-object "-outline-Cascadia Code-regular-normal-normal-mono-16-*-*-*-c-*-iso8859-1"> 45 45 62] 69 [0 0 45 1970 9 1 10 17 4 nil] [1 1 45 1969 9 0 10 17 4 nil] [2 2 62 2728 9 0 9 17 4 nil]] > > > > It clearly shows the font used to display the 3 glyphs of this > > ligature and the data of the 3 glyphs themselves. > > > > The idea is then to compare what you get from the "bad" display with > > what you get for the same ligature in a fresh Emacs session, where the > > display should be good. > > > > Let me know if you need more help or more detailed instructions or > > have questions. > > > > Thanks. > > Thank you very much for the clear instructions. I was testing this in a > fresh Emacs session. And > > (gdb) pp composition_gstring_from_id(ID) > > seems to show nothing? > > (gdb) c > Continuing. > > Thread 1 "emacs" hit Breakpoint 3, set_cursor_from_row (w=0x55b8c994f338, row=0x55b8c9e20410, matrix=0x55b8c9960480, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:18217 > 18217 struct glyph *glyph = row->glyphs[TEXT_AREA]; > (gdb) pgrow > TEXT: 4 glyphs > 0 0: COMP[16 (0..0)] pos=5 w=9 a+d=14+4 face=28 MB > 1 9: COMP[16 (1..1)] pos=6 w=9 a+d=14+4 face=28 MB > 2 18: COMP[16 (2..2)] pos=7 w=9 a+d=14+4 face=28 MB > 3 27: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=14+4 MB > (gdb) pp composition_gstring_from_id(16) > (gdb) p composition_gstring_from_id(16) > $1 = XIL(0x55b8cada607d) > > Am I missing something? Maybe your Emacs is not built with enough debug info? What does this produce: (gdb) p composition_gstring_from_id(16) $1 = XIL(0x55b8cada607d) (gdb) xpr If this doesn't work, either, you will have to decypher XIL(0x55b8cada607d) "by hand", using xvector etc... I can give you instructions for that as well. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 17:45 ` Eli Zaretskii @ 2024-10-30 5:43 ` Visuwesh 0 siblings, 0 replies; 90+ messages in thread From: Visuwesh @ 2024-10-30 5:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 73752, xuan [செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote: >> Thank you very much for the clear instructions. I was testing this in a >> fresh Emacs session. And >> >> (gdb) pp composition_gstring_from_id(ID) >> >> seems to show nothing? >> >> (gdb) c >> Continuing. >> >> Thread 1 "emacs" hit Breakpoint 3, set_cursor_from_row (w=0x55b8c994f338, row=0x55b8c9e20410, matrix=0x55b8c9960480, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:18217 >> 18217 struct glyph *glyph = row->glyphs[TEXT_AREA]; >> (gdb) pgrow >> TEXT: 4 glyphs >> 0 0: COMP[16 (0..0)] pos=5 w=9 a+d=14+4 face=28 MB >> 1 9: COMP[16 (1..1)] pos=6 w=9 a+d=14+4 face=28 MB >> 2 18: COMP[16 (2..2)] pos=7 w=9 a+d=14+4 face=28 MB >> 3 27: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=14+4 MB >> (gdb) pp composition_gstring_from_id(16) >> (gdb) p composition_gstring_from_id(16) >> $1 = XIL(0x55b8cada607d) >> >> Am I missing something? > > Maybe your Emacs is not built with enough debug info? I built a debug version of Emacs specifically for this. ./configure --with-sound=alsa --with-x-toolkit=lucid --without-xaw3d \ --without-gconf --without-libsystemd --with-cairo \ --enable-checking='yes,glyphs' \ --enable-check-lisp-object-type CFLAGS='-O0 -g3' > What does this produce: > > (gdb) p composition_gstring_from_id(16) > $1 = XIL(0x55b8cada607d) > (gdb) xpr > > If this doesn't work, either, you will have to decypher > XIL(0x55b8cada607d) "by hand", using xvector etc... I can give you > instructions for that as well. (gdb) p composition_gstring_from_id(16) $3 = XIL(0x55b8cada607d) (gdb) xpr Lisp_Vectorlike PVEC_NORMAL_VECTOR $4 = (struct Lisp_Vector *) 0x55b8cada6078 {XIL(0x55b8cada60ad), make_fixnum(16), XIL(0x55b8cada60d5), XIL(0x55b8cada612d), XIL(0x55b8cada6185)} So I am guessing we do need to decypher it "by hand"? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 15:38 ` Eli Zaretskii 2024-10-29 16:46 ` Visuwesh @ 2024-10-29 16:51 ` Eli Zaretskii 1 sibling, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-29 16:51 UTC (permalink / raw) To: visuweshm; +Cc: luangruo, 73752, xuan > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Tue, 29 Oct 2024 17:38:07 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > (gdb) pp composition_gstring_from_id(69) > > This will show the composition cached at slot 116. ^^^ Sorry, a typo: that should have been 69, of course, not 116. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-27 17:19 ` Eli Zaretskii 2024-10-27 17:27 ` Eli Zaretskii @ 2024-10-27 17:29 ` Yixuan Chen 1 sibling, 0 replies; 90+ messages in thread From: Yixuan Chen @ 2024-10-27 17:29 UTC (permalink / raw) To: Eli Zaretskii, Visuwesh; +Cc: luangruo, 73752 On 10/27/24 13:19, Eli Zaretskii wrote: > It's quite clear from the image that the "misaligned" line uses a font > with a different slant/weight/height value. If that is the reason, I > guess the problem is with composition caching, but why is that an > issue in real life? Do real-life Lisp programs modify face font > attributes so frequently? It's not about frequency, but probably total number of font face attribute changes. The lisp code I submitted was changing the attributes rapidly just to recreate the problem faster. In real-life, this problem happens with normal emacs configuration, usually within half an hour. For reference, here (https://github.com/LukeXuan/dot-files/tree/e6067ec232ea34e01fb9a1f1a358d1c328d47c50/.config/doom) is my emacs configuration on top of doom. I primarily write LaTeX and Coq and this problem occurs every 30 minutes or so. The solution is to either restart emacs (what I used to do) or disable ligature altogether (what I do now). ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-11 16:18 bug#73752: 29.4; Ligatures are randomly rendered with extra spaces xuan 2024-10-12 8:02 ` Eli Zaretskii @ 2024-10-29 23:14 ` Tim Ruffing 2024-10-30 15:12 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-10-29 23:14 UTC (permalink / raw) To: 73752 I regularly experience yet another "variant" of this bug. Of course, I can't be sure that is has the same cause but except for the exact distortion in the rendering, the circumstances look pretty similar. I've seen the bug for a while, and I did some experiments in the past, but then I got distracted and I didn't find the time to report it properly. In fact, I see this quite often, and the xuan's test script makes this very easy to reproduce for me. Here's all the meaningful information I could gather in the past. I had already posted much of this in the mentioned GitHub issue, but let me repeat here. Also, here a video that demonstrates most the following items: https://github.com/user-attachments/assets/56b15dfc-6467-4785-bf1f-f2cd05f33f04 This was recorded on an old Emacs version (should be 29.1, but I can't vouch for it), but the bug has existed much longer, and I still see it on my currently installed Emacs 31.0.50 (commit 174784). * When I experience that bug, it's not only that there's additional spacing at the end of the ligature, but I see this with additional spacing after every partial "character" of the ligature (e.g., the "===" ligature is rendered rather like "= = = "). For some ligatures, this means that individual components are also misaligned with respect to each other. For example, the "/" in the "!=" (not equal) ligature, which is supposed to strike through the "==" is vertically off. (You can see this exact problem in the right half of line 58 in the video.) * This can happen with all kinds of font changes. So the issue appears to be specific to a what I call I "realized face" with selected slope, weight, etc. (no idea what the proper Emacs term is). Ligatures may be broken in upright but not in italics, or ligatures may be broken in bold but not in normal. Once the face is broken, it stays broken. * In the video, one can see that searching for "=" fixes the broken rendering of the "===" ligature in line 52. Contrary to the previous item, I believe this is *not* due to change in background color, but due to Emacs trying to highlight the individual "=" char. Still, it's interesting to see that this fixes the rendering. (In fact, changing the colors doesn't seem to influence the problem. I suspect that just the shapes are cached but not the colors?) * This one may be a nice for debugging: I use GNOME, and changing the font rendering settings triggers a "re-realization" of the fonts, and this will then fix the issue (again, see the video). One may be tempted to think that this should be a possibility to trigger the bug, but I could never observe this. It always fixed the problem for me, but maybe I was just "lucky". * There doesn't seem to be a way to reproduce this deterministically. I made multiple attempts to find a minimal reproducible config and fooled myself every time. I don't think this is an elisp config thing, I believe it can happen whenever there are ligatures (at least on affected systems). I've also tried multiple fonts (Iosevka, JetBrains Mono, Fira Code...). The video uses Iosevka. * Rebuilding the fontconfig cache with `fc-cache -f` or even `-r` doesn't do anything. `(clear-font-cache)` doesn't do anything (see video below). * Now that I saw this thread, I've also checked (clear-font-cache t) and (clear-composition-thread). These don't help. * If it's broken in one frame, then it's broken also in other frames. * Notably, I also use the pgtk build on wayland. * I have found this on the web, which seems yet another variant (?) of the bug: https://web.archive.org/web/20230226082659/https://www.reddit.com/r/emacs/comments/11c957r/ligatures_character_overlap_and_extreme_squashing/ I've just managed to reproduce this again, and I've attached gdb, but I'm also stuck at pp doesn't displaying: (gdb) pp composition_gstring_from_id(19) (gdb) p composition_gstring_from_id(19) $6 = (struct Lisp_X *) 0x58ad4d938225 (gdb) xpr Lisp_Vectorlike PVEC_NORMAL_VECTOR $7 = (struct Lisp_Vector *) 0x58ad4d938220 {XIL(0x58ad4f32aabd), make_fixnum(19), XIL(0x58ad4d93f8e5), XIL(0x58ad4d93f93d), XIL(0x58ad4d93f995)} I still have the session open. Also happy to rebuild with more debug info enabled, if you tell me how that works. ``` 3.24.43, cairo version 1.18.2) of 2024-09-13 built on tonno.fritz.box Repository revision: 04e8ad6489ebec121ace7ea6d582429a96af8f04 Repository branch: makepkg System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-modules --without-m17n-flt --without-gconf --with-native-compilation=yes --with-xinput2 --with-pgtk --without-xaw3d --with-sound=no --with-tree-sitter --without-gpm --without-compress-install '--program-transform-name=s/\([ec]tags\)/\1.emacs/' 'CFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/home/tim/.cache/pikaur/build/emacs- git/src=/usr/src/debug/emacs-git -flto=auto' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto' 'CXXFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/home/tim/.cache/pikaur/build/emacs- git/src=/usr/src/debug/emacs-git -flto=auto'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB ``` ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-29 23:14 ` Tim Ruffing @ 2024-10-30 15:12 ` Eli Zaretskii 2024-10-30 15:45 ` Eli Zaretskii [not found] ` <mvmikt9zkcq.fsf@suse.de> 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-30 15:12 UTC (permalink / raw) To: Tim Ruffing, Paul Eggert; +Cc: 73752 > From: Tim Ruffing <dev@real-or-random.org> > Date: Wed, 30 Oct 2024 00:14:58 +0100 > > I've just managed to reproduce this again, and I've attached gdb, but > I'm also stuck at pp doesn't displaying: > (gdb) pp composition_gstring_from_id(19) > (gdb) p composition_gstring_from_id(19) > $6 = (struct Lisp_X *) 0x58ad4d938225 > (gdb) xpr > Lisp_Vectorlike > PVEC_NORMAL_VECTOR > $7 = (struct Lisp_Vector *) 0x58ad4d938220 > {XIL(0x58ad4f32aabd), make_fixnum(19), XIL(0x58ad4d93f8e5), > XIL(0x58ad4d93f93d), XIL(0x58ad4d93f995)} Paul, any ideas why pp would fail to work? I never say anything like that, but maybe external-debugging-output doesn't work when GDB is attached to a running Emacs? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 15:12 ` Eli Zaretskii @ 2024-10-30 15:45 ` Eli Zaretskii [not found] ` <mvmikt9zkcq.fsf@suse.de> 1 sibling, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-30 15:45 UTC (permalink / raw) To: Paul Eggert; +Cc: dev, 73752 > Cc: 73752@debbugs.gnu.org > Date: Wed, 30 Oct 2024 17:12:33 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > > From: Tim Ruffing <dev@real-or-random.org> > > Date: Wed, 30 Oct 2024 00:14:58 +0100 > > > > I've just managed to reproduce this again, and I've attached gdb, but > > I'm also stuck at pp doesn't displaying: > > (gdb) pp composition_gstring_from_id(19) > > (gdb) p composition_gstring_from_id(19) > > $6 = (struct Lisp_X *) 0x58ad4d938225 > > (gdb) xpr > > Lisp_Vectorlike > > PVEC_NORMAL_VECTOR > > $7 = (struct Lisp_Vector *) 0x58ad4d938220 > > {XIL(0x58ad4f32aabd), make_fixnum(19), XIL(0x58ad4d93f8e5), > > XIL(0x58ad4d93f93d), XIL(0x58ad4d93f995)} > > Paul, any ideas why pp would fail to work? I never say anything like ^^^ "saw" > that, but maybe external-debugging-output doesn't work when GDB is > attached to a running Emacs? > > > > ^ permalink raw reply [flat|nested] 90+ messages in thread
[parent not found: <mvmikt9zkcq.fsf@suse.de>]
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces [not found] ` <mvmikt9zkcq.fsf@suse.de> @ 2024-10-30 15:47 ` Eli Zaretskii 2024-10-30 17:34 ` Tim Ruffing 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-30 15:47 UTC (permalink / raw) To: Andreas Schwab; +Cc: dev, 73752, eggert > From: Andreas Schwab <schwab@suse.de> > Cc: Tim Ruffing <dev@real-or-random.org>, Paul Eggert <eggert@cs.ucla.edu>, > 73752@debbugs.gnu.org > Date: Wed, 30 Oct 2024 16:22:29 +0100 > > On Okt 30 2024, Eli Zaretskii wrote: > > >> From: Tim Ruffing <dev@real-or-random.org> > >> Date: Wed, 30 Oct 2024 00:14:58 +0100 > >> > >> I've just managed to reproduce this again, and I've attached gdb, but > >> I'm also stuck at pp doesn't displaying: > >> (gdb) pp composition_gstring_from_id(19) > >> (gdb) p composition_gstring_from_id(19) > >> $6 = (struct Lisp_X *) 0x58ad4d938225 > >> (gdb) xpr > >> Lisp_Vectorlike > >> PVEC_NORMAL_VECTOR > >> $7 = (struct Lisp_Vector *) 0x58ad4d938220 > >> {XIL(0x58ad4f32aabd), make_fixnum(19), XIL(0x58ad4d93f8e5), > >> XIL(0x58ad4d93f93d), XIL(0x58ad4d93f995)} > > > > Paul, any ideas why pp would fail to work? I never say anything like > > that, but maybe external-debugging-output doesn't work when GDB is > > attached to a running Emacs? > > pp is calling Emacs to print to its stderr. If that is redirected > somewhere else you won't see the output. That's what I suspected, thanks. So there's no way to use pp when GDB is attached to an Emacs that was not started from a shell prompt? Or can the user do something to make that output show somewhere? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 15:47 ` Eli Zaretskii @ 2024-10-30 17:34 ` Tim Ruffing 2024-10-30 17:46 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-10-30 17:34 UTC (permalink / raw) To: Eli Zaretskii, Andreas Schwab; +Cc: dev, 73752, eggert > > pp is calling Emacs to print to its stderr. If that is redirected > > somewhere else you won't see the output. > Ah, this was the right hint. I'm using emacs in daemon mode, started from systemd, so I can inspect stderr via journalctl. ------ Broken rendering for ligature "===" starting at pos 1290 (emacs happens to be in daemon mode) [...] 39 480: COMP[19 (0..0)] pos=1290 w=20 a+d=20+6 face=39 MB 40 500: COMP[19 (1..1)] pos=1291 w=20 a+d=20+6 face=39 MB 41 520: COMP[19 (2..2)] pos=1292 w=20 a+d=20+6 face=39 MB [...] $ pp composition_gstring_from_id(19) [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]] ------- Proper rendering (emacs happens to be not in daemon mode): 39 390: COMP[13 (0..0)] pos=1290 w=10 a+d=20+6 face=39 MB 40 400: COMP[13 (1..1)] pos=1291 w=10 a+d=20+6 face=39 MB 41 410: COMP[13 (2..2)] pos=1292 w=10 a+d=20+6 face=39 MB $ pp composition_gstring_from_id(13) [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 13 [0 0 61 5852 10 1 11 11 -4 nil] [1 1 61 5896 10 -1 11 11 -4 nil] [2 2 61 5891 10 -1 9 11 -4 nil]] Both sessions are still running. I Hope this helps. Let me know if need more remote hands. Best, Tim ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 17:34 ` Tim Ruffing @ 2024-10-30 17:46 ` Eli Zaretskii 2024-10-30 18:00 ` Tim Ruffing 2024-10-31 8:12 ` Visuwesh 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-30 17:46 UTC (permalink / raw) To: Tim Ruffing; +Cc: dev, Visuwesh, xuan, 73752 > From: Tim Ruffing <dev@real-or-random.org> > Cc: dev@real-or-random.org, eggert@cs.ucla.edu, 73752@debbugs.gnu.org > Date: Wed, 30 Oct 2024 18:34:14 +0100 > > > > > pp is calling Emacs to print to its stderr. If that is redirected > > > somewhere else you won't see the output. > > > > Ah, this was the right hint. I'm using emacs in daemon mode, started > from systemd, so I can inspect stderr via journalctl. > > ------ > > Broken rendering for ligature "===" starting at pos 1290 (emacs happens > to be in daemon mode) > > [...] > 39 480: COMP[19 (0..0)] pos=1290 w=20 a+d=20+6 face=39 MB > 40 500: COMP[19 (1..1)] pos=1291 w=20 a+d=20+6 face=39 MB > 41 520: COMP[19 (2..2)] pos=1292 w=20 a+d=20+6 face=39 MB > [...] > > $ pp composition_gstring_from_id(19) > > [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]] > > ------- > > Proper rendering (emacs happens to be not in daemon mode): > > 39 390: COMP[13 (0..0)] pos=1290 w=10 a+d=20+6 face=39 MB > 40 400: COMP[13 (1..1)] pos=1291 w=10 a+d=20+6 face=39 MB > 41 410: COMP[13 (2..2)] pos=1292 w=10 a+d=20+6 face=39 MB > > $ pp composition_gstring_from_id(13) > > [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 13 [0 0 61 5852 10 1 11 11 -4 nil] [1 1 61 5896 10 -1 11 11 -4 nil] [2 2 61 5891 10 -1 9 11 -4 nil]] > > > Both sessions are still running. I Hope this helps. Let me know if need > more remote hands. Did the "bad" display start from "good" at the beginning of a session? Or did it start from "bad" to begin with? If the former, the next idea is to put a watchpoint on the cached composition in a session with "good" display, and then do whatever it takes to make it "bad", hoping that the watchpoint will break at some point and show us the code which replaces nil with these [X-OFF Y-OFF WADJUST] vectors. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 17:46 ` Eli Zaretskii @ 2024-10-30 18:00 ` Tim Ruffing 2024-10-30 18:57 ` Eli Zaretskii 2024-10-31 8:12 ` Visuwesh 1 sibling, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-10-30 18:00 UTC (permalink / raw) To: Eli Zaretskii, Tim Ruffing; +Cc: 73752, xuan, Visuwesh On Wed, 2024-10-30 at 19:46 +0200, Eli Zaretskii wrote: > > Did the "bad" display start from "good" at the beginning of a > session? Or did it start from "bad" to begin with? I'm rather sure that it started bad from the beginning of the session yesterday. In general, I'm not so sure, unfortunately. (I had disabled ligatures in the past months because this bug was too annoying.) Don't rely on any of this: I can't recall that it ever flipped suddenly from good to bad *when the affected ligatures was in the visible array of the buffer*. But I'm not so sure if this has really never flipped from good to bad during a session, when the ligature was not visible. Perhaps the other reporters have a better memory. Tim ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 18:00 ` Tim Ruffing @ 2024-10-30 18:57 ` Eli Zaretskii 2024-10-31 1:39 ` Tim Ruffing 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-30 18:57 UTC (permalink / raw) To: Tim Ruffing; +Cc: 73752, xuan, visuweshm > From: Tim Ruffing <dev@real-or-random.org> > Cc: 73752@debbugs.gnu.org, Visuwesh <visuweshm@gmail.com>, xuan@xlk.me > Date: Wed, 30 Oct 2024 19:00:17 +0100 > > > > On Wed, 2024-10-30 at 19:46 +0200, Eli Zaretskii wrote: > > > > Did the "bad" display start from "good" at the beginning of a > > session? Or did it start from "bad" to begin with? > > I'm rather sure that it started bad from the beginning of the session > yesterday. > > In general, I'm not so sure, unfortunately. (I had disabled ligatures > in the past months because this bug was too annoying.) Don't rely on > any of this: I can't recall that it ever flipped suddenly from good to > bad *when the affected ligatures was in the visible array of the > buffer*. But I'm not so sure if this has really never flipped from good > to bad during a session, when the ligature was not visible. Then what exactly is the difference between the session with "good" display and the one with the "bad" display? How come they show the same ligature differently? What did you do to make them have different looks? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 18:57 ` Eli Zaretskii @ 2024-10-31 1:39 ` Tim Ruffing 2024-10-31 2:36 ` Yixuan Chen 2024-10-31 9:42 ` Eli Zaretskii 0 siblings, 2 replies; 90+ messages in thread From: Tim Ruffing @ 2024-10-31 1:39 UTC (permalink / raw) To: Eli Zaretskii, Tim Ruffing; +Cc: 73752, xuan, visuweshm On Wed, 2024-10-30 at 20:57 +0200, Eli Zaretskii wrote: > > > Then what exactly is the difference between the session with "good" > display and the one with the "bad" display? How come they show the > same ligature differently? What did you do to make them have > different looks? Nothing (that I'm aware of.) This appears to be non-deterministic. Sometimes it works, sometimes it doesn't. And Yixuan seems to say the same when he says that this looks like race condition. It will still be useful to figure out what sets the [X-OFF Y-OFF WADJUST] vectors instead of nil. After digging into the code a bit, I strongly suspect it's composition_gstring_adjust_zero_width. I'm not sure if I have the time to verify this in the coming days, I'd appreciate if some of the other affected users could give it a try. I'm not claiming that composition_gstring_adjust_zero_width is wrong, but if my theory is right that it sets the vector if and only if the rendering is bad, then we'll be a step further. This function was introduced in cd88f6de4be1f8eba1db038b371d769f584be53b because of bug#50951. AFAIU it is supposed to correct a grapheme width of 0 pixels to 1 pixel, so that won't explain why large spaces are added. But I skimmed bug#50951 and there are some mentions that composition_gstring_adjust_zero_width is supposed to suppress adding the "space width of the font", which is what some people see here, so all of this sounds a bit related. Next question would be why emacs thinks that the grapheme width was zero in the first place. Tim ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-31 1:39 ` Tim Ruffing @ 2024-10-31 2:36 ` Yixuan Chen 2024-10-31 2:46 ` Yixuan Chen 2024-10-31 9:42 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-31 2:36 UTC (permalink / raw) To: Tim Ruffing, Eli Zaretskii; +Cc: 73752, visuweshm On 10/30/24 21:39, Tim Ruffing wrote: > I'm not sure if I have the time to verify this in the coming days, I'd > appreciate if some of the other affected users could give it a try. I'm sorry I wasn't following this thread closely for the last few days. I'm currently busy with a submission due in two weeks so I don't have continuous time to investigate the problem using GDB before Nov. 14. > I can't recall that it ever flipped suddenly from good to > bad *when the affected ligatures was in the visible array of the > buffer*. But I'm not so sure if this has really never flipped from good > to bad during a session, when the ligature was not visible. I'm pretty certain it doesn't happen to a line spontaneously. I usually encounter this behavior (with a probability) when 1. after a font changes, like what the script I submitted did. 2. after switching to a different buffer, even if both buffers contains ligatures and uses the same font/fontset setting (though maybe one of the buffers contains certain characters with bold/italic/etc font attributes, I don't recall it exactly). 3. (maybe) after scrolling down/up the buffer into a position where a line contains ligatures appears. Best, Yixuan ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-31 2:36 ` Yixuan Chen @ 2024-10-31 2:46 ` Yixuan Chen 2024-10-31 7:44 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Yixuan Chen @ 2024-10-31 2:46 UTC (permalink / raw) To: Tim Ruffing, Eli Zaretskii; +Cc: 73752, visuweshm Eli, An idea on reproducibility: if I can build an container image (I don't know if it will work, but the idea is through wayland socket bind mount) or an VM image where emacs can consistently demonstrate the problem, would that be acceptable? That way maybe you can have a first hand experience with the problem. If so, what format do you accept? On 10/30/24 22:36, Yixuan Chen wrote: > On 10/30/24 21:39, Tim Ruffing wrote: >> I'm not sure if I have the time to verify this in the coming days, I'd >> appreciate if some of the other affected users could give it a try. > > I'm sorry I wasn't following this thread closely for the last few days. > I'm currently busy with a submission due in two weeks so I don't have > continuous time to investigate the problem using GDB before Nov. 14. > >> I can't recall that it ever flipped suddenly from good to >> bad *when the affected ligatures was in the visible array of the >> buffer*. But I'm not so sure if this has really never flipped from good >> to bad during a session, when the ligature was not visible. > > I'm pretty certain it doesn't happen to a line spontaneously. I usually > encounter this behavior (with a probability) when > 1. after a font changes, like what the script I submitted did. > 2. after switching to a different buffer, even if both buffers contains > ligatures and uses the same font/fontset setting (though maybe one of > the buffers contains certain characters with bold/italic/etc font > attributes, I don't recall it exactly). > 3. (maybe) after scrolling down/up the buffer into a position where a > line contains ligatures appears. > > Best, > Yixuan ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-31 2:46 ` Yixuan Chen @ 2024-10-31 7:44 ` Eli Zaretskii 0 siblings, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-31 7:44 UTC (permalink / raw) To: Yixuan Chen; +Cc: dev, visuweshm, 73752 > Date: Wed, 30 Oct 2024 22:46:30 -0400 > From: Yixuan Chen <xuan@xlk.me> > Cc: 73752@debbugs.gnu.org, visuweshm@gmail.com > > An idea on reproducibility: if I can build an container image (I don't > know if it will work, but the idea is through wayland socket bind mount) > or an VM image where emacs can consistently demonstrate the problem, > would that be acceptable? I don't think so, no. I have no system where I could run such an image with debugging capabilities I need. Let's try to follow up the information we already uncovered, it might be that we have good leads already. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-31 1:39 ` Tim Ruffing 2024-10-31 2:36 ` Yixuan Chen @ 2024-10-31 9:42 ` Eli Zaretskii 2024-11-01 17:05 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-10-31 9:42 UTC (permalink / raw) To: Tim Ruffing; +Cc: 73752, xuan, visuweshm > From: Tim Ruffing <dev@real-or-random.org> > Cc: 73752@debbugs.gnu.org, visuweshm@gmail.com, xuan@xlk.me > Date: Thu, 31 Oct 2024 02:39:09 +0100 > > > Then what exactly is the difference between the session with "good" > > display and the one with the "bad" display? How come they show the > > same ligature differently? What did you do to make them have > > different looks? > > Nothing (that I'm aware of.) This appears to be non-deterministic. > Sometimes it works, sometimes it doesn't. And Yixuan seems to say the > same when he says that this looks like race condition. If that's the case, we need to understand what causes such a "race condition". Emacs is single-threaded, so it's hard to imagine something like that. > It will still be useful to figure out what sets the [X-OFF Y-OFF > WADJUST] vectors instead of nil. After digging into the code a bit, I > strongly suspect it's composition_gstring_adjust_zero_width. > > I'm not sure if I have the time to verify this in the coming days, I'd > appreciate if some of the other affected users could give it a try. > > I'm not claiming that composition_gstring_adjust_zero_width is wrong, > but if my theory is right that it sets the vector if and only if the > rendering is bad, then we'll be a step further. > > This function was introduced in > cd88f6de4be1f8eba1db038b371d769f584be53b because of bug#50951. AFAIU it > is supposed to correct a grapheme width of 0 pixels to 1 pixel, so that > won't explain why large spaces are added. But I skimmed bug#50951 and > there are some mentions that composition_gstring_adjust_zero_width is > supposed to suppress adding the "space width of the font", which is > what some people see here, so all of this sounds a bit related. Next > question would be why emacs thinks that the grapheme width was zero in > the first place. The way forward would be to set a breakpoint inside the width == 0 condition in that function: if (NILP (glyph) || from != LGLYPH_FROM (glyph)) { eassert (i > 0); Lisp_Object last = LGSTRING_GLYPH (gstring, i - 1); if (width == 0) { if (NILP (LGLYPH_ADJUSTMENT (last))) <<<<<<<<<<<<<<<<<<<<<<<<< LGLYPH_SET_ADJUSTMENT (last, CALLN (Fvector, make_fixnum (0), make_fixnum (0), make_fixnum (LGLYPH_WIDTH (last) + 1))); else ASET (LGLYPH_ADJUSTMENT (last), 2, make_fixnum (LGLYPH_WADJUST (last) + 1)); } and see if it ever breaks in the scenario(s) where you see the corrupted display. In my testing, that breakpoint never breaks, which is consistent with the fact that none of the glyphs we compose have zero width. They don't have zero width in your "broken rendering" case, either: > $ pp composition_gstring_from_id(19) > > [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]] (The width is the 5th component of the glyph vector, and they are all positive there.) Same in the example shown by Visuwesh: > Misaligned: > > [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2231 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]] So there's something we are missing here. Also note that in Visuwesh's case the WADJUST element corresponds to the width of the previous glyph (9 + 1 = 10), but in your case it doesn't (11 + 1 ≠ 20). So this is another mystery. There are a few calls to lglyph-set-adjustment in composite.el, which could be responsible for this. So if the breakpoint inside composition_gstring_adjust_zero_width never breaks in your sessions, either, the next step is to put a watchpoint on the cached composition created by font-shape-gstring and wait for some code to modify the adjustment part. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-31 9:42 ` Eli Zaretskii @ 2024-11-01 17:05 ` Eli Zaretskii 2024-11-02 3:34 ` Tim Ruffing 2024-11-02 10:32 ` Visuwesh 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-11-01 17:05 UTC (permalink / raw) To: dev, visuweshm; +Cc: 73752, xuan > Cc: 73752@debbugs.gnu.org, xuan@xlk.me, visuweshm@gmail.com > Date: Thu, 31 Oct 2024 11:42:12 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > In my testing, that breakpoint never breaks, which is consistent with > the fact that none of the glyphs we compose have zero width. They > don't have zero width in your "broken rendering" case, either: > > > $ pp composition_gstring_from_id(19) > > > > [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]] > > (The width is the 5th component of the glyph vector, and they are all > positive there.) Same in the example shown by Visuwesh: > > > Misaligned: > > > > [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2231 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]] > > So there's something we are missing here. > > Also note that in Visuwesh's case the WADJUST element corresponds to > the width of the previous glyph (9 + 1 = 10), but in your case it > doesn't (11 + 1 ≠ 20). So this is another mystery. > > There are a few calls to lglyph-set-adjustment in composite.el, which > could be responsible for this. So if the breakpoint inside > composition_gstring_adjust_zero_width never breaks in your sessions, > either, the next step is to put a watchpoint on the cached composition > created by font-shape-gstring and wait for some code to modify the > adjustment part. Btw, is your Emacs built with only HarfBuz, or with both HarfBuz and m17n-flt? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-01 17:05 ` Eli Zaretskii @ 2024-11-02 3:34 ` Tim Ruffing 2024-11-02 9:52 ` Eli Zaretskii 2024-11-02 10:32 ` Visuwesh 1 sibling, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-11-02 3:34 UTC (permalink / raw) To: Eli Zaretskii, dev, visuweshm; +Cc: 73752, xuan [-- Attachment #1: Type: text/plain, Size: 3960 bytes --] Okay, here's what I think is a breakthrough: > > There are a few calls to lglyph-set-adjustment in composite.el, > > which > > could be responsible for this. So if the breakpoint inside > > composition_gstring_adjust_zero_width never breaks in your > > sessions, > > either, the next step is to put a watchpoint on the cached > > composition > > created by font-shape-gstring and wait for some code to modify the > > adjustment part. > Neither the critical line in composition_gstring_adjust_zero_width nor the calls to lglyph-set-adjustment in composite.el are triggered. But this hack in hbfont_shape means I can't reproduce the bug anymore using Yixuan's init file: diff --git a/src/hbfont.c b/src/hbfont.c index 37ed4132492..6fae513069a 100644 --- a/src/hbfont.c +++ b/src/hbfont.c @@ -592,11 +592,12 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction) LGLYPH_SET_ASCENT (lglyph, metrics.ascent); LGLYPH_SET_DESCENT (lglyph, metrics.descent); xoff = lround (pos[i].x_offset * position_unit); yoff = - lround (pos[i].y_offset * position_unit); - wadjust = lround (pos[i].x_advance * position_unit); + /* wadjust = lround (pos[i].x_advance * position_unit); */ + wadjust = metrics.width; if (xoff || yoff || wadjust != metrics.width) LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector, make_fixnum (xoff), make_fixnum (yoff), make_fixnum (wadjust))); Without this patch, what I see with his init file matches his screenshots in the initial bug report (with the same ligatures affected, as far as I can see), namely a single additional "space" at the end of the ligature. Let me note again that this is different from I typically see when I use emacs daily, namely a space after (almost?) every character which is part of the ligature. We may or may not be chasing multiple bugs here. Anyway, I tried adding a printf inside the critical "if" in hbfont.c. This is what I see when the bug triggers: xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 So this is not a rounding error at least. ;) Much more interesting: I can reproduce this only when "enough" (or I guess, the right) ligatures are visible in the buffer. With Yixuan's init file, when I not only load but also visit this init file -- just for testing the rendering, because it contains relevant ligatures -- then I can trigger the bug. But I can't trigger it with a reduced version (that notably doesn't contain arrow ligatures)! Eli, perhaps this is precise enough already so that you can reproduce it? See the attached archive: Use it as init-dir. It contains the init script (but I removed the automatic repeat). Visit bad.el. Press C=# to initialize the font randomization, and then keep pressing C-RET until you hopefully hit the bug. And I can't reproduce the bug with good.el that has fewer ligatures. So it seems that harfbuzz gives different results for some composition depending on the "context", i.e., the other characters (and ligatures?) that appear in the buffer passed to harfbuzz. Is this a bug in harfbuzz? If you still can't reproduce, what's a good way to pretty print the lgstring passed to hbfont_shape? (I'd prefer changing the code, that's a bit easier than gdb, at least for me.) [-- Attachment #2: bug-73752.tar.xz --] [-- Type: application/x-xz-compressed-tar, Size: 6152 bytes --] ^ permalink raw reply related [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 3:34 ` Tim Ruffing @ 2024-11-02 9:52 ` Eli Zaretskii 2024-11-02 10:39 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 9:52 UTC (permalink / raw) To: Tim Ruffing; +Cc: 73752, xuan, visuweshm > From: Tim Ruffing <dev@real-or-random.org> > Cc: 73752@debbugs.gnu.org, xuan@xlk.me > Date: Sat, 02 Nov 2024 04:34:17 +0100 > > Neither the critical line in composition_gstring_adjust_zero_width nor > the calls to lglyph-set-adjustment in composite.el are triggered. But > this hack in hbfont_shape means I can't reproduce the bug anymore using > Yixuan's init file: > > diff --git a/src/hbfont.c b/src/hbfont.c > index 37ed4132492..6fae513069a 100644 > --- a/src/hbfont.c > +++ b/src/hbfont.c > @@ -592,11 +592,12 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object > direction) > LGLYPH_SET_ASCENT (lglyph, metrics.ascent); > LGLYPH_SET_DESCENT (lglyph, metrics.descent); > > xoff = lround (pos[i].x_offset * position_unit); > yoff = - lround (pos[i].y_offset * position_unit); > - wadjust = lround (pos[i].x_advance * position_unit); > + /* wadjust = lround (pos[i].x_advance * position_unit); */ > + wadjust = metrics.width; > if (xoff || yoff || wadjust != metrics.width) > LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector, > make_fixnum (xoff), > make_fixnum (yoff), > make_fixnum (wadjust))); Which leads me to the original suggestion in bug#50951, to do this: diff --git a/src/hbfont.c b/src/hbfont.c index 37ed413..040658a 100644 --- a/src/hbfont.c +++ b/src/hbfont.c @@ -600,6 +600,8 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction) make_fixnum (xoff), make_fixnum (yoff), make_fixnum (wadjust))); + else + LGLYPH_SET_ADJUSTMENT (lglyph, Qnil); } return make_fixnum (glyph_len); In bug#50951, an alternative change in fill_gstring_body was proposed (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50951#97), which was eventually installed, but I guess that might not be enough? Can you and Visuwesh please confirm that we sometimes get an lgstring argument to hbfont_shape whose glyphs already have a non-nil LGLYPH_ADJUSTMENT component, and we leave it unmodified because the condition to use LGLYPH_SET_ADJUSTMENT isn't satisfied? Like this: (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil In my testing, a breakpoint with this condition never breaks. But that could be because I use a different font (Cascadia Code, instead of JetBrains Mono, which I don't have), or because my version of HarfBuzz is much older than yours, or for some other reason. > Anyway, I tried adding a printf inside the critical "if" in hbfont.c. > This is what I see when the bug triggers: > > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 > xoff: 0, yoff: 0, wadjust: 18, metrics.width: 9, pos[i].x_advance * position_unit: 18.000000 And what do you see for LGLYPH_ADJUSTMENT in those cases? are they nil or some non-nil vector? If they are always nil, there's some other factor at work here. > Much more interesting: > I can reproduce this only when "enough" (or I guess, the right) > ligatures are visible in the buffer. With Yixuan's init file, when I > not only load but also visit this init file -- just for testing the > rendering, because it contains relevant ligatures -- then I can trigger > the bug. But I can't trigger it with a reduced version (that notably > doesn't contain arrow ligatures)! Alas, this explains nothing, except that there's some mysterious factor that rears its ugly head only under some unknown conditions. Which is something we already knew. > Eli, perhaps this is precise enough already so that you can reproduce > it? See the attached archive: Use it as init-dir. It contains the init > script (but I removed the automatic repeat). Visit bad.el. Press C=# to > initialize the font randomization, and then keep pressing C-RET until > you hopefully hit the bug. It never happens here, no matter how long I hold C-RET when displaying bad.el. > So it seems that harfbuzz gives different results for some composition > depending on the "context", i.e., the other characters (and ligatures?) > that appear in the buffer passed to harfbuzz. Is this a bug in > harfbuzz? We did not yet capture in GDB even a single case when such "bad" grapheme clusters are produced by HarfBuzz, at the moment of their production. So we don't have a C backtrace for those cases, and cannot go up the call-stack to understand the conditions under which this happens. Until we do, we cannot claim this to be a bug in HarfBuzz. (The code in question was written by a HarfBuzz developer, btw, so it presumably is correct.) It could be due to how we call HarfBuzz, or what we pass to it (which is determined, among other things, by the code in ligature.el). > If you still can't reproduce, what's a good way to pretty print the > lgstring passed to hbfont_shape? Use the "pp" command defined on our src/.gdbinit, of course. If you start Emacs from GDB, the result of "pp" will be shown in the GDB interaction window. If you attach GDB to an already running Emacs, be sure to start Emacs from a shell prompt, and don't close the window where the shell runs -- in which case the result of "pp" will show in that window, because we tell Emacs to write the result to its stderr. ^ permalink raw reply related [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 9:52 ` Eli Zaretskii @ 2024-11-02 10:39 ` Visuwesh 2024-11-02 12:07 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 10:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tim Ruffing, xuan, 73752 [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> From: Tim Ruffing <dev@real-or-random.org> >> Cc: 73752@debbugs.gnu.org, xuan@xlk.me >> Date: Sat, 02 Nov 2024 04:34:17 +0100 >> >> Neither the critical line in composition_gstring_adjust_zero_width nor >> the calls to lglyph-set-adjustment in composite.el are triggered. But >> this hack in hbfont_shape means I can't reproduce the bug anymore using >> Yixuan's init file: >> >> diff --git a/src/hbfont.c b/src/hbfont.c >> index 37ed4132492..6fae513069a 100644 >> --- a/src/hbfont.c >> +++ b/src/hbfont.c >> @@ -592,11 +592,12 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object >> direction) >> LGLYPH_SET_ASCENT (lglyph, metrics.ascent); >> LGLYPH_SET_DESCENT (lglyph, metrics.descent); >> >> xoff = lround (pos[i].x_offset * position_unit); >> yoff = - lround (pos[i].y_offset * position_unit); >> - wadjust = lround (pos[i].x_advance * position_unit); >> + /* wadjust = lround (pos[i].x_advance * position_unit); */ >> + wadjust = metrics.width; >> if (xoff || yoff || wadjust != metrics.width) >> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector, >> make_fixnum (xoff), >> make_fixnum (yoff), >> make_fixnum (wadjust))); > > Which leads me to the original suggestion in bug#50951, to do this: > > diff --git a/src/hbfont.c b/src/hbfont.c > index 37ed413..040658a 100644 > --- a/src/hbfont.c > +++ b/src/hbfont.c > @@ -600,6 +600,8 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction) > make_fixnum (xoff), > make_fixnum (yoff), > make_fixnum (wadjust))); > + else > + LGLYPH_SET_ADJUSTMENT (lglyph, Qnil); > } > > return make_fixnum (glyph_len); > > In bug#50951, an alternative change in fill_gstring_body was proposed > (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50951#97), which > was eventually installed, but I guess that might not be enough? Can > you and Visuwesh please confirm that we sometimes get an lgstring > argument to hbfont_shape whose glyphs already have a non-nil > LGLYPH_ADJUSTMENT component, and we leave it unmodified because the > condition to use LGLYPH_SET_ADJUSTMENT isn't satisfied? Like this: > > (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > > In my testing, a breakpoint with this condition never breaks. But > that could be because I use a different font (Cascadia Code, instead > of JetBrains Mono, which I don't have), or because my version of > HarfBuzz is much older than yours, or for some other reason. I am not sure if you wanted me to apply the above patch or not. But just loading a file that contains (set-face-attribute 'default nil :family "Cascadia Code" :height 110 :weight 'bold) (load "/tmp/ligature.el") (ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!=" "=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!" "??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>" "<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####" "#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$" "$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--" "-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>" "==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|" "<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~" "~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||" "|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::=" ":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???" "<:<" ";;;")) (global-ligature-mode t) was enough to trigger the breakpoint for me. This is, of course, before I got a chance to even reproduce the misalignment. Here's what the gdb buffer looks like: (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = dumb Breakpoint 1 at 0x20b4b7: file emacs.c, line 432. Breakpoint 2 at 0x1cfa8a: file xterm.c, line 27102. (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil Breakpoint 3 at 0x3c3ad7: file hbfont.c, line 598. (gdb) run -Q Starting program: /home/viz/lib/ports/emacs/src/emacs -Q [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff1b8f6c0 (LWP 198125)] [New Thread 0x7ffff118f6c0 (LWP 198126)] [New Thread 0x7fffebf8f6c0 (LWP 198127)] [New Thread 0x7fffeb58f6c0 (LWP 198128)] Error in testing condition for breakpoint 3: Attempt to take address of value not located in memory. Thread 1 "emacs" hit Breakpoint 3, hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598 598 if (xoff || yoff || wadjust != metrics.width) ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 10:39 ` Visuwesh @ 2024-11-02 12:07 ` Eli Zaretskii 2024-11-02 13:29 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 12:07 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: Tim Ruffing <dev@real-or-random.org>, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Sat, 02 Nov 2024 16:09:15 +0530 > > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > > > In bug#50951, an alternative change in fill_gstring_body was proposed > > (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50951#97), which > > was eventually installed, but I guess that might not be enough? Can > > you and Visuwesh please confirm that we sometimes get an lgstring > > argument to hbfont_shape whose glyphs already have a non-nil > > LGLYPH_ADJUSTMENT component, and we leave it unmodified because the > > condition to use LGLYPH_SET_ADJUSTMENT isn't satisfied? Like this: > > > > (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > > > > In my testing, a breakpoint with this condition never breaks. But > > that could be because I use a different font (Cascadia Code, instead > > of JetBrains Mono, which I don't have), or because my version of > > HarfBuzz is much older than yours, or for some other reason. > > I am not sure if you wanted me to apply the above patch or not. no patch should be applied, not yet. > But just loading a file that contains > > (set-face-attribute 'default nil > :family "Cascadia Code" > :height 110 > :weight 'bold) > > (load "/tmp/ligature.el") > > (ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!=" > "=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!" > "??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>" > "<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####" > "#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$" > "$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--" > "-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>" > "==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|" > "<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~" > "~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||" > "|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::=" > ":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???" > "<:<" ";;;")) > (global-ligature-mode t) > > was enough to trigger the breakpoint for me. This is, of course, before > I got a chance to even reproduce the misalignment. > > Here's what the gdb buffer looks like: > > (gdb) source .gdbinit > SIGINT is used by the debugger. > Are you sure you want to change it? (y or n) [answered Y; input not from terminal] > DISPLAY = :0.0 > TERM = dumb > Breakpoint 1 at 0x20b4b7: file emacs.c, line 432. > Breakpoint 2 at 0x1cfa8a: file xterm.c, line 27102. > (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > Breakpoint 3 at 0x3c3ad7: file hbfont.c, line 598. > (gdb) run -Q > Starting program: /home/viz/lib/ports/emacs/src/emacs -Q > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7ffff1b8f6c0 (LWP 198125)] > [New Thread 0x7ffff118f6c0 (LWP 198126)] > [New Thread 0x7fffebf8f6c0 (LWP 198127)] > [New Thread 0x7fffeb58f6c0 (LWP 198128)] > Error in testing condition for breakpoint 3: > Attempt to take address of value not located in memory. > > Thread 1 "emacs" hit Breakpoint 3, hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598 > 598 if (xoff || yoff || wadjust != metrics.width) Good. Now please do this: (gdb) pp lgstring (gdb) p wadjust (gdb) p metrics.width (gdb) bt And post the results here. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 12:07 ` Eli Zaretskii @ 2024-11-02 13:29 ` Visuwesh 2024-11-02 16:47 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 13:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> But just loading a file that contains >> >> (set-face-attribute 'default nil >> :family "Cascadia Code" >> :height 110 >> :weight 'bold) >> >> (load "/tmp/ligature.el") >> >> (ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!=" >> "=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!" >> "??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>" >> "<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####" >> "#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$" >> "$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--" >> "-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>" >> "==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|" >> "<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~" >> "~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||" >> "|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::=" >> ":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???" >> "<:<" ";;;")) >> (global-ligature-mode t) >> >> was enough to trigger the breakpoint for me. This is, of course, before >> I got a chance to even reproduce the misalignment. >> >> Here's what the gdb buffer looks like: >> >> (gdb) source .gdbinit >> SIGINT is used by the debugger. >> Are you sure you want to change it? (y or n) [answered Y; input not from terminal] >> DISPLAY = :0.0 >> TERM = dumb >> Breakpoint 1 at 0x20b4b7: file emacs.c, line 432. >> Breakpoint 2 at 0x1cfa8a: file xterm.c, line 27102. >> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil >> Breakpoint 3 at 0x3c3ad7: file hbfont.c, line 598. >> (gdb) run -Q >> Starting program: /home/viz/lib/ports/emacs/src/emacs -Q >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7ffff1b8f6c0 (LWP 198125)] >> [New Thread 0x7ffff118f6c0 (LWP 198126)] >> [New Thread 0x7fffebf8f6c0 (LWP 198127)] >> [New Thread 0x7fffeb58f6c0 (LWP 198128)] >> Error in testing condition for breakpoint 3: >> Attempt to take address of value not located in memory. >> >> Thread 1 "emacs" hit Breakpoint 3, hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598 >> 598 if (xoff || yoff || wadjust != metrics.width) > > Good. Now please do this: > > (gdb) pp lgstring > (gdb) p wadjust > (gdb) p metrics.width > (gdb) bt > > And post the results here. (gdb) pp lgstring [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 59 59] nil [0 0 59 1935 9 4 14 8 4 nil] [1 1 59 1865 9 2 6 8 4 nil] nil nil nil nil nil nil] (gdb) p wadjust $1 = 9 (gdb) p metrics.width $2 = 9 (gdb) bt #0 hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598 #1 0x00005555558795a7 in Ffont_shape_gstring (gstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at font.c:4617 #2 0x000055555584b330 in funcall_subr (subr=0x5555560333a0 <Sfont_shape_gstring>, numargs=2, args=0x7ffff1c00070) at eval.c:3149 #3 0x00005555558a95f3 in exec_byte_code (fun=XIL(0x7ffff2934d8d), args_template=1542, nargs=6, args=0x7fffffff6d68) at bytecode.c:813 #4 0x000055555584b978 in funcall_lambda (fun=XIL(0x7ffff2934d8d), nargs=6, arg_vector=0x7fffffff6d38) at eval.c:3238 #5 0x000055555584ad18 in funcall_general (fun=XIL(0x7ffff2934d8d), numargs=6, args=0x7fffffff6d38) at eval.c:3030 #6 0x000055555584afd9 in Ffuncall (nargs=7, args=0x7fffffff6d30) at eval.c:3079 #7 0x00005555558473bc in internal_condition_case_n (bfun=0x55555584ae63 <Ffuncall>, nargs=7, args=0x7fffffff6d30, handlers=XIL(0x30), hfun=0x55555584b059 <safe_eval_handler>) at eval.c:1687 #8 0x000055555584b117 in safe_funcall (nargs=7, args=0x7fffffff6d30) at eval.c:3107 #9 0x00005555558f1047 in autocmp_chars (rule=XIL(0x5555561300ed), charpos=1, bytepos=1, limit=3, win=0x55555628c3f8, face=0x5555566b7780, string=XIL(0), direction=XIL(0x33c0), ch=59) at composite.c:979 #10 0x00005555558f1fb3 in composition_reseat_it (cmp_it=0x7fffffff8e80, charpos=1, bytepos=1, endpos=148, w=0x55555628c3f8, bidi_level=0 '\000', face=0x5555566b7780, string=XIL(0)) at composite.c:1346 #11 0x00005555555ea807 in next_element_from_buffer (it=0x7fffffff85c0) at xdisp.c:9808 #12 0x00005555555e6324 in get_next_display_element (it=0x7fffffff85c0) at xdisp.c:8306 #13 0x0000555555620630 in display_line (it=0x7fffffff85c0, cursor_vpos=3) at xdisp.c:25443 #14 0x0000555555610972 in try_window (window=XIL(0x55555628c3fd), pos=..., flags=1) at xdisp.c:21261 #15 0x000055555560d30b in redisplay_window (window=XIL(0x55555628c3fd), just_this_one_p=false) at xdisp.c:20641 #16 0x0000555555603eea in redisplay_window_0 (window=XIL(0x55555628c3fd)) at xdisp.c:18124 #17 0x00005555558471d8 in internal_condition_case_1 (bfun=0x555555603ea8 <redisplay_window_0>, arg=XIL(0x55555628c3fd), handlers=XIL(0x7ffff2a75de3), hfun=0x555555603d85 <redisplay_window_error>) at eval.c:1631 #18 0x0000555555603d57 in redisplay_windows (window=XIL(0x55555628c3fd)) at xdisp.c:18093 #19 0x0000555555602430 in redisplay_internal () at xdisp.c:17492 #20 0x00005555555fff75 in redisplay () at xdisp.c:16667 #21 0x000055555576bffb in read_char (commandflag=1, map=XIL(0x7ffff5109073), prev_event=XIL(0), used_mouse_menu=0x7fffffffdcaf, end_time=0x0) at keyboard.c:2673 #22 0x0000555555780075 in read_key_sequence (keybuf=0x7fffffffde60, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at keyboard.c:10747 #23 0x0000555555768380 in command_loop_1 () at keyboard.c:1424 #24 0x00005555558470f7 in internal_condition_case (bfun=0x555555767f51 <command_loop_1>, handlers=XIL(0x90), hfun=0x5555557673d2 <cmd_error>) at eval.c:1607 #25 0x0000555555767b18 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1163 #26 0x000055555584654d in internal_catch (tag=XIL(0x12330), func=0x555555767aee <command_loop_2>, arg=XIL(0x90)) at eval.c:1286 #27 0x0000555555767aaa in command_loop () at keyboard.c:1141 #28 0x0000555555766e74 in recursive_edit_1 () at keyboard.c:749 #29 0x00005555557670a0 in Frecursive_edit () at keyboard.c:832 #30 0x0000555555762937 in main (argc=2, argv=0x7fffffffe498) at emacs.c:2625 Lisp Backtrace: "font-shape-gstring" (0xf1c00070) "auto-compose-chars" (0xffff6d38) "redisplay_internal (C function)" (0x0) ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 13:29 ` Visuwesh @ 2024-11-02 16:47 ` Eli Zaretskii 2024-11-02 17:04 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 16:47 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Sat, 02 Nov 2024 18:59:03 +0530 > > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > > >> But just loading a file that contains > >> > >> (set-face-attribute 'default nil > >> :family "Cascadia Code" > >> :height 110 > >> :weight 'bold) > >> > >> (load "/tmp/ligature.el") > >> > >> (ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!=" > >> "=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!" > >> "??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>" > >> "<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####" > >> "#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$" > >> "$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--" > >> "-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>" > >> "==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|" > >> "<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~" > >> "~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||" > >> "|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::=" > >> ":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???" > >> "<:<" ";;;")) > >> (global-ligature-mode t) > >> > >> was enough to trigger the breakpoint for me. This is, of course, before > >> I got a chance to even reproduce the misalignment. > >> > >> Here's what the gdb buffer looks like: > >> > >> (gdb) source .gdbinit > >> SIGINT is used by the debugger. > >> Are you sure you want to change it? (y or n) [answered Y; input not from terminal] > >> DISPLAY = :0.0 > >> TERM = dumb > >> Breakpoint 1 at 0x20b4b7: file emacs.c, line 432. > >> Breakpoint 2 at 0x1cfa8a: file xterm.c, line 27102. > >> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > >> Breakpoint 3 at 0x3c3ad7: file hbfont.c, line 598. > >> (gdb) run -Q > >> Starting program: /home/viz/lib/ports/emacs/src/emacs -Q > >> [Thread debugging using libthread_db enabled] > >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > >> [New Thread 0x7ffff1b8f6c0 (LWP 198125)] > >> [New Thread 0x7ffff118f6c0 (LWP 198126)] > >> [New Thread 0x7fffebf8f6c0 (LWP 198127)] > >> [New Thread 0x7fffeb58f6c0 (LWP 198128)] > >> Error in testing condition for breakpoint 3: > >> Attempt to take address of value not located in memory. > >> > >> Thread 1 "emacs" hit Breakpoint 3, hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598 > >> 598 if (xoff || yoff || wadjust != metrics.width) > > > > Good. Now please do this: > > > > (gdb) pp lgstring > > (gdb) p wadjust > > (gdb) p metrics.width > > (gdb) bt > > > > And post the results here. > > (gdb) pp lgstring > [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 59 59] nil [0 0 59 1935 9 4 14 8 4 nil] [1 1 59 1865 9 2 6 8 4 nil] nil nil nil nil nil nil] > (gdb) p wadjust > $1 = 9 > (gdb) p metrics.width > $2 = 9 Thanks, but this is a false alarm: the lgstring's glyphs don't have the [XOFF YOFF WADJUST] component. So either my breakpoint condition is somehow wrong, or you mistyped it, or something else. What does GDB show if you type (gdb) p LGLYPH_ADJUSTMENT(lglyph) (gdb) p Qnil ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 16:47 ` Eli Zaretskii @ 2024-11-02 17:04 ` Visuwesh 2024-11-02 17:18 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 17:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org >> Date: Sat, 02 Nov 2024 18:59:03 +0530 >> >> [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> >> >> But just loading a file that contains >> >> >> >> (set-face-attribute 'default nil >> >> :family "Cascadia Code" >> >> :height 110 >> >> :weight 'bold) >> >> >> >> (load "/tmp/ligature.el") >> >> >> >> (ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!=" >> >> "=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!" >> >> "??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>" >> >> "<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####" >> >> "#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$" >> >> "$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--" >> >> "-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>" >> >> "==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|" >> >> "<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~" >> >> "~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||" >> >> "|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::=" >> >> ":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???" >> >> "<:<" ";;;")) >> >> (global-ligature-mode t) >> >> >> >> was enough to trigger the breakpoint for me. This is, of course, before >> >> I got a chance to even reproduce the misalignment. >> >> >> >> Here's what the gdb buffer looks like: >> >> >> >> (gdb) source .gdbinit >> >> SIGINT is used by the debugger. >> >> Are you sure you want to change it? (y or n) [answered Y; input not from terminal] >> >> DISPLAY = :0.0 >> >> TERM = dumb >> >> Breakpoint 1 at 0x20b4b7: file emacs.c, line 432. >> >> Breakpoint 2 at 0x1cfa8a: file xterm.c, line 27102. >> >> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil >> >> Breakpoint 3 at 0x3c3ad7: file hbfont.c, line 598. >> >> (gdb) run -Q >> >> Starting program: /home/viz/lib/ports/emacs/src/emacs -Q >> >> [Thread debugging using libthread_db enabled] >> >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> [New Thread 0x7ffff1b8f6c0 (LWP 198125)] >> >> [New Thread 0x7ffff118f6c0 (LWP 198126)] >> >> [New Thread 0x7fffebf8f6c0 (LWP 198127)] >> >> [New Thread 0x7fffeb58f6c0 (LWP 198128)] >> >> Error in testing condition for breakpoint 3: >> >> Attempt to take address of value not located in memory. >> >> >> >> Thread 1 "emacs" hit Breakpoint 3, hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598 >> >> 598 if (xoff || yoff || wadjust != metrics.width) >> > >> > Good. Now please do this: >> > >> > (gdb) pp lgstring >> > (gdb) p wadjust >> > (gdb) p metrics.width >> > (gdb) bt >> > >> > And post the results here. >> >> (gdb) pp lgstring >> [[#<font-object "-SAJA-Cascadia >> Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 59 59] nil [0 0 >> 59 1935 9 4 14 8 4 nil] [1 1 59 1865 9 2 6 8 4 nil] nil nil nil nil >> nil nil] >> (gdb) p wadjust >> $1 = 9 >> (gdb) p metrics.width >> $2 = 9 > > Thanks, but this is a false alarm: the lgstring's glyphs don't have > the [XOFF YOFF WADJUST] component. So either my breakpoint condition > is somehow wrong, or you mistyped it, or something else. I don't think I mistyped the condition at least. Here's what I typed: (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > What does GDB show if you type > > (gdb) p LGLYPH_ADJUSTMENT(lglyph) > (gdb) p Qnil (gdb) p LGLYPH_ADJUSTMENT(lglyph) $3 = XIL(0) (gdb) p Qnil $4 = XIL(0) ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:04 ` Visuwesh @ 2024-11-02 17:18 ` Eli Zaretskii 2024-11-02 17:31 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 17:18 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Sat, 02 Nov 2024 22:34:44 +0530 > > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > > > Thanks, but this is a false alarm: the lgstring's glyphs don't have > > the [XOFF YOFF WADJUST] component. So either my breakpoint condition > > is somehow wrong, or you mistyped it, or something else. > > I don't think I mistyped the condition at least. Here's what I typed: > > (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > > > What does GDB show if you type > > > > (gdb) p LGLYPH_ADJUSTMENT(lglyph) > > (gdb) p Qnil > > (gdb) p LGLYPH_ADJUSTMENT(lglyph) > $3 = XIL(0) > (gdb) p Qnil > $4 = XIL(0) OK, but then why did the breakpoint break, when the condition is obviously false: LGLYPH_ADJUSTMENT(lglyph) == Qnil. What happens if you type this: (gdb) p Qnil+0 ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:18 ` Eli Zaretskii @ 2024-11-02 17:31 ` Visuwesh 2024-11-02 17:34 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 17:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org >> Date: Sat, 02 Nov 2024 22:34:44 +0530 >> >> [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> >> > Thanks, but this is a false alarm: the lgstring's glyphs don't have >> > the [XOFF YOFF WADJUST] component. So either my breakpoint condition >> > is somehow wrong, or you mistyped it, or something else. >> >> I don't think I mistyped the condition at least. Here's what I typed: >> >> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == >> metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil >> >> > What does GDB show if you type >> > >> > (gdb) p LGLYPH_ADJUSTMENT(lglyph) >> > (gdb) p Qnil >> >> (gdb) p LGLYPH_ADJUSTMENT(lglyph) >> $3 = XIL(0) >> (gdb) p Qnil >> $4 = XIL(0) > > OK, but then why did the breakpoint break, when the condition is > obviously false: LGLYPH_ADJUSTMENT(lglyph) == Qnil. > > What happens if you type this: > > (gdb) p Qnil+0 (gdb) p Qnil+0 Attempt to take address of value not located in memory. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:31 ` Visuwesh @ 2024-11-02 17:34 ` Eli Zaretskii 2024-11-02 17:39 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 17:34 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Sat, 02 Nov 2024 23:01:37 +0530 > > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > > >> From: Visuwesh <visuweshm@gmail.com> > >> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > >> Date: Sat, 02 Nov 2024 22:34:44 +0530 > >> > >> [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > >> > >> > Thanks, but this is a false alarm: the lgstring's glyphs don't have > >> > the [XOFF YOFF WADJUST] component. So either my breakpoint condition > >> > is somehow wrong, or you mistyped it, or something else. > >> > >> I don't think I mistyped the condition at least. Here's what I typed: > >> > >> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == > >> metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil > >> > >> > What does GDB show if you type > >> > > >> > (gdb) p LGLYPH_ADJUSTMENT(lglyph) > >> > (gdb) p Qnil > >> > >> (gdb) p LGLYPH_ADJUSTMENT(lglyph) > >> $3 = XIL(0) > >> (gdb) p Qnil > >> $4 = XIL(0) > > > > OK, but then why did the breakpoint break, when the condition is > > obviously false: LGLYPH_ADJUSTMENT(lglyph) == Qnil. > > > > What happens if you type this: > > > > (gdb) p Qnil+0 > > (gdb) p Qnil+0 > Attempt to take address of value not located in memory. And this: (gdb) ptype Qnil ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:34 ` Eli Zaretskii @ 2024-11-02 17:39 ` Visuwesh 2024-11-02 17:44 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 17:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org >> Date: Sat, 02 Nov 2024 23:01:37 +0530 >> >> [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> >> >> From: Visuwesh <visuweshm@gmail.com> >> >> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org >> >> Date: Sat, 02 Nov 2024 22:34:44 +0530 >> >> >> >> [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: >> >> >> >> > Thanks, but this is a false alarm: the lgstring's glyphs don't have >> >> > the [XOFF YOFF WADJUST] component. So either my breakpoint condition >> >> > is somehow wrong, or you mistyped it, or something else. >> >> >> >> I don't think I mistyped the condition at least. Here's what I typed: >> >> >> >> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == >> >> metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil >> >> >> >> > What does GDB show if you type >> >> > >> >> > (gdb) p LGLYPH_ADJUSTMENT(lglyph) >> >> > (gdb) p Qnil >> >> >> >> (gdb) p LGLYPH_ADJUSTMENT(lglyph) >> >> $3 = XIL(0) >> >> (gdb) p Qnil >> >> $4 = XIL(0) >> > >> > OK, but then why did the breakpoint break, when the condition is >> > obviously false: LGLYPH_ADJUSTMENT(lglyph) == Qnil. >> > >> > What happens if you type this: >> > >> > (gdb) p Qnil+0 >> >> (gdb) p Qnil+0 >> Attempt to take address of value not located in memory. > > And this: > > (gdb) ptype Qnil (gdb) ptype Qnil type = struct Lisp_Object { Lisp_Word i; } ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:39 ` Visuwesh @ 2024-11-02 17:44 ` Eli Zaretskii 2024-11-02 17:54 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 17:44 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Sat, 02 Nov 2024 23:09:40 +0530 > > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > > >> >> > What does GDB show if you type > >> >> > > >> >> > (gdb) p LGLYPH_ADJUSTMENT(lglyph) > >> >> > (gdb) p Qnil > >> >> > >> >> (gdb) p LGLYPH_ADJUSTMENT(lglyph) > >> >> $3 = XIL(0) > >> >> (gdb) p Qnil > >> >> $4 = XIL(0) > >> > > >> > OK, but then why did the breakpoint break, when the condition is > >> > obviously false: LGLYPH_ADJUSTMENT(lglyph) == Qnil. > >> > > >> > What happens if you type this: > >> > > >> > (gdb) p Qnil+0 > >> > >> (gdb) p Qnil+0 > >> Attempt to take address of value not located in memory. > > > > And this: > > > > (gdb) ptype Qnil > > (gdb) ptype Qnil > type = struct Lisp_Object { > Lisp_Word i; > } Ah, that explains the problem. Then please change the breakpoint condition to say this instead, and re-run the experiment: break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && ((struct Lisp_Object)LGLYPH_ADJUSTMENT(lglyph)).i != 0 ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:44 ` Eli Zaretskii @ 2024-11-02 17:54 ` Visuwesh 2024-11-02 18:02 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 17:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > Ah, that explains the problem. Then please change the breakpoint > condition to say this instead, and re-run the experiment: > > break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && ((struct Lisp_Object)LGLYPH_ADJUSTMENT(lglyph)).i != 0 It doesn't break immediately anymore. I will report back once the breakpoint breaks. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 17:54 ` Visuwesh @ 2024-11-02 18:02 ` Visuwesh 2024-11-02 18:27 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-02 18:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [சனி நவம்பர் 02, 2024] Visuwesh wrote: > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > >> Ah, that explains the problem. Then please change the breakpoint >> condition to say this instead, and re-run the experiment: >> >> break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == >> metrics.width && ((struct Lisp_Object)LGLYPH_ADJUSTMENT(lglyph)).i >> != 0 > > It doesn't break immediately anymore. I will report back once the > breakpoint breaks. I tried reproducing it again. The misalignment occurred but the breakpoint was not triggered: (gdb) pgrow TEXT: 4 glyphs 0 0: COMP[3457 (0..0)] pos=1 w=10 a+d=14+4 face=23 MB 1 10: COMP[3457 (1..1)] pos=2 w=10 a+d=14+4 face=23 MB 2 20: COMP[3457 (2..2)] pos=3 w=10 a+d=14+4 face=23 MB 3 30: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=14+4 MB (gdb) pp composition_gstring_from_id(3457) [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 3457 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]] where to get to type `pgrow' I said % kill -TSTP 222729 then set the breakpoint for set_cursor_from_row like you instructed earlier. I can try to reproduce this issue once again to see if the breakpoint gets triggered. This type though, the glyph made from --> was rendered properly using the same font but started misrendering after letting the timer run a while. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 18:02 ` Visuwesh @ 2024-11-02 18:27 ` Eli Zaretskii 2024-11-04 0:11 ` Tim Ruffing 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-02 18:27 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Sat, 02 Nov 2024 23:32:53 +0530 > > [சனி நவம்பர் 02, 2024] Visuwesh wrote: > > > [சனி நவம்பர் 02, 2024] Eli Zaretskii wrote: > > > >> Ah, that explains the problem. Then please change the breakpoint > >> condition to say this instead, and re-run the experiment: > >> > >> break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == > >> metrics.width && ((struct Lisp_Object)LGLYPH_ADJUSTMENT(lglyph)).i > >> != 0 > > > > It doesn't break immediately anymore. I will report back once the > > breakpoint breaks. > > I tried reproducing it again. The misalignment occurred but the > breakpoint was not triggered: > > (gdb) pgrow > TEXT: 4 glyphs > 0 0: COMP[3457 (0..0)] pos=1 w=10 a+d=14+4 face=23 MB > 1 10: COMP[3457 (1..1)] pos=2 w=10 a+d=14+4 face=23 MB > 2 20: COMP[3457 (2..2)] pos=3 w=10 a+d=14+4 face=23 MB > 3 30: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=14+4 MB > (gdb) pp composition_gstring_from_id(3457) > [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 3457 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]] > > where to get to type `pgrow' I said > > % kill -TSTP 222729 > > then set the breakpoint for set_cursor_from_row like you instructed > earlier. > > I can try to reproduce this issue once again to see if the breakpoint > gets triggered. Please also put a breakpoint in composite.c on the line shown below, before you try reproducing again: if (NILP (glyph) || from != LGLYPH_FROM (glyph)) { eassert (i > 0); Lisp_Object last = LGSTRING_GLYPH (gstring, i - 1); if (width == 0) { if (NILP (LGLYPH_ADJUSTMENT (last))) <<<<<<<<<<<<<<<<<<<<< LGLYPH_SET_ADJUSTMENT (last, CALLN (Fvector, make_fixnum (0), make_fixnum (0), make_fixnum (LGLYPH_WIDTH (last) + 1))); else ASET (LGLYPH_ADJUSTMENT (last), 2, make_fixnum (LGLYPH_WADJUST (last) + 1)); } ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-02 18:27 ` Eli Zaretskii @ 2024-11-04 0:11 ` Tim Ruffing 2024-11-04 17:45 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-11-04 0:11 UTC (permalink / raw) To: Eli Zaretskii, Visuwesh; +Cc: dev, xuan, 73752 This fixes the problem: diff --git a/src/ftfont.c b/src/ftfont.c index 882d3eec256..2be443108f1 100644 --- a/src/ftfont.c +++ b/src/ftfont.c @@ -2994,9 +2994,8 @@ fthbfont_begin_hb_font (struct font *font, double *position_unit) struct font_info *ftfont_info = (struct font_info *) font; *position_unit = 1.0 / (1 << 6); - if (! ftfont_info->hb_font) - ftfont_info->hb_font - = hb_ft_font_create_referenced (ftfont_info->ft_size->face); + ftfont_info->hb_font + = hb_ft_font_create_referenced (ftfont_info->ft_size->face); return ftfont_info->hb_font; } That is, it makes at least the bug with Yixuan's script disappear. I haven't yet verified if this fixes what I often see during my daily usage. The above patch seems to a bit crude at first glance. While I don't notice any impact on performance, the following should be faster according to https://harfbuzz.github.io/integration-freetype.html : diff --git a/src/ftfont.c b/src/ftfont.c index 882d3eec256..cd685af4d89 100644 --- a/src/ftfont.c +++ b/src/ftfont.c @@ -2997,6 +2997,8 @@ fthbfont_begin_hb_font (struct font *font, double *position_unit) if (! ftfont_info->hb_font) ftfont_info->hb_font = hb_ft_font_create_referenced (ftfont_info->ft_size->face); + else + hb_ft_font_changed (ftfont_info->hb_font); return ftfont_info->hb_font; } But unfortunately, that one doesn't work. With this patch, the rendering is still bad, it's just bad in a difference way: Instead of the last character having wadjust > width, all characters in the bad ligature have the same wadjust > width. If we care about this, then we may want to reach out to harfbuzz to understand why. (Or at least that seems beyond my superficial text rendering skills, but perhaps the experts here understand what's going on.) ^ permalink raw reply related [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-04 0:11 ` Tim Ruffing @ 2024-11-04 17:45 ` Eli Zaretskii 2024-11-04 18:02 ` Visuwesh ` (2 more replies) 0 siblings, 3 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-11-04 17:45 UTC (permalink / raw) To: Tim Ruffing, YAMAMOTO Mitsuharu; +Cc: 73752, dev, xuan, visuweshm > From: Tim Ruffing <dev@real-or-random.org> > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Mon, 04 Nov 2024 01:11:39 +0100 > > This fixes the problem: Thanks. But do you understand why? And how did you arrive to the conclusion that this is the change which might help? > diff --git a/src/ftfont.c b/src/ftfont.c > index 882d3eec256..2be443108f1 100644 > --- a/src/ftfont.c > +++ b/src/ftfont.c > @@ -2994,9 +2994,8 @@ fthbfont_begin_hb_font (struct font *font, double > *position_unit) > struct font_info *ftfont_info = (struct font_info *) font; > > *position_unit = 1.0 / (1 << 6); > - if (! ftfont_info->hb_font) > - ftfont_info->hb_font > - = hb_ft_font_create_referenced (ftfont_info->ft_size->face); > + ftfont_info->hb_font > + = hb_ft_font_create_referenced (ftfont_info->ft_size->face); > return ftfont_info->hb_font; > } > > That is, it makes at least the bug with Yixuan's script disappear. I > haven't yet verified if this fixes what I often see during my daily > usage. That code was written by a leading HarfBuzz developer, so it's hard for me to believe that it is so incorrect. OTOH, I see that ftcrhbfont is the _only_ HarfBuzz-based font backend which implements the end_hb_font method, and I think you both told me that only the Cairo build has this problem? If so, I think the code to look at is the end_hb_font method and what it does to the hb_font object. The end_hb_font method is called each time the shaper is called, so whatever it does to the hb_font object is inherited by the next call to the shaper. Visuwesh, do the problems you see also disappear when you install the change in fthbfont_begin_hb_font which removes the !ftfont_info->hb_font condition for calling hb_ft_font_create_referenced? I'm also adding Yamamoto-san to this discussion, in the hope that he could have some ideas or suggestions. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-04 17:45 ` Eli Zaretskii @ 2024-11-04 18:02 ` Visuwesh 2024-11-04 23:33 ` Tim Ruffing 2024-11-06 14:50 ` Visuwesh 2 siblings, 0 replies; 90+ messages in thread From: Visuwesh @ 2024-11-04 18:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tim Ruffing, xuan, YAMAMOTO Mitsuharu, 73752 [திங்கள் நவம்பர் 04, 2024] Eli Zaretskii wrote: > Visuwesh, do the problems you see also disappear when you install the > change in fthbfont_begin_hb_font which removes the > !ftfont_info->hb_font condition for calling > hb_ft_font_create_referenced? I will try to test it ASAP. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-04 17:45 ` Eli Zaretskii 2024-11-04 18:02 ` Visuwesh @ 2024-11-04 23:33 ` Tim Ruffing 2024-11-04 23:47 ` Tim Ruffing 2024-11-06 12:02 ` Tim Ruffing 2024-11-06 14:50 ` Visuwesh 2 siblings, 2 replies; 90+ messages in thread From: Tim Ruffing @ 2024-11-04 23:33 UTC (permalink / raw) To: Eli Zaretskii, Tim Ruffing, YAMAMOTO Mitsuharu; +Cc: 73752, xuan, visuweshm On Mon, 2024-11-04 at 19:45 +0200, Eli Zaretskii wrote: > > From: Tim Ruffing <dev@real-or-random.org> > > Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org > > Date: Mon, 04 Nov 2024 01:11:39 +0100 > > > > This fixes the problem: > > Thanks. But do you understand why? > > And how did you arrive to the conclusion that this is the change > which > might help? I was trying to understand why hb_shape_full() gives different results at different times. All the other inputs (e.g., text direction) to hb seemed harmless and fixed for the reproducing script. The only thing that is constantly changing in the script is the font, so this was the obvious candidate. Then I searched harfbuzz's bug tracker for relevant issues, and I found this one, which is rather similar to what we observe (e.g., advance wrong): https://github.com/harfbuzz/harfbuzz/issues/1620 > That code was written by a leading HarfBuzz developer, so it's hard > for me to believe that it is so incorrect. > Perhaps it was simply written before harfbuzz implemented caching, so the code was correct for older versions of harfbuzz. The root cause of the aforementioned issue is exactly this. > OTOH, I see that ftcrhbfont is the _only_ HarfBuzz-based font backend > which implements the end_hb_font method, and I think you both told me > that only the Cairo build has this problem? The Cairo build has this problem, and yeah, I've just checked, I can't reproduce with the the Xft backend. > If so, I think the code > to look at is the end_hb_font method and what it does to the hb_font > object. The end_hb_font method is called each time the shaper is > called, so whatever it does to the hb_font object is inherited by the > next call to the shaper. This sounds like a plausible cause, but as far as I can tell, end_hb_font doesn't do anything to hb_font. The end function is simply necessary to call cairo_ft_scaled_font_unlock_face(). What I don't understand is whether or how the underlying FT_Face or FT_Size is supposed to change at all. I assume it's not supposed to change? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-04 23:33 ` Tim Ruffing @ 2024-11-04 23:47 ` Tim Ruffing 2024-11-06 12:02 ` Tim Ruffing 1 sibling, 0 replies; 90+ messages in thread From: Tim Ruffing @ 2024-11-04 23:47 UTC (permalink / raw) To: Tim Ruffing, Eli Zaretskii, YAMAMOTO Mitsuharu; +Cc: 73752, xuan, visuweshm By the way, I was not suggesting a final patch. If anything, if we call hb_ft_font_create_referenced unconditionally, we should create an _end function and call hb_font_destroy there. But I still think that there should be a cleaner fix. I have no idea why hb_ft_font_changed doesn't work. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-04 23:33 ` Tim Ruffing 2024-11-04 23:47 ` Tim Ruffing @ 2024-11-06 12:02 ` Tim Ruffing 2024-11-06 13:11 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-11-06 12:02 UTC (permalink / raw) To: Tim Ruffing, Eli Zaretskii, YAMAMOTO Mitsuharu; +Cc: 73752, xuan, visuweshm > > If so, I think the code > > to look at is the end_hb_font method and what it does to the > hb_font > > object. The end_hb_font method is called each time the shaper is > > called, so whatever it does to the hb_font object is inherited by > the > > next call to the shaper. > > This sounds like a plausible cause, but as far as I can tell, > end_hb_font doesn't do anything to hb_font. The end function is > simply > necessary to call cairo_ft_scaled_font_unlock_face(). > Okay, I still have no idea what the root cause is, but this hack also makes the bug disappear for me: diff --git a/src/ftcrfont.c b/src/ftcrfont.c index 3700154e44a..4f62873f8c1 100644 --- a/src/ftcrfont.c +++ b/src/ftcrfont.c @@ -708,7 +708,6 @@ ftcrhbfont_end_hb_font (struct font *font, hb_font_t *hb_font) struct font_info *ftcrfont_info = (struct font_info *) font; cairo_scaled_font_t *scaled_font = ftcrfont_info->cr_scaled_font; - cairo_ft_scaled_font_unlock_face (scaled_font); ftcrfont_info->ft_size = NULL; } This is consistent with your theory about end_hb_font. ^ permalink raw reply related [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-06 12:02 ` Tim Ruffing @ 2024-11-06 13:11 ` Eli Zaretskii 2024-11-07 2:12 ` Tim Ruffing 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-06 13:11 UTC (permalink / raw) To: Tim Ruffing; +Cc: 73752, dev, xuan, mituharu, visuweshm > From: Tim Ruffing <dev@real-or-random.org> > Cc: visuweshm@gmail.com, xuan@xlk.me, 73752@debbugs.gnu.org > Date: Wed, 06 Nov 2024 13:02:34 +0100 > > > > If so, I think the code > > > to look at is the end_hb_font method and what it does to the > > hb_font > > > object. The end_hb_font method is called each time the shaper is > > > called, so whatever it does to the hb_font object is inherited by > > the > > > next call to the shaper. > > > > This sounds like a plausible cause, but as far as I can tell, > > end_hb_font doesn't do anything to hb_font. The end function is > > simply > > necessary to call cairo_ft_scaled_font_unlock_face(). > > > > > Okay, I still have no idea what the root cause is, but this hack also > makes the bug disappear for me: > > diff --git a/src/ftcrfont.c b/src/ftcrfont.c > index 3700154e44a..4f62873f8c1 100644 > --- a/src/ftcrfont.c > +++ b/src/ftcrfont.c > @@ -708,7 +708,6 @@ ftcrhbfont_end_hb_font (struct font *font, > hb_font_t *hb_font) > struct font_info *ftcrfont_info = (struct font_info *) font; > cairo_scaled_font_t *scaled_font = ftcrfont_info->cr_scaled_font; > > - cairo_ft_scaled_font_unlock_face (scaled_font); > ftcrfont_info->ft_size = NULL; > } > > This is consistent with your theory about end_hb_font. Thanks. Can you try calling hb_font_destroy in ftcrhbfont_end_hb_font and setting ftcrfont_info->hb_font to NULL right after that? If that solves the problem, we could at least install this for now, until we have a better solution (if one exists). Also, did you see https://github.com/harfbuzz/harfbuzz/issues/4926 ? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-06 13:11 ` Eli Zaretskii @ 2024-11-07 2:12 ` Tim Ruffing 2024-11-07 7:05 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Tim Ruffing @ 2024-11-07 2:12 UTC (permalink / raw) To: Eli Zaretskii, Tim Ruffing; +Cc: 73752, xuan, mituharu, visuweshm [-- Attachment #1: Type: text/plain, Size: 2648 bytes --] On Wed, 2024-11-06 at 15:11 +0200, Eli Zaretskii wrote: > > > Thanks. Can you try calling hb_font_destroy in > ftcrhbfont_end_hb_font > and setting ftcrfont_info->hb_font to NULL right after that? If that > solves the problem, we could at least install this for now, until we > have a better solution (if one exists). Yes, that appears to work. And I don't think there's an obvious better solution. See attached patch. And I think I understand the root cause now: What the cairo backend persists is a cairo_font_face_t, from which it will obtain an FT_Face on demand using cairo_ft_scaled_font_lock_face (and cairo_ft_scaled_font_unlock_face), e.g., to pass it to hb_ft_font_create_referenced to create a hb_font_t. The lock/unlock interface implies that we should not keep a reference to the FT_Face in hb_font_t after cairo_ft_scaled_font_unlock_face, and so we should not persist the hb_font_t. Here's an unconfirmed theory what actually happens under the hood: Cairo internally caches an unscaled FT_Face and scales it on demand to a specific size. That means that cairo_ft_scaled_font_lock_face will scale the one FT_Face to which we still hold possibly multiple references (one for each size) inside the hb_font_t object. Since we call cairo_ft_scaled_font_lock_face every time before accessing the hb_font_t, we happen to see the scaled version with the correct size every time. So far we were lucky. But Cairo's cache is limited to (currently) 10 elements [1]. As a result, if many fonts are used, Cairo will evict a random cached FT_Face, and later create a new one if requested via cairo_ft_scaled_font_lock_face. In that case, we hold a reference to the outdated FT_Face, which won't be scaled any longer by cairo_ft_scaled_font_lock_face, and thus we pass a face with the wrong size to harfbuzz. The caching logic also explains why removing the unlock call makes the problem disappear: Cairo won't evict the FT_Face of locked cairo_scaled_font_t objects, even if this means going over 10. This suggests that removing the cairo_ft_scaled_font_unlock_face call is another fix, probably slightly more efficient, but also somewhat frivolous. The docs explicitly say this: "Since the FT_Face object can be shared between multiple cairo_scaled_font_t objects, you must not lock any other font objects until you unlock this one." Though, if you look at the implementation, they release the mutex explicitly, so there can't be any deadlocks in the end. (Not suggesting we should rely on this...) [1] See MAX_OPEN_FACES in src/cairo-ft-font.c in the Cairo source code. [-- Attachment #2: 0001-Fix-additional-spacing-in-compositions-Cairo-backend.patch --] [-- Type: text/x-patch, Size: 1225 bytes --] From b52b47453665fbc088dcd570ffb79ac755dfbe8f Mon Sep 17 00:00:00 2001 From: Tim Ruffing <dev@real-or-random.org> Date: Thu, 7 Nov 2024 03:09:09 +0100 Subject: [PATCH] Fix additional spacing in compositions (Cairo backend) * src/ftcrfont.c (ftcrhbfont_end_hb_font): Don't persist the result of cairo_ft_scaled_font_lock_face in violation of the API contract. (Bug#73752) --- src/ftcrfont.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/ftcrfont.c b/src/ftcrfont.c index 3700154e44a..ee111d18763 100644 --- a/src/ftcrfont.c +++ b/src/ftcrfont.c @@ -708,6 +708,13 @@ ftcrhbfont_end_hb_font (struct font *font, hb_font_t *hb_font) struct font_info *ftcrfont_info = (struct font_info *) font; cairo_scaled_font_t *scaled_font = ftcrfont_info->cr_scaled_font; + eassert (hb_font == ftcrfont_info->hb_font); + /* ftcrfont_info->hb_font holds a reference to the FT_Face returned by + cairo_ft_scaled_font_lock_face. Keeping it around after the + matching unlock call would violate the API contract (Bug#73752). */ + hb_font_destroy (ftcrfont_info->hb_font); + ftcrfont_info->hb_font = NULL; + cairo_ft_scaled_font_unlock_face (scaled_font); ftcrfont_info->ft_size = NULL; } -- 2.47.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 2:12 ` Tim Ruffing @ 2024-11-07 7:05 ` Eli Zaretskii 2024-11-07 13:45 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-07 7:05 UTC (permalink / raw) To: Tim Ruffing; +Cc: 73752, xuan, mituharu, visuweshm > From: Tim Ruffing <dev@real-or-random.org> > Cc: mituharu@math.s.chiba-u.ac.jp, visuweshm@gmail.com, xuan@xlk.me, > 73752@debbugs.gnu.org > Date: Thu, 07 Nov 2024 03:12:19 +0100 > > On Wed, 2024-11-06 at 15:11 +0200, Eli Zaretskii wrote: > > > > > > Thanks. Can you try calling hb_font_destroy in > > ftcrhbfont_end_hb_font > > and setting ftcrfont_info->hb_font to NULL right after that? If that > > solves the problem, we could at least install this for now, until we > > have a better solution (if one exists). > > Yes, that appears to work. And I don't think there's an obvious better > solution. See attached patch. Thanks. Visuwesh, does this patch fix your problem as well? If so, I think we should install this. > And I think I understand the root cause now: Thanks, sounds plausible (but I know nothing about Cairo internals or how we use it in Emacs). ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 7:05 ` Eli Zaretskii @ 2024-11-07 13:45 ` Visuwesh 2024-11-07 14:40 ` Eli Zaretskii 0 siblings, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-07 13:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tim Ruffing, xuan, mituharu, 73752 [வியாழன் நவம்பர் 07, 2024] Eli Zaretskii wrote: >> From: Tim Ruffing <dev@real-or-random.org> >> Cc: mituharu@math.s.chiba-u.ac.jp, visuweshm@gmail.com, xuan@xlk.me, >> 73752@debbugs.gnu.org >> Date: Thu, 07 Nov 2024 03:12:19 +0100 >> >> On Wed, 2024-11-06 at 15:11 +0200, Eli Zaretskii wrote: >> > >> > >> > Thanks. Can you try calling hb_font_destroy in >> > ftcrhbfont_end_hb_font >> > and setting ftcrfont_info->hb_font to NULL right after that? If that >> > solves the problem, we could at least install this for now, until we >> > have a better solution (if one exists). >> >> Yes, that appears to work. And I don't think there's an obvious better >> solution. See attached patch. > > Thanks. Visuwesh, does this patch fix your problem as well? I cannot reproduce the original issue but it leads to following backtrace when I visit dinamalar.com in eww, and click on any of the links coloured in blue: say the one under the heading named "வாராவாரம்". Directly visiting a link doesn't produce the backtrace though. I need to visit a webpage with Tamil text on it twice to trigger it. It might well be a false warning since I see the warning Warning: program compiled against libxml 212 using older 209 Warning: program compiled against libxml 212 using older 209 in stderr printed. I updated my system (kernel updates included) but haven't restarted it yet. Of course, I built Emacs _after_ the update. If you want me to restart and check if you believe it is a false warning, I am to do so. Maybe a `make bootstrap' or somesuch is also in order? (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = dumb Breakpoint 1 at 0x55555575f4b7: file emacs.c, line 432. Breakpoint 2 at 0x555555723a8a: file xterm.c, line 27102. (gdb) run -Q Starting program: /home/viz/lib/ports/emacs/src/emacs -Q [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff198f6c0 (LWP 451634)] [New Thread 0x7fffebf8f6c0 (LWP 451635)] [New Thread 0x7ffff0f8f6c0 (LWP 451636)] [New Thread 0x7fffeb58f6c0 (LWP 451637)] [Detaching after vfork from child process 451650] [Detaching after vfork from child process 451651] [Detaching after vfork from child process 451652] [New Thread 0x7ffff2369dc0 (LWP 451655)] [New Thread 0x7fffe9b8f6c0 (LWP 451656)] [Thread 0x7fffe9b8f6c0 (LWP 451656) exited] [Thread 0x7ffff2369dc0 (LWP 451655) exited] [New Thread 0x7ffff2369dc0 (LWP 451658)] [New Thread 0x7ffff1f7edc0 (LWP 451659)] [New Thread 0x7ffff1f66dc0 (LWP 451660)] [New Thread 0x7ffff1f4edc0 (LWP 451661)] [New Thread 0x7ffff1f36dc0 (LWP 451662)] [New Thread 0x7ffff1f1edc0 (LWP 451663)] [Thread 0x7ffff1f1edc0 (LWP 451663) exited] [Thread 0x7ffff1f36dc0 (LWP 451662) exited] [Thread 0x7ffff1f4edc0 (LWP 451661) exited] [Thread 0x7ffff1f7edc0 (LWP 451659) exited] [Thread 0x7ffff2369dc0 (LWP 451658) exited] [Thread 0x7ffff1f66dc0 (LWP 451660) exited] character.h:380: Emacs fatal error: assertion failed: 0xC0 <= c Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:432 432 signal (sig, SIG_DFL); (gdb) bt full #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:432 #1 0x00005555558105ef in die (msg=0x55555596707f "0xC0 <= c", file=0x55555596702b "character.h", line=380) at alloc.c:8057 #2 0x00005555555c7a71 in string_char_and_length (p=0x5555580c40b0 "\205லை\n\n \nபிரபஞ்சத்தின் திறவுகோலாகும் 'சிவ ஷம்போ'\n\nபிரபஞ்சத்தின் திறவுகோலாகும் "..., length=0x7fffffff1c4c) at /home/viz/lib/ports/emacs/src/character.h:380 c = 133 d = 3021 #3 0x00005555555c7c6e in STRING_CHAR (p=0x5555580c40b0 "\205லை\n\n \nபிரபஞ்சத்தின் திறவுகோலாகும் 'சிவ ஷம்போ'\n\nபிரபஞ்சத்தின் திறவுகோலாகும் "...) at /home/viz/lib/ports/emacs/src/character.h:417 len = 0 #4 0x00005555555c8e57 in FETCH_MULTIBYTE_CHAR (pos=8753) at /home/viz/lib/ports/emacs/src/buffer.h:1295 p = 0x5555580c40b0 "\205லை\n\n \nபிரபஞ்சத்தின் திறவுகோலாகும் 'சிவ ஷம்போ'\n\nபிரபஞ்சத்தின் திறவுகோலாகும் "... #5 0x00005555555dc783 in face_before_or_after_it_pos (it=0x7fffffffa820, before_p=false) at xdisp.c:5067 c = 21845 face = 0x7fffffff3080 pos = { charpos = 5890, bytepos = 8753 } face_id = 23 limit = 5989 next_check_charpos = 5894 it_copy = { window = XIL(0x5555557ef628), w = 0x0, f = 0x7fffffff2d90, method = 1434454367, stop_charpos = 0, prev_stop = 93825037779108, base_level_stop = 93825010904128, end_charpos = 3, medium_narrowing_begv = 93825037779111, medium_narrowing_zv = 93825010904143, large_narrowing_begv = 6, large_narrowing_zv = 93825037779117, s = 0x555556722cae "\016\005", string_nchars = 9, multibyte_p = true, tab_line_p = false, header_line_p = true, string_from_display_prop_p = true, string_from_prefix_prop_p = false, from_disp_prop_p = true, ellipsis_p = false, avoid_cursor_p = true, dp = 0x555556722c52, dpvec = 0x7fffffff1dc0, dpend = 0x5555555e7c4b <set_iterator_to_next+1147>, dpvec_char_len = 0, dpvec_face_id = 1, saved_face_id = -22496, ctl_chars = {XIL(0x5555555c5f4b), XIL(0x7ffff24001b0), XIL(0x7fffffff1dc0), make_fixnum(107732301870), XIL(0x5555560b1800), XIL(0xdffffa820), XIL(0x55555822d465), XIL(0x7fffffff1dc0), XIL(0x5555555c879d), XIL(0x55555822d465), XIL(0x7fffffff7fc0), make_fixnum(23456248214506), XIL(0x27), XIL(0xffffffff00000008), make_fixnum(2147483648), XIL(0)}, start = { pos = { charpos = 140737488299856, bytepos = 2 }, overlay_string_index = 140737488297520, string_pos = { charpos = 93824995063026, bytepos = 0 }, dpvec_index = 1472482992 }, current = { pos = { charpos = 8589934593, bytepos = 0 }, overlay_string_index = 140737488297568, string_pos = { charpos = 2, bytepos = 140737488297584 }, dpvec_index = 1434481906 }, n_overlay_strings = 0, overlay_strings_charpos = 93825024433104, overlay_strings = {XIL(0xcffff1ec0), XIL(0x198), XIL(0x7fffffff1ea0), XIL(0x55555580769c), XIL(0x198), XIL(0x555557409bd0), XIL(0x31), make_fixnum(12), XIL(0x7fffffff1f00), XIL(0x555555807a55), XIL(0x5555560b0720), XIL(0), XIL(0), XIL(0x7fffffff1ee0), make_fixnum(23456248840424), XIL(0xffff1ef0)}, string_overlays = {XIL(0x7fffffff1f10), XIL(0x555555851b1f), XIL(0x55555a959713), XIL(0), make_fixnum(23456248840424), XIL(0), XIL(0x7fffffff1f80), XIL(0x555557409b65), XIL(0x7fffffff1f50), make_fixnum(23456248866773), XIL(0), XIL(0x555557409b65), XIL(0), XIL(0x555557409b65), XIL(0x7fffffff1f80), XIL(0x55555586a1a1)}, string = XIL(0), from_overlay = XIL(0x55555a959713), stack = {{ string = XIL(0xc), string_nchars = 1463851877, end_charpos = 140737488297904, stop_charpos = 93824995467094, prev_stop = 140737488297952, base_level_stop = 93825024432997, cmp_it = { stop_pos = 140737488297920, id = 93825024432997, ch = -57376, rule_idx = 93824995467681, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0xb, charpos = 93825024432997, nchars = -57312, nbytes = 32767, from = 1434931549, to = 21845, width = 1443563296 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0x7fffffff2020), y = XIL(0x5555556d7d1f), width = XIL(0x9c7180e8), height = XIL(0x7fffffff2090) }, image_id = 93824993845541 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 140737488298192, bytepos = 140737488298368 }, current = { pos = { charpos = 140737488301664, bytepos = 140737488298192 }, overlay_string_index = 93825005705760, string_pos = { charpos = 93825005706456, bytepos = 93825004209648 }, dpvec_index = 65232 }, from_overlay = XIL(0), area = 78816, method = 20, paragraph_embedding = (L2R | R2L | unknown: 0x556d7d1c), multibyte_p = true, string_from_display_prop_p = false, string_from_prefix_prop_p = true, display_ellipsis_p = false, avoid_cursor_p = true, bidi_p = false, from_disp_prop_p = true, line_wrap = (unknown: 0x9c7180e8), voffset = 10922, space_width = XIL(0x7fffffff21c0), font_height = XIL(0x5555556de61f) }, { string = XIL(0x556d7d1f), string_nchars = -56960, end_charpos = 140737488301664, stop_charpos = 46912257491176, prev_stop = 93825005705760, base_level_stop = 93825005706456, cmp_it = { stop_pos = 33120, id = 140737261501108, ch = 78816, rule_idx = 78816, lookback = 78816, nglyphs = 78816, reversed_p = false, parent_it = 0x133e0, charpos = 78816, nchars = 78816, nbytes = 0, from = 78816, to = 0, width = 78816 }, face_id = 78816, u = { image = { object = XIL(0x133e0), slice = { x = XIL(0x133e0), y = XIL(0x2000133e0), width = XIL(0), height = XIL(0x133e0) }, image_id = 2 }, stretch = { object = XIL(0x133e0) }, xwidget = { object = XIL(0x133e0) } }, position = { charpos = 140737488298384, bytepos = 93824995063026 }, current = { pos = { charpos = 0, bytepos = 93825024433216 }, overlay_string_index = 54164291816, string_pos = { charpos = 296, bytepos = 140737488298432 }, dpvec_index = 1434482332 }, from_overlay = XIL(0x128), area = 1463852096, method = 21845, paragraph_embedding = (L2R | R2L | unknown: 0x20), multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = (unknown: 0x24), voffset = 0, space_width = XIL(0x7fffffff2220), font_height = XIL(0x555555807a55) }, { string = XIL(0x7fffffff24a0), string_nchars = 112, end_charpos = 140737488301664, stop_charpos = 408, prev_stop = 296, base_level_stop = 93825024433104, cmp_it = { stop_pos = 93825004144416, id = 49, ch = 0, rule_idx = 112, lookback = 140737488298592, nglyphs = 1519752947, reversed_p = 85, parent_it = 0x7fffffff2250, charpos = 93824995043671, nchars = 0, nbytes = 0, from = 1519752947, to = 21845, width = -56720 }, face_id = 1519752944, u = { image = { object = XIL(0), slice = { x = XIL(0x55555a9596f3), y = XIL(0x7fffffff22b0), width = XIL(0x555555806f3f), height = XIL(0) }, image_id = 93825080334067 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 25769747120, bytepos = 93825024433109 }, current = { pos = { charpos = 140737488298704, bytepos = 93824995467094 }, overlay_string_index = 140737488298752, string_pos = { charpos = 93825024433109, bytepos = 140737488298720 }, dpvec_index = 1463851989 }, from_overlay = XIL(0x7fffffff2300), area = 1434886561, method = 21845, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0xb), font_height = XIL(0x555557409bd5) }, { string = XIL(0x7fffffff2340), string_nchars = 1434931650, end_charpos = 93825004144416, stop_charpos = 0, prev_stop = 0, base_level_stop = 140737488298816, cmp_it = { stop_pos = 93824993819935, id = 4294913664, ch = -56400, rule_idx = 93824993845541, lookback = 140737488298992, nglyphs = -56160, reversed_p = 255, parent_it = 0x7fffffff2e60, charpos = 140737488298992, nchars = 1445124640, nbytes = 21845, from = 1445125336, to = 21845, width = 1443628528 }, face_id = 65232, u = { image = { object = XIL(0), slice = { x = XIL(0x14000133e0), y = XIL(0x5555556d7d1f), width = XIL(0x2aaa9c8ff600), height = XIL(0x7fffffff24e0) }, image_id = 93824993846815 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 1433238815, bytepos = 140737488299168 }, current = { pos = { charpos = 140737488301664, bytepos = 46912259487232 }, overlay_string_index = 93825005705760, string_pos = { charpos = 93825005706456, bytepos = 33120 }, dpvec_index = 78816 }, from_overlay = XIL(0x133e0), area = 78816, method = GET_FROM_BUFFER, paragraph_embedding = (L2R | R2L | unknown: 0xf2ced78c), multibyte_p = true, string_from_display_prop_p = true, string_from_prefix_prop_p = true, display_ellipsis_p = true, avoid_cursor_p = true, bidi_p = true, from_disp_prop_p = true, line_wrap = (unknown: 0x133e0), voffset = 0, space_width = XIL(0x133e0), font_height = XIL(0x133e0) }, { string = XIL(0x133e0), string_nchars = 78816, end_charpos = 78816, stop_charpos = 78816, prev_stop = 78816, base_level_stop = 78816, cmp_it = { stop_pos = 78816, id = 78816, ch = -1670283032, rule_idx = 78816, lookback = 78816, nglyphs = 78816, reversed_p = false, parent_it = 0x5500558503a2, charpos = 140737488299567, nchars = -1668286976, nbytes = 10922, from = 0, to = 10922, width = -55360 }, face_id = 0, u = { image = { object = XIL(0x555556515220), slice = { x = XIL(0x1401ff24e0), y = XIL(0x5555556d7d1f), width = XIL(0x2aaa9c8ff600), height = XIL(0x7fffffff2650) }, image_id = 93824993851579 }, stretch = { object = XIL(0x555556515220) }, xwidget = { object = XIL(0x555556515220) } }, position = { charpos = 140737488299968, bytepos = 17099872 }, current = { pos = { charpos = 140737488301664, bytepos = 46912259487232 }, overlay_string_index = 93825005705760, string_pos = { charpos = 93825005706456, bytepos = 93825004223232 }, dpvec_index = 78816 }, from_overlay = XIL(0x133e0), area = 78816, method = GET_FROM_BUFFER, paragraph_embedding = (L2R | R2L | unknown: 0x556d7d1c), multibyte_p = true, string_from_display_prop_p = false, string_from_prefix_prop_p = true, display_ellipsis_p = false, avoid_cursor_p = true, bidi_p = false, from_disp_prop_p = true, line_wrap = (unknown: 0x9c8ff600), voffset = 10922, space_width = XIL(0x7fffffff2580), font_height = XIL(0x5555556dce8f) }}, sp = 33120, selective = 93825021281568, what = IT_CHARACTER, face_id = 0, selective_display_ellipsis_p = false, ctl_arrow_p = false, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = true, ignore_overlay_strings_at_pos_p = true, glyph_not_available_p = false, starts_in_middle_of_char_p = true, face_before_selective_p = false, constrain_row_ascent_descent_p = false, line_number_produced_p = false, align_visually_p = false, line_wrap = TRUNCATE, base_face_id = -55888, c = 32767, len = 1433259984, cmp_it = { stop_pos = 93825006945637, id = 93825021281565, ch = -55840, rule_idx = 93824993823458, lookback = 0, nglyphs = 1460700445, reversed_p = 85, parent_it = 0x7fffffff2600, charpos = 93825021281568, nchars = 1443563296, nbytes = 21845, from = 0, to = 0, width = 0 }, char_to_display = -55808, glyphless_method = 32767, image_id = 93824993819935, xwidget = 0x5710851d, slice = { x = XIL(0x7fffffff2650), y = XIL(0x5555556dd393), width = make_fixnum(23364980785384), height = XIL(0x23ffff2710) }, space_width = XIL(0x133e0), voffset = 9792, tab_width = -1, font_height = XIL(0x5555560b0720), object = XIL(0x41751800000009), position = { charpos = 0, bytepos = 399373912 }, truncation_pixel_width = 32031, continuation_pixel_width = 21869, first_visible_x = 399373912, last_visible_x = 1446364512, last_visible_y = 21845, extra_line_spacing = 17159264, max_extra_line_spacing = 0, override_ascent = 17159264, override_descent = 0, override_boff = 211, glyph_row = 0x105d460, area = -55600, nglyphs = 32767, pixel_width = 1434851262, ascent = 21845, descent = -55632, max_ascent = 32767, max_descent = 1434847944, phys_ascent = 4289816, phys_descent = 1443642112, max_phys_ascent = 21845, max_phys_descent = 78816, current_x = 0, wrap_prefix_width = 78816, continuation_lines_width = 0, eol_pos = { charpos = 78816, bytepos = 93824993819935 }, current_y = 33120, first_vpos = 0, vpos = -55552, hpos = 32767, lnum = 93824993840783, lnum_bytepos = 33120, lnum_width = 1461353184, lnum_pixel_width = 21845, pt_lnum = 0, stretch_adjust = 33120, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 993072, right_user_fringe_face_id = 32767, bidi_p = false, bidi_it = { bytepos = 93824993841104, charpos = 93825006945637, ch = 1461353181, nchars = 140737488299872, ch_len = 93824993823458, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT, orig_type = 1461353181, resolved_level = 85 'U', isolate_level = 85 'U', invalid_levels = 140737488299904, invalid_isolates = 93825021934304, prev = { charpos = 93825004144416, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, last_strong = { charpos = 0, type = 4294911872, orig_type = 32767 }, next_for_neutral = { charpos = 93824993819935, type = 1461353181, orig_type = UNKNOWN_BT }, prev_for_neutral = { charpos = 140737488299984, type = 1433260947, orig_type = 21845 }, next_for_ws = { charpos = 93459923141538, type = 4294912144, orig_type = 35 }, bracket_pairing_pos = 78816, bracket_enclosed_type = 4294911936, next_en_pos = 93825004144416, next_en_type = UNKNOWN_BT, sos = NEUTRAL_DIR, scan_dir = 0, disp_pos = 140737488300000, disp_prop = 1433238815, stack_idx = 21845, level_stack = {{ next_for_neutral_pos = 17159264, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993845541, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 140737488300352, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 140737488300176, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 0, level = 34 '"', flags = 86 'V' }, { next_for_neutral_pos = 93825005706456, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 7, level = 12 '\f', flags = 86 'V' }, { next_for_neutral_pos = 65232, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 12240, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995408133, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 4294967299, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 12240, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 17159264, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 0, level = 34 '"', flags = 86 'V' }, { next_for_neutral_pos = 93825005706456, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 5, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 78816, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 1 '\001', flags = 0 '\000' }, { next_for_neutral_pos = 78816, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 1 '\001', flags = 0 '\000' }, { next_for_neutral_pos = 78816, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 1 '\001', flags = 0 '\000' }, { next_for_neutral_pos = 78816, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 1 '\001', flags = 0 '\000' }, { next_for_neutral_pos = 93825020854996, next_for_neutral_type = 4, last_strong_type = 6, prev_for_neutral_type = 2, level = 10 '\n', flags = 87 'W' }, { next_for_neutral_pos = 78816, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 1 '\001', flags = 0 '\000' }, { next_for_neutral_pos = 78816, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 3, level = 55 '7', flags = 86 'V' }, { next_for_neutral_pos = 1600, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824994966547, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 5, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995015530, next_for_neutral_type = 7, last_strong_type = 7, prev_for_neutral_type = 7, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 16793, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 12 '\f', flags = 88 'X' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 1600, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 5, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824994966547, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995015530, next_for_neutral_type = 4, last_strong_type = 4, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 16793, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 12 '\f', flags = 88 'X' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004107912, next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 6, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 26 '\032', flags = 86 'V' }, { next_for_neutral_pos = 4294970276, next_for_neutral_type = 2, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 12884901889, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 1, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 1600, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 3, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 20, next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 6, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 26 '\032', flags = 86 'V' }, { next_for_neutral_pos = 2984, next_for_neutral_type = 2, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737331473032, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 62, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995408133, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 4294967298, next_for_neutral_type = 6, last_strong_type = 7, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 70, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 167 '\247', flags = 87 'W' }, { next_for_neutral_pos = 140737335126521, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 167 '\247', flags = 87 'W' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737335138460, next_for_neutral_type = 5, last_strong_type = 0, prev_for_neutral_type = 3, level = 88 'X', flags = 87 'W' }, { next_for_neutral_pos = 140737488300999, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 4, last_strong_type = 3, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 1, next_for_neutral_type = 0, last_strong_type = 1, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825007864917, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995363916, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825007864917, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995365293, next_for_neutral_type = 4, last_strong_type = 6, prev_for_neutral_type = 6, level = 134 '\206', flags = 85 'U' }, { next_for_neutral_pos = 11922, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995408133, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 4294967297, next_for_neutral_type = 2, last_strong_type = 2, prev_for_neutral_type = 2, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 11922, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 102530, next_for_neutral_type = 0, last_strong_type = 7, prev_for_neutral_type = 5, level = 162 '\242', flags = 85 'U' }, { next_for_neutral_pos = 102530, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 62, next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type = 1, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 102530, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995436311, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 102530, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825025426277, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995363916, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825025426277, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995365293, next_for_neutral_type = 4, last_strong_type = 6, prev_for_neutral_type = 6, level = 134 '\206', flags = 85 'U' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 3, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995409991, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 4294967296, next_for_neutral_type = 5, last_strong_type = 4, prev_for_neutral_type = 5, level = 79 'O', flags = 87 'W' }, { next_for_neutral_pos = 140737262504229, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995436311, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 11922, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 11922, next_for_neutral_type = 2, last_strong_type = 2, prev_for_neutral_type = 2, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93824995365293, next_for_neutral_type = 4, last_strong_type = 4, prev_for_neutral_type = 6, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 3465085955520144975, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 3, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995435877, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488301248, next_for_neutral_type = 2, last_strong_type = 4, prev_for_neutral_type = 6, level = 133 '\205', flags = 85 'U' }, { next_for_neutral_pos = 4294913232, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 3, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995367711, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825003550528, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 5, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995373384, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 38, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488301376, next_for_neutral_type = 4, last_strong_type = 7, prev_for_neutral_type = 1, level = 126 '~', flags = 85 'U' }, { next_for_neutral_pos = 1519751683, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824994959235, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 6, last_strong_type = 4, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 30, next_for_neutral_type = 5, last_strong_type = 4, prev_for_neutral_type = 4, level = 137 '\211', flags = 242 '\362' }, { next_for_neutral_pos = 38, next_for_neutral_type = 1, last_strong_type = 1, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 7, next_for_neutral_type = 1, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 30, next_for_neutral_type = 4, last_strong_type = 7, prev_for_neutral_type = 1, level = 126 '~', flags = 85 'U' }, { next_for_neutral_pos = 93825020596192, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824994960445, next_for_neutral_type = 5, last_strong_type = 0, prev_for_neutral_type = 6, level = 137 '\211', flags = 242 '\362' }, { next_for_neutral_pos = 93825080332787, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995347708, next_for_neutral_type = 2, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488301648, next_for_neutral_type = 3, last_strong_type = 7, prev_for_neutral_type = 2, level = 142 '\216', flags = 85 'U' }, { next_for_neutral_pos = 4069116197, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488301616, next_for_neutral_type = 4, last_strong_type = 2, prev_for_neutral_type = 2, level = 132 '\204', flags = 85 'U' }, { next_for_neutral_pos = 1460015040, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 143168688433, next_for_neutral_type = 5, last_strong_type = 1, prev_for_neutral_type = 5, level = 147 '\223', flags = 242 '\362' }, { next_for_neutral_pos = 140737488301664, next_for_neutral_type = 7, last_strong_type = 2, prev_for_neutral_type = 1, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 145803700045, next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488301696, next_for_neutral_type = 7, last_strong_type = 2, prev_for_neutral_type = 1, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 6, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 3, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993705751, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 140737263167309, next_for_neutral_type = 5, last_strong_type = 1, prev_for_neutral_type = 5, level = 147 '\223', flags = 242 '\362' }, { next_for_neutral_pos = 6, next_for_neutral_type = 7, last_strong_type = 2, prev_for_neutral_type = 1, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 140737263167304, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993705776, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 140737263158717, next_for_neutral_type = 5, last_strong_type = 7, prev_for_neutral_type = 6, level = 147 '\223', flags = 242 '\362' }, { next_for_neutral_pos = 6, next_for_neutral_type = 7, last_strong_type = 2, prev_for_neutral_type = 1, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 140737263158712, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 5, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993705776, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488301888, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 107 'k', flags = 85 'U' }, { next_for_neutral_pos = 4069713512, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993706077, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 140737263024437, next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737263024432, next_for_neutral_type = 4, last_strong_type = 6, prev_for_neutral_type = 3, level = 142 '\216', flags = 85 'U' }, { next_for_neutral_pos = 3, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824996001446, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825020854964, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993821052, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825033784581, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824993821523, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }}, string = { lstring = XIL(0), s = 0x7fffffff3020 "P0\377\377\377\177", schars = 93825033784576, bufpos = 140737488302112, from_disp_str = true, unibyte = false }, w = 0x0, paragraph_dir = NEUTRAL_DIR, separator_limit = 93825033784576, first_elt = true, new_paragraph = false, frame_window_p = true }, paragraph_embedding = (unknown: 0xffff3050), min_width_property = XIL(0x5555556e512f), min_width_start = 1446970624 } it_copy_data = 0x0 #6 0x00005555555e7726 in get_next_display_element (it=0x7fffffffa820) at xdisp.c:8718 face_id = 24 success_p = true #7 0x00005555555eb11d in move_it_in_display_line_to (it=0x7fffffffa820, to_charpos=9562, to_x=693, op=MOVE_TO_X) at xdisp.c:10107 x = 177 i = 1 ascent = 0 descent = 0 result = MOVE_UNDEFINED saved_glyph_row = 0x555556a12930 wrap_it = { window = XIL(0x1), w = 0x0, f = 0x0, method = GET_FROM_BUFFER, stop_charpos = 93825005706461, prev_stop = 93825005706456, base_level_stop = 93825005705760, end_charpos = 0, medium_narrowing_begv = 5894, medium_narrowing_zv = 0, large_narrowing_begv = 5873, large_narrowing_zv = 9562, s = 0x0, string_nchars = 0, multibyte_p = false, tab_line_p = false, header_line_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, from_disp_prop_p = false, ellipsis_p = false, avoid_cursor_p = false, dp = 0x0, dpvec = 0x0, dpend = 0x0, dpvec_char_len = 5, dpvec_face_id = 0, saved_face_id = 0, ctl_chars = {XIL(0), XIL(0), XIL(0), XIL(0x18), XIL(0) <repeats 12 times>}, start = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 5874 }, dpvec_index = 8704 }, current = { pos = { charpos = -1, bytepos = -1 }, overlay_string_index = -1, string_pos = { charpos = 4294967295, bytepos = 5874 }, dpvec_index = 8704 }, n_overlay_strings = -1, overlay_strings_charpos = -1, overlay_strings = {XIL(0xffffffffffffffff), XIL(0xffffffff), XIL(0), make_fixnum(1468), XIL(0) <repeats 12 times>}, string_overlays = {XIL(0) <repeats 16 times>}, string = XIL(0), from_overlay = XIL(0), stack = {{ string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }}, sp = -1, selective = 0, what = IT_CHARACTER, face_id = 0, selective_display_ellipsis_p = false, ctl_arrow_p = false, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = false, ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false, line_number_produced_p = false, align_visually_p = false, line_wrap = TRUNCATE, base_face_id = 0, c = 0, len = 0, cmp_it = { stop_pos = 103079215105, id = 7, ch = 0, rule_idx = 3, lookback = 5874, nglyphs = 829, reversed_p = false, parent_it = 0xba4, charpos = 0, nchars = 0, nbytes = 0, from = 3, to = 0, width = -22496 }, char_to_display = 5874, glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id = 25769803778, xwidget = 0x200000000, slice = { x = XIL(0x1), y = XIL(0), width = XIL(0), height = XIL(0) }, space_width = XIL(0), voffset = 0, tab_width = 0, font_height = XIL(0), object = XIL(0), position = { charpos = 0, bytepos = 524288 }, truncation_pixel_width = 0, continuation_pixel_width = 0, first_visible_x = 0, last_visible_x = 1450507077, last_visible_y = 21845, extra_line_spacing = 5874, max_extra_line_spacing = 0, override_ascent = 8704, override_descent = 0, override_boff = 9, glyph_row = 0x286000002d0, area = LEFT_MARGIN_AREA, nglyphs = 0, pixel_width = -1, ascent = 0, descent = 0, max_ascent = 0, max_descent = 1453402416, phys_ascent = 21845, phys_descent = 1, max_phys_ascent = 1, max_phys_descent = 12, current_x = 19, wrap_prefix_width = 9, continuation_lines_width = 19, eol_pos = { charpos = 73014444041, bytepos = 73014444039 }, current_y = 7, first_vpos = 12, vpos = 0, hpos = 0, lnum = 0, lnum_bytepos = 0, lnum_width = 0, lnum_pixel_width = 1, pt_lnum = 4294967296, stretch_adjust = 0, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = false, bidi_it = { bytepos = 0, charpos = 0, ch = 0, nchars = 0, ch_len = 0, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT, orig_type = UNKNOWN_BT, resolved_level = 0 '\000', isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0, prev = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, last_strong = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, prev_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_ws = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, bracket_pairing_pos = 0, bracket_enclosed_type = UNKNOWN_BT, next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = NEUTRAL_DIR, scan_dir = 0, disp_pos = 0, disp_prop = 0, stack_idx = 0, level_stack = {{ next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' } <repeats 128 times>}, string = { lstring = XIL(0), s = 0x0, schars = 0, bufpos = 0, from_disp_str = false, unibyte = false }, w = 0x0, paragraph_dir = NEUTRAL_DIR, separator_limit = 0, first_elt = false, new_paragraph = false, frame_window_p = false }, paragraph_embedding = (unknown: 0x5622dcd8), min_width_property = XIL(0), min_width_start = 0 } atpos_it = { window = XIL(0x7fffffff6d40), w = 0xcde, f = 0x869, method = 4294930000, stop_charpos = 93825005706461, prev_stop = 93825005706456, base_level_stop = 93825005705760, end_charpos = 0, medium_narrowing_begv = 5894, medium_narrowing_zv = 0, large_narrowing_begv = 5873, large_narrowing_zv = 9562, s = 0x0, string_nchars = 0, multibyte_p = false, tab_line_p = false, header_line_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, from_disp_prop_p = false, ellipsis_p = false, avoid_cursor_p = false, dp = 0x0, dpvec = 0x0, dpend = 0x0, dpvec_char_len = 5, dpvec_face_id = 0, saved_face_id = 0, ctl_chars = {XIL(0), XIL(0), XIL(0), XIL(0x18), XIL(0) <repeats 12 times>}, start = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 5874 }, dpvec_index = 8704 }, current = { pos = { charpos = -1, bytepos = -1 }, overlay_string_index = -1, string_pos = { charpos = 4294967295, bytepos = 5874 }, dpvec_index = 8704 }, n_overlay_strings = -1, overlay_strings_charpos = -1, overlay_strings = {XIL(0xffffffffffffffff), XIL(0xffffffff), XIL(0), make_fixnum(1468), XIL(0) <repeats 12 times>}, string_overlays = {XIL(0) <repeats 16 times>}, string = XIL(0), from_overlay = XIL(0), stack = {{ string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }}, sp = -1, selective = 0, what = IT_CHARACTER, face_id = 0, selective_display_ellipsis_p = false, ctl_arrow_p = false, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = false, ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false, line_number_produced_p = false, align_visually_p = false, line_wrap = TRUNCATE, base_face_id = 0, c = 0, len = 0, cmp_it = { stop_pos = 103079215105, id = 7, ch = 0, rule_idx = 3, lookback = 5874, nglyphs = 829, reversed_p = false, parent_it = 0xba4, charpos = 0, nchars = 0, nbytes = 0, from = 3, to = 0, width = -22496 }, char_to_display = 5874, glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id = 25769803778, xwidget = 0x200000000, slice = { x = XIL(0x1), y = XIL(0), width = XIL(0), height = XIL(0) }, space_width = XIL(0), voffset = 0, tab_width = 0, font_height = XIL(0), object = XIL(0), position = { charpos = 0, bytepos = 524288 }, truncation_pixel_width = 0, continuation_pixel_width = 0, first_visible_x = 0, last_visible_x = 1450507077, last_visible_y = 21845, extra_line_spacing = 5874, max_extra_line_spacing = 0, override_ascent = 8704, override_descent = 0, override_boff = 9, glyph_row = 0x286000002d0, area = LEFT_MARGIN_AREA, nglyphs = 0, pixel_width = -1, ascent = 0, descent = 0, max_ascent = 0, max_descent = 1453402416, phys_ascent = 21845, phys_descent = 1, max_phys_ascent = 1, max_phys_descent = 12, current_x = 19, wrap_prefix_width = 9, continuation_lines_width = 19, eol_pos = { charpos = 73014444041, bytepos = 73014444039 }, current_y = 7, first_vpos = 12, vpos = 0, hpos = 0, lnum = 0, lnum_bytepos = 0, lnum_width = 0, lnum_pixel_width = 1, pt_lnum = 4294967296, stretch_adjust = 0, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = false, bidi_it = { bytepos = 0, charpos = 0, ch = 0, nchars = 0, ch_len = 0, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT, orig_type = UNKNOWN_BT, resolved_level = 0 '\000', isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0, prev = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, last_strong = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, prev_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_ws = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, bracket_pairing_pos = 0, bracket_enclosed_type = UNKNOWN_BT, next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = NEUTRAL_DIR, scan_dir = 0, disp_pos = 0, disp_prop = 0, stack_idx = 0, level_stack = {{ next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' } <repeats 128 times>}, string = { lstring = XIL(0), s = 0x0, schars = 0, bufpos = 0, from_disp_str = false, unibyte = false }, w = 0x0, paragraph_dir = NEUTRAL_DIR, separator_limit = 0, first_elt = false, new_paragraph = false, frame_window_p = false }, paragraph_embedding = (unknown: 0x5622dcd8), min_width_property = XIL(0), min_width_start = 0 } atx_it = { window = XIL(0), w = 0x0, f = 0x0, method = 24, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, end_charpos = 0, medium_narrowing_begv = 0, medium_narrowing_zv = 0, large_narrowing_begv = 0, large_narrowing_zv = 0, s = 0x0, string_nchars = 0, multibyte_p = false, tab_line_p = false, header_line_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, from_disp_prop_p = false, ellipsis_p = false, avoid_cursor_p = false, dp = 0x0, dpvec = 0x0, dpend = 0x0, dpvec_char_len = 0, dpvec_face_id = 0, saved_face_id = 0, ctl_chars = {make_fixnum(1468), XIL(0x2200), XIL(0xffffffffffffffff), XIL(0xffffffffffffffff), XIL(0xffffffffffffffff), XIL(0xffffffff), XIL(0x16f0), XIL(0x21fc), XIL(0xffffffffffffffff), XIL(0xffffffffffffffff), XIL(0xffffffffffffffff), XIL(0xffffffff), XIL(0), make_fixnum(1468), XIL(0), XIL(0)}, start = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, n_overlay_strings = 0, overlay_strings_charpos = 0, overlay_strings = {XIL(0) <repeats 16 times>}, string_overlays = {XIL(0) <repeats 16 times>}, string = XIL(0), from_overlay = XIL(0), stack = {{ string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 103079215105, bytepos = 7 }, current = { pos = { charpos = 12799002542080, bytepos = 3 }, overlay_string_index = 5874, string_pos = { charpos = 829, bytepos = 2980 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LAST_AREA, method = GET_FROM_BUFFER, paragraph_embedding = (unknown: 0xffffa820), multibyte_p = true, string_from_display_prop_p = true, string_from_prefix_prop_p = true, display_ellipsis_p = true, avoid_cursor_p = true, bidi_p = true, from_disp_prop_p = true, line_wrap = (WINDOW_WRAP | unknown: 0x16f0), voffset = 0, space_width = make_fixnum(6442450944), font_height = XIL(0x200000000) }}, sp = -1, selective = 0, what = IT_CHARACTER, face_id = 0, selective_display_ellipsis_p = false, ctl_arrow_p = false, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = false, ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false, line_number_produced_p = false, align_visually_p = false, line_wrap = TRUNCATE, base_face_id = 0, c = 0, len = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 524288, lookback = 0, nglyphs = 1450507077, reversed_p = 85, parent_it = 0x16f2, charpos = 8704, nchars = 9, nbytes = 0, from = 720, to = 646, width = 0 }, char_to_display = -1, glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id = 0, xwidget = 0x555556a12930, slice = { x = XIL(0x100000001), y = make_fixnum(20401094659), width = XIL(0x1300000009), height = XIL(0x1100000009) }, space_width = XIL(0x1100000007), voffset = 7, tab_width = 0, font_height = XIL(0), object = XIL(0), position = { charpos = 0, bytepos = 4294967296 }, truncation_pixel_width = 0, continuation_pixel_width = 0, first_visible_x = 1, last_visible_x = 0, last_visible_y = 0, extra_line_spacing = 0, max_extra_line_spacing = 0, override_ascent = 0, override_descent = 0, override_boff = 0, glyph_row = 0x0, area = LEFT_MARGIN_AREA, nglyphs = 0, pixel_width = 0, ascent = 0, descent = 0, max_ascent = 0, max_descent = 0, phys_ascent = 0, phys_descent = 0, max_phys_ascent = 0, max_phys_descent = 0, current_x = 0, wrap_prefix_width = 0, continuation_lines_width = 0, eol_pos = { charpos = 0, bytepos = 0 }, current_y = 0, first_vpos = 0, vpos = 0, hpos = 0, lnum = 0, lnum_bytepos = 0, lnum_width = 0, lnum_pixel_width = 0, pt_lnum = 0, stretch_adjust = 0, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = false, bidi_it = { bytepos = 0, charpos = 0, ch = 0, nchars = 0, ch_len = 0, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT, orig_type = UNKNOWN_BT, resolved_level = 0 '\000', isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0, prev = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, last_strong = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, prev_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_ws = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, bracket_pairing_pos = 0, bracket_enclosed_type = UNKNOWN_BT, next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = NEUTRAL_DIR, scan_dir = 0, disp_pos = 0, disp_prop = 0, stack_idx = 0, level_stack = {{ next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' } <repeats 122 times>, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 3, prev_for_neutral_type = 3, level = 34 '"', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488317424, next_for_neutral_type = 3, last_strong_type = 1, prev_for_neutral_type = 5, level = 92 '\\', flags = 85 'U' }, { next_for_neutral_pos = 1445125336, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }}, string = { lstring = XIL(0x5555556c062f), s = 0x7fffffff6c30 "\300\223\377\377\377\177", schars = 93824993727756, bufpos = 4294967308, from_disp_str = false, unibyte = false }, w = 0x20, paragraph_dir = NEUTRAL_DIR, separator_limit = 140737488327616, first_elt = true, new_paragraph = false, frame_window_p = true }, paragraph_embedding = (unknown: 0xffff6d08), min_width_property = XIL(0x7fffffffa820), min_width_start = -164103488 } ppos_it = { window = XIL(0), w = 0xac8, f = 0x16800000c30, method = GET_FROM_BUFFER, stop_charpos = 4294967295, prev_stop = 140737488308384, base_level_stop = 0, end_charpos = 0, medium_narrowing_begv = 0, medium_narrowing_zv = 547, large_narrowing_begv = 7215545057282, large_narrowing_zv = 3360, s = 0xd2000000690 <error: Cannot access memory at address 0xd2000000690>, string_nchars = 15461882267520, multibyte_p = false, tab_line_p = false, header_line_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, from_disp_prop_p = true, ellipsis_p = false, avoid_cursor_p = false, dp = 0xffffffff, dpvec = 0x7fffffff4480, dpend = 0x7fffffff46e8, dpvec_char_len = -47912, dpvec_face_id = 32767, saved_face_id = 0, ctl_chars = {XIL(0xaf5), make_fixnum(2061584302080), XIL(0xc30), XIL(0xc3000000780), XIL(0xd2000000690), XIL(0xd2000000c30), XIL(0xffffffff), XIL(0x7fffffff4428), XIL(0x7fffffff4690), XIL(0x7fffffff45e0), XIL(0), XIL(0xc33), make_fixnum(2061584302080), XIL(0xc30), XIL(0xc3000000780), XIL(0xd2000000870)}, start = { pos = { charpos = 14431090117680, bytepos = 1 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 140737488307504 }, dpvec_index = 0 }, current = { pos = { charpos = 3120, bytepos = 9277129359362 }, overlay_string_index = 3360, string_pos = { charpos = 14431090116720, bytepos = 15461882267520 }, dpvec_index = 3360 }, n_overlay_strings = 1, overlay_strings_charpos = 0, overlay_strings = {XIL(0), XIL(0x7fffffff44d8), XIL(0), XIL(0xd98), make_fixnum(2963527434240), make_fixnum(697), XIL(0xae600000ac8), make_fixnum(3092376453787), make_fixnum(3092376453817), XIL(0x1), XIL(0), XIL(0), XIL(0x7fffffff4530), XIL(0), make_fixnum(697), make_fixnum(1159641169920)}, string_overlays = {make_fixnum(697), XIL(0xae600000438), make_fixnum(3092376453412), make_fixnum(3092376453817), XIL(0xffffffff), XIL(0x7fffffff4428), XIL(0x7fffffff4740), XIL(0x7fffffff4530), XIL(0), XIL(0x9cd), make_fixnum(1159641169920), make_fixnum(112), XIL(0x1c200000438), XIL(0xae600000438), make_fixnum(2995739689072), XIL(0xffffffff)}, string = XIL(0x7fffffff4428), from_overlay = XIL(0x7fffffff48f8), stack = {{ string = XIL(0x7fffffff4798), string_nchars = 0, end_charpos = 2725, stop_charpos = 5025111736322, prev_stop = 360, base_level_stop = 1546188227730, cmp_it = { stop_pos = 1932735284280, id = 1932735283560, ch = -1, rule_idx = 140737488307240, lookback = 140737488308384, nglyphs = -47120, reversed_p = 255, parent_it = 0x0, charpos = 1381, nchars = 2, nbytes = 2670, from = 360, to = 0, width = 2670 }, face_id = 2760, u = { image = { object = XIL(0x1c200000168), slice = { x = XIL(0x1), y = XIL(0), width = XIL(0), height = XIL(0x7fffffff4530) }, image_id = 0 }, stretch = { object = XIL(0x1c200000168) }, xwidget = { object = XIL(0x1c200000168) } }, position = { charpos = 360, bytepos = 11854109736962 }, current = { pos = { charpos = 450, bytepos = 1932735285960 }, overlay_string_index = 11982958758600, string_pos = { charpos = 11982958756290, bytepos = 1 }, dpvec_index = 0 }, from_overlay = XIL(0), area = -47824, method = 32767, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = (WINDOW_WRAP | unknown: 0x1c0), voffset = 0, space_width = make_fixnum(2093796556800), font_height = XIL(0x675) }, { string = make_fixnum(1774895235559), string_nchars = 1950, end_charpos = 9848360011381, stop_charpos = 4294967295, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 140737488307152, id = 0, ch = 1964, rule_idx = 15981573308418, lookback = 1653, nglyphs = 3721, reversed_p = 117, parent_it = 0x7ac00000ea6, charpos = 8435315770997, nchars = 1, nbytes = 0, from = -46768, to = 32767, width = 0 }, face_id = -48176, u = { image = { object = XIL(0), slice = { x = XIL(0), y = make_fixnum(978178801664), width = XIL(0x758), height = XIL(0x7580000038f) }, image_id = 8705898709882 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 8705898710872, bytepos = 4294967295 }, current = { pos = { charpos = 140737488307328, bytepos = 140737488308560 }, overlay_string_index = 140737488308648, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 2 }, from_overlay = XIL(0x4a4), area = 2704, method = 1188, paragraph_embedding = (L2R | R2L | unknown: 0x38c), multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = true, avoid_cursor_p = true, bidi_p = false, from_disp_prop_p = true, line_wrap = (unknown: 0x4a4), voffset = 1880, space_width = XIL(0xffffffff), font_height = XIL(0x7fffffff4428) }, { string = XIL(0x7fffffff4950), string_nchars = -46592, end_charpos = 0, stop_charpos = 0, prev_stop = 11613591568386, base_level_stop = 1188, cmp_it = { stop_pos = 5102421150352, id = 5729486375698, ch = 1188, rule_idx = 1, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x7fffffff45e0, charpos = 0, nchars = 1188, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0x7fffffff4c08), string_nchars = -46128, end_charpos = 0, stop_charpos = 32, prev_stop = 0, base_level_stop = 3745211483112, cmp_it = { stop_pos = 140737488309352, id = 140737488309320, ch = 3840, rule_idx = 140737488307328, lookback = 0, nglyphs = -46104, reversed_p = 255, parent_it = 0xf00, charpos = 140737488307416, nchars = 0, nbytes = 0, from = 0, to = 0, width = 3600 }, face_id = -47648, u = { image = { object = XIL(0), slice = { x = XIL(0x7fffffff4c28), y = XIL(0xe10), width = XIL(0x7fffffff46e8), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 2548, bytepos = 93825082857248 }, current = { pos = { charpos = 0, bytepos = 140737488309224 }, overlay_string_index = 3721, string_pos = { charpos = 93825082854256, bytepos = 0 }, dpvec_index = -45880 }, from_overlay = make_fixnum(716), area = 1522274896, method = 21845, paragraph_embedding = (L2R | R2L | unknown: 0xfffffffc), multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = (unknown: 0xffff4c68), voffset = 32767, space_width = XIL(0x9f4), font_height = XIL(0x55555abc16c8) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = -1 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 214748364801 }, dpvec_index = 3 }, from_overlay = XIL(0xb9a00000000), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = L2R, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = (unknown: 0x2c8), voffset = 0, space_width = make_fixnum(742), font_height = XIL(0) }}, sp = 0, selective = 1, what = 4294944672, face_id = 32767, selective_display_ellipsis_p = true, ctl_arrow_p = false, face_box_p = false, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = false, ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false, line_number_produced_p = false, align_visually_p = false, line_wrap = TRUNCATE, base_face_id = 1, c = 3, len = 0, cmp_it = { stop_pos = 1, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 524288, to = 0, width = 0 }, char_to_display = 1473344525, glyphless_method = 21845, image_id = 1, xwidget = 0x1, slice = { x = XIL(0x90000), y = XIL(0x286000002d0), width = XIL(0), height = XIL(0xffffffff) }, space_width = XIL(0), voffset = 10288, tab_width = 22177, font_height = XIL(0x100000001), object = XIL(0xf0000000c), position = { charpos = 6, bytepos = 64424509440 }, truncation_pixel_width = 6, continuation_pixel_width = 0, first_visible_x = 15, last_visible_x = 6, last_visible_y = 0, extra_line_spacing = 0, max_extra_line_spacing = 0, override_ascent = 0, override_descent = 0, override_boff = 0, glyph_row = 0x0, area = LEFT_MARGIN_AREA, nglyphs = 0, pixel_width = 0, ascent = 0, descent = 0, max_ascent = 0, max_descent = 0, phys_ascent = 0, phys_descent = 0, max_phys_ascent = 0, max_phys_descent = 0, current_x = 0, wrap_prefix_width = 0, continuation_lines_width = 0, eol_pos = { charpos = 0, bytepos = 0 }, current_y = 0, first_vpos = 0, vpos = 0, hpos = 0, lnum = 0, lnum_bytepos = 0, lnum_width = 0, lnum_pixel_width = 0, pt_lnum = 0, stretch_adjust = 0, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = false, bidi_it = { bytepos = 0, charpos = 0, ch = 0, nchars = 4398046511104, ch_len = 140737488310240, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT, orig_type = UNKNOWN_BT, resolved_level = 0 '\000', isolate_level = 0 '\000', invalid_levels = 140737488309256, invalid_isolates = 140737488309224, prev = { charpos = 140737488309256, type = 4294921192, orig_type = 32767 }, last_strong = { charpos = 140737488309384, type = 4294921352, orig_type = 32767 }, next_for_neutral = { charpos = 140737488309320, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, prev_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_ws = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, bracket_pairing_pos = 0, bracket_enclosed_type = UNKNOWN_BT, next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = NEUTRAL_DIR, scan_dir = 0, disp_pos = 0, disp_prop = 0, stack_idx = 0, level_stack = {{ next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825084191728, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825084191728, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 5, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995347755, next_for_neutral_type = 2, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488310672, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488310640, next_for_neutral_type = 4, last_strong_type = 2, prev_for_neutral_type = 2, level = 132 '\204', flags = 85 'U' }, { next_for_neutral_pos = 1460017216, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 3712, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824994966495, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825020598336, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824994966894, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 3712, next_for_neutral_type = 0, last_strong_type = 5, prev_for_neutral_type = 0, level = 126 '~', flags = 85 'U' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 5, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995035487, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 1, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 1, last_strong_type = 5, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 6, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643114, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 9, next_for_neutral_type = 3, last_strong_type = 5, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 4, last_strong_type = 1, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643116, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 15, next_for_neutral_type = 5, last_strong_type = 5, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 2, last_strong_type = 2, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643118, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 21, next_for_neutral_type = 7, last_strong_type = 5, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 0, last_strong_type = 3, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643120, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 27, next_for_neutral_type = 1, last_strong_type = 6, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 6, last_strong_type = 3, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643122, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 33, next_for_neutral_type = 3, last_strong_type = 6, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 4, last_strong_type = 4, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643124, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 39, next_for_neutral_type = 5, last_strong_type = 6, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 2, last_strong_type = 5, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643126, next_for_neutral_type = 4, last_strong_type = 0, prev_for_neutral_type = 1, level = 96 '`', flags = 89 'Y' }, { next_for_neutral_pos = 45, next_for_neutral_type = 7, last_strong_type = 6, prev_for_neutral_type = 4, level = 18 '\022', flags = 86 'V' }, { next_for_neutral_pos = 93825060053572, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825004643128, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311200, next_for_neutral_type = 3, last_strong_type = 7, prev_for_neutral_type = 3, level = 135 '\207', flags = 85 'U' }, { next_for_neutral_pos = 1434766635, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995553409, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 3, next_for_neutral_type = 3, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311907, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311280, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = -997, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311910, next_for_neutral_type = 0, last_strong_type = 3, prev_for_neutral_type = 4, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 100, next_for_neutral_type = 0, last_strong_type = 3, prev_for_neutral_type = 4, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 140737488311344, next_for_neutral_type = 3, last_strong_type = 5, prev_for_neutral_type = 4, level = 130 '\202', flags = 85 'U' }, { next_for_neutral_pos = 140737266045208, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995168311, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 1, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 140737266045208, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995180560, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737266045208, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 6, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995180560, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 140737263369016, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737266047552, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995180560, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 1, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 140737488311536, next_for_neutral_type = 4, last_strong_type = 5, prev_for_neutral_type = 3, level = 130 '\202', flags = 85 'U' }, { next_for_neutral_pos = 140737266047584, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 4, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995168086, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 4, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 140737266047584, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 4, level = 191 '\277', flags = 242 '\362' }, { next_for_neutral_pos = 140737488311600, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311632, next_for_neutral_type = 2, last_strong_type = 4, prev_for_neutral_type = 6, level = 133 '\205', flags = 85 'U' }, { next_for_neutral_pos = 1450507077, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311696, next_for_neutral_type = 2, last_strong_type = 4, prev_for_neutral_type = 6, level = 133 '\205', flags = 85 'U' }, { next_for_neutral_pos = 1434823429, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311744, next_for_neutral_type = 2, last_strong_type = 4, prev_for_neutral_type = 6, level = 133 '\205', flags = 85 'U' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995395398, next_for_neutral_type = 3, last_strong_type = 2, prev_for_neutral_type = 3, level = 23 '\027', flags = 87 'W' }, { next_for_neutral_pos = 28752, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488311824, next_for_neutral_type = 6, last_strong_type = 4, prev_for_neutral_type = 4, level = 141 '\215', flags = 85 'U' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995954781, next_for_neutral_type = 2, last_strong_type = 0, prev_for_neutral_type = 7, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 4294967296, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825080158979, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 3, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 17149872, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825005706461, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 2, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995954300, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825080158979, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 3, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995974109, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825011088197, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 23490, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824995975109, next_for_neutral_type = 0, last_strong_type = 7, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93825011088197, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 23490, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 5872, next_for_neutral_type = 1, last_strong_type = 6, prev_for_neutral_type = 3, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 1, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 17089760, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 4, level = 11 '\v', flags = 86 'V' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488312160, next_for_neutral_type = 6, last_strong_type = 4, prev_for_neutral_type = 4, level = 141 '\215', flags = 85 'U' }, { next_for_neutral_pos = 1519577827, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824996508298, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 3, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488317408, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 8, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 4611686018427387904, next_for_neutral_type = 7, last_strong_type = 7, prev_for_neutral_type = 7, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 8, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 93825013983536, next_for_neutral_type = 0, last_strong_type = 2, prev_for_neutral_type = 1, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93823560581132, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 72198327231315968, next_for_neutral_type = 1, last_strong_type = 6, prev_for_neutral_type = 3, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 55834574848, next_for_neutral_type = 5, last_strong_type = 0, prev_for_neutral_type = 5, level = 116 't', flags = 86 'V' }, { next_for_neutral_pos = 140737488312384, next_for_neutral_type = 5, last_strong_type = 3, prev_for_neutral_type = 6, level = 92 '\\', flags = 85 'U' }, { next_for_neutral_pos = 93825011088197, next_for_neutral_type = 0, last_strong_type = 6, prev_for_neutral_type = 0, level = 255 '\377', flags = 255 '\377' }, { next_for_neutral_pos = 93824992867370, next_for_neutral_type = 0, last_strong_type = 1, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = -1, next_for_neutral_type = 2, last_strong_type = 6, prev_for_neutral_type = 3, level = 0 '\000', flags = 0 '\000' }, { next_for_neutral_pos = 140737488322544, next_for_neutral_type = 5, last_strong_type = 3, prev_for_neutral_type = 3, level = 34 '"', flags = 86 'V' }, { next_for_neutral_pos = 93825005706456, next_for_neutral_type = 0, last_strong_type = 4, prev_for_neutral_type = 0, level = 34 '"', flags = 86 'V' }}, string = { lstring = XIL(0), s = 0x1706 <error: Cannot access memory at address 0x1706>, schars = 0, bufpos = 0, from_disp_str = false, unibyte = true }, w = 0x0, paragraph_dir = NEUTRAL_DIR, separator_limit = 0, first_elt = false, new_paragraph = false, frame_window_p = false }, paragraph_embedding = NEUTRAL_DIR, min_width_property = XIL(0), min_width_start = 5 } wrap_data = 0x0 atpos_data = 0x0 atx_data = 0x0 ppos_data = 0x0 may_wrap = false prev_method = GET_FROM_BUFFER closest_pos = 0 prev_pos = 5887 saw_smaller_pos = true line_number_pending = false this_line_subject_to_line_prefix = 0 atx_flag = 0 atpos_flag = 5874 wrap_flag = 0 #8 0x00005555555ee3e5 in move_it_in_display_line (it=0x7fffffffa820, to_charpos=9562, to_x=693, op=MOVE_TO_X) at xdisp.c:10728 #9 0x00005555557e4733 in Fvertical_motion (lines=make_fixnum(0), window=XIL(0), cur_col=XIL(0)) at indent.c:2451 it_start = 5874 start_col = 0 start_x = 0 it_overshoot_count = 1 first_x = 0 overshoot_handled = false disp_string_at_start_p = false vpos_init = 0 start_x_given = false nlines = 0 to_x = 693 lnum_width = 0 lnum_pixel_width = 0 it = { window = XIL(0x55555622dcdd), w = 0x55555622dcd8, f = 0x55555622da20, method = GET_FROM_BUFFER, stop_charpos = 5894, prev_stop = 0, base_level_stop = 5873, end_charpos = 9562, medium_narrowing_begv = 0, medium_narrowing_zv = 0, large_narrowing_begv = 0, large_narrowing_zv = 0, s = 0x0, string_nchars = 0, multibyte_p = true, tab_line_p = false, header_line_p = true, string_from_display_prop_p = false, string_from_prefix_prop_p = false, from_disp_prop_p = false, ellipsis_p = false, avoid_cursor_p = false, dp = 0x0, dpvec = 0x0, dpend = 0x0, dpvec_char_len = 0, dpvec_face_id = 0, saved_face_id = 24, ctl_chars = {XIL(0) <repeats 16 times>}, start = { pos = { charpos = 5874, bytepos = 8704 }, overlay_string_index = -1, string_pos = { charpos = -1, bytepos = -1 }, dpvec_index = -1 }, current = { pos = { charpos = 5889, bytepos = 8747 }, overlay_string_index = -1, string_pos = { charpos = -1, bytepos = -1 }, dpvec_index = -1 }, n_overlay_strings = 0, overlay_strings_charpos = 5874, overlay_strings = {XIL(0) <repeats 16 times>}, string_overlays = {XIL(0) <repeats 16 times>}, string = XIL(0), from_overlay = XIL(0), stack = {{ string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }, { string = XIL(0), string_nchars = 0, end_charpos = 0, stop_charpos = 0, prev_stop = 0, base_level_stop = 0, cmp_it = { stop_pos = 0, id = 0, ch = 0, rule_idx = 0, lookback = 0, nglyphs = 0, reversed_p = false, parent_it = 0x0, charpos = 0, nchars = 0, nbytes = 0, from = 0, to = 0, width = 0 }, face_id = 0, u = { image = { object = XIL(0), slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, image_id = 0 }, stretch = { object = XIL(0) }, xwidget = { object = XIL(0) } }, position = { charpos = 0, bytepos = 0 }, current = { pos = { charpos = 0, bytepos = 0 }, overlay_string_index = 0, string_pos = { charpos = 0, bytepos = 0 }, dpvec_index = 0 }, from_overlay = XIL(0), area = LEFT_MARGIN_AREA, method = GET_FROM_BUFFER, paragraph_embedding = NEUTRAL_DIR, multibyte_p = false, string_from_display_prop_p = false, string_from_prefix_prop_p = false, display_ellipsis_p = false, avoid_cursor_p = false, bidi_p = false, from_disp_prop_p = false, line_wrap = TRUNCATE, voffset = 0, space_width = XIL(0), font_height = XIL(0) }}, sp = 0, selective = 0, what = IT_COMPOSITION, face_id = 24, selective_display_ellipsis_p = true, ctl_arrow_p = true, face_box_p = true, start_of_box_run_p = false, end_of_box_run_p = false, overlay_strings_at_end_processed_p = false, ignore_overlay_strings_at_pos_p = false, glyph_not_available_p = false, starts_in_middle_of_char_p = false, face_before_selective_p = false, constrain_row_ascent_descent_p = false, line_number_produced_p = false, align_visually_p = false, line_wrap = TRUNCATE, base_face_id = 0, c = 2980, len = 6, cmp_it = { stop_pos = 5887, id = 827, ch = 2984, rule_idx = 0, lookback = 0, nglyphs = 3, reversed_p = false, parent_it = 0x7fffffffa820, charpos = 5889, nchars = 1, nbytes = 3, from = 2, to = 3, width = 1 }, char_to_display = 32, glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE, image_id = 0, xwidget = 0x0, slice = { x = XIL(0), y = XIL(0), width = XIL(0), height = XIL(0) }, space_width = XIL(0), voffset = 0, tab_width = 8, font_height = XIL(0), object = XIL(0x55555674fb45), position = { charpos = 5889, bytepos = 8747 }, truncation_pixel_width = 9, continuation_pixel_width = 0, first_visible_x = 0, last_visible_x = 720, last_visible_y = 646, extra_line_spacing = 0, max_extra_line_spacing = 0, override_ascent = -1, override_descent = 0, override_boff = 0, glyph_row = 0x0, area = TEXT_AREA, nglyphs = 1, pixel_width = 14, ascent = 19, descent = 9, max_ascent = 19, max_descent = 10, phys_ascent = 17, phys_descent = 7, max_phys_ascent = 17, max_phys_descent = 8, current_x = 177, wrap_prefix_width = 0, continuation_lines_width = 0, eol_pos = { charpos = 0, bytepos = 0 }, current_y = 0, first_vpos = 1, vpos = 0, hpos = 10, lnum = 0, lnum_bytepos = 0, lnum_width = 0, lnum_pixel_width = 0, pt_lnum = 0, stretch_adjust = 0, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, bidi_p = false, bidi_it = { bytepos = 0, charpos = 0, ch = 0, nchars = 0, ch_len = 0, type = UNKNOWN_BT, type_after_wn = UNKNOWN_BT, orig_type = UNKNOWN_BT, resolved_level = 0 '\000', isolate_level = 0 '\000', invalid_levels = 0, invalid_isolates = 0, prev = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, last_strong = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, prev_for_neutral = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, next_for_ws = { charpos = 0, type = UNKNOWN_BT, orig_type = UNKNOWN_BT }, bracket_pairing_pos = 0, bracket_enclosed_type = UNKNOWN_BT, next_en_pos = 0, next_en_type = UNKNOWN_BT, sos = NEUTRAL_DIR, scan_dir = 0, disp_pos = 0, disp_prop = 0, stack_idx = 0, level_stack = {{ next_for_neutral_pos = 0, next_for_neutral_type = 0, last_strong_type = 0, prev_for_neutral_type = 0, level = 0 '\000', flags = 0 '\000' } <repeats 128 times>}, string = { lstring = XIL(0), s = 0x0, schars = 0, bufpos = 0, from_disp_str = false, unibyte = false }, w = 0x55555622dcd8, paragraph_dir = NEUTRAL_DIR, separator_limit = 0, first_elt = false, new_paragraph = false, frame_window_p = false }, paragraph_embedding = L2R, min_width_property = XIL(0), min_width_start = 0 } pt = { charpos = 5874, bytepos = 8704 } w = 0x55555622dcd8 lcols = make_fixnum(77) itdata = 0x0 count = { bytes = 1504 } #10 0x000055555584b363 in funcall_subr (subr=0x55555602c420 <Svertical_motion>, numargs=1, args=0x7ffff1a004a0) at eval.c:3151 argbuf = {XIL(0x55555a959d73), XIL(0), XIL(0), XIL(0x5c0), XIL(0x7fffffffbc70), XIL(0x12558a8305), XIL(0x55555602c425), XIL(0x7fffffffbc90)} a = 0x7fffffffbc40 maxargs = 3 fun = make_fixnum(23456248930209) #11 0x00005555558a95f3 in exec_byte_code (fun=XIL(0x55555710f7d5), args_template=257, nargs=1, args=0x7ffff1a00438) at bytecode.c:813 call_nargs = 1 call_fun = XIL(0x55555602c425) count1 = { bytes = 1472 } val = make_fixnum(9) call_args = 0x7ffff1a004a0 original_fun = XIL(0x2aaa9c361bf8) op = 1 type = CATCHER targets = {0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad565 <exec_byte_code+19810>, 0x5555558ad567 <exec_byte_code+19812>, 0x5555558ad569 <exec_byte_code+19814>, 0x5555558ad56b <exec_byte_code+19816>, 0x5555558ad56b <exec_byte_code+19816>, 0x5555558ad5d0 <exec_byte_code+19917>, 0x5555558ad644 <exec_byte_code+20033>, 0x5555558a8d31 <exec_byte_code+1326>, 0x5555558a8d33 <exec_byte_code+1328>, 0x5555558a8d35 <exec_byte_code+1330>, 0x5555558a8d37 <exec_byte_code+1332>, 0x5555558a8d39 <exec_byte_code+1334>, 0x5555558a8d39 <exec_byte_code+1334>, 0x5555558a8d3f <exec_byte_code+1340>, 0x5555558a8d00 <exec_byte_code+1277>, 0x5555558a9114 <exec_byte_code+2321>, 0x5555558a9116 <exec_byte_code+2323>, 0x5555558a9118 <exec_byte_code+2325>, 0x5555558a911a <exec_byte_code+2327>, 0x5555558a911c <exec_byte_code+2329>, 0x5555558a911c <exec_byte_code+2329>, 0x5555558a9151 <exec_byte_code+2382>, 0x5555558a9122 <exec_byte_code+2335>, 0x5555558a92fe <exec_byte_code+2811>, 0x5555558a9300 <exec_byte_code+2813>, 0x5555558a9302 <exec_byte_code+2815>, 0x5555558a9304 <exec_byte_code+2817>, 0x5555558a9306 <exec_byte_code+2819>, 0x5555558a9306 <exec_byte_code+2819>, 0x5555558a92b8 <exec_byte_code+2741>, 0x5555558a92cf <exec_byte_code+2764>, 0x5555558a93b4 <exec_byte_code+2993>, 0x5555558a93b6 <exec_byte_code+2995>, 0x5555558a93b8 <exec_byte_code+2997>, 0x5555558a93ba <exec_byte_code+2999>, 0x5555558a93bc <exec_byte_code+3001>, 0x5555558a93bc <exec_byte_code+3001>, 0x5555558a936e <exec_byte_code+2923>, 0x5555558a9385 <exec_byte_code+2946>, 0x5555558a9727 <exec_byte_code+3876>, 0x5555558a9729 <exec_byte_code+3878>, 0x5555558a972b <exec_byte_code+3880>, 0x5555558a972d <exec_byte_code+3882>, 0x5555558a972f <exec_byte_code+3884>, 0x5555558a972f <exec_byte_code+3884>, 0x5555558a96e1 <exec_byte_code+3806>, 0x5555558a96f8 <exec_byte_code+3829>, 0x5555558a9fc8 <exec_byte_code+6085>, 0x5555558a9dd0 <exec_byte_code+5581>, 0x5555558a9dc7 <exec_byte_code+5572>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558aa210 <exec_byte_code+6669>, 0x5555558aa394 <exec_byte_code+7057>, 0x5555558aa403 <exec_byte_code+7168>, 0x5555558aa470 <exec_byte_code+7277>, 0x5555558aa4df <exec_byte_code+7388>, 0x5555558a8f62 <exec_byte_code+1887>, 0x5555558a8ff1 <exec_byte_code+2030>, 0x5555558aa565 <exec_byte_code+7522>, 0x5555558a8eab <exec_byte_code+1704>, 0x5555558a905c <exec_byte_code+2137>, 0x5555558aa5da <exec_byte_code+7639>, 0x5555558aa645 <exec_byte_code+7746>, 0x5555558aa690 <exec_byte_code+7821>, 0x5555558aa6fb <exec_byte_code+7928>, 0x5555558aa764 <exec_byte_code+8033>, 0x5555558aa853 <exec_byte_code+8272>, 0x5555558aa89e <exec_byte_code+8347>, 0x5555558aaa47 <exec_byte_code+8772>, 0x5555558aac17 <exec_byte_code+9236>, 0x5555558aac62 <exec_byte_code+9311>, 0x5555558aacad <exec_byte_code+9386>, 0x5555558aad18 <exec_byte_code+9493>, 0x5555558aad83 <exec_byte_code+9600>, 0x5555558aadee <exec_byte_code+9707>, 0x5555558aae76 <exec_byte_code+9843>, 0x5555558aaec8 <exec_byte_code+9925>, 0x5555558aaf1a <exec_byte_code+10007>, 0x5555558aafea <exec_byte_code+10215>, 0x5555558ab0fa <exec_byte_code+10487>, 0x5555558ab20a <exec_byte_code+10759>, 0x5555558ab30e <exec_byte_code+11019>, 0x5555558ab422 <exec_byte_code+11295>, 0x5555558ab536 <exec_byte_code+11571>, 0x5555558ab64a <exec_byte_code+11847>, 0x5555558ab75e <exec_byte_code+12123>, 0x5555558ab8f0 <exec_byte_code+12525>, 0x5555558aba01 <exec_byte_code+12798>, 0x5555558abb90 <exec_byte_code+13197>, 0x5555558abc59 <exec_byte_code+13398>, 0x5555558abd22 <exec_byte_code+13599>, 0x5555558ac1d9 <exec_byte_code+14806>, 0x5555558a9c41 <exec_byte_code+5182>, 0x5555558ac237 <exec_byte_code+14900>, 0x5555558ac282 <exec_byte_code+14975>, 0x5555558ac34d <exec_byte_code+15178>, 0x5555558ac3ab <exec_byte_code+15272>, 0x5555558ac409 <exec_byte_code+15366>, 0x5555558ac454 <exec_byte_code+15441>, 0x5555558ac49a <exec_byte_code+15511>, 0x5555558ac4e0 <exec_byte_code+15581>, 0x5555558ac52e <exec_byte_code+15659>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ac589 <exec_byte_code+15750>, 0x5555558ac5cf <exec_byte_code+15820>, 0x5555558ac615 <exec_byte_code+15890>, 0x5555558ac65b <exec_byte_code+15960>, 0x5555558ac6a1 <exec_byte_code+16030>, 0x5555558ac6e7 <exec_byte_code+16100>, 0x5555558a9c41 <exec_byte_code+5182>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ac732 <exec_byte_code+16175>, 0x5555558ac785 <exec_byte_code+16258>, 0x5555558ac7d0 <exec_byte_code+16333>, 0x5555558ac81b <exec_byte_code+16408>, 0x5555558ac886 <exec_byte_code+16515>, 0x5555558ac8f1 <exec_byte_code+16622>, 0x5555558ac93c <exec_byte_code+16697>, 0x5555558ac987 <exec_byte_code+16772>, 0x5555558ac9f2 <exec_byte_code+16879>, 0x5555558aca5d <exec_byte_code+16986>, 0x5555558acac8 <exec_byte_code+17093>, 0x5555558acb0e <exec_byte_code+17163>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558a9b8b <exec_byte_code+5000>, 0x5555558a9795 <exec_byte_code+3986>, 0x5555558a8e19 <exec_byte_code+1558>, 0x5555558a9837 <exec_byte_code+4148>, 0x5555558a98bb <exec_byte_code+4280>, 0x5555558a993c <exec_byte_code+4409>, 0x5555558a99bd <exec_byte_code+4538>, 0x5555558a9b54 <exec_byte_code+4945>, 0x5555558a9265 <exec_byte_code+2658>, 0x5555558a9c0a <exec_byte_code+5127>, 0x5555558a9c78 <exec_byte_code+5237>, 0x5555558a9d0c <exec_byte_code+5385>, 0x5555558a9d55 <exec_byte_code+5458>, 0x5555558aa014 <exec_byte_code+6161>, 0x5555558aa091 <exec_byte_code+6286>, 0x5555558aa119 <exec_byte_code+6422>, 0x5555558aa17f <exec_byte_code+6524>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558acb59 <exec_byte_code+17238>, 0x5555558acbe1 <exec_byte_code+17374>, 0x5555558acc2c <exec_byte_code+17449>, 0x5555558acc77 <exec_byte_code+17524>, 0x5555558accc2 <exec_byte_code+17599>, 0x5555558acd0d <exec_byte_code+17674>, 0x5555558acd78 <exec_byte_code+17781>, 0x5555558acde3 <exec_byte_code+17888>, 0x5555558ace4e <exec_byte_code+17995>, 0x5555558aceb9 <exec_byte_code+18102>, 0x5555558ad052 <exec_byte_code+18511>, 0x5555558ad0bd <exec_byte_code+18618>, 0x5555558ad128 <exec_byte_code+18725>, 0x5555558ad173 <exec_byte_code+18800>, 0x5555558ad275 <exec_byte_code+19058>, 0x5555558ad377 <exec_byte_code+19316>, 0x5555558ad3c2 <exec_byte_code+19391>, 0x5555558ad40d <exec_byte_code+19466>, 0x5555558abec8 <exec_byte_code+14021>, 0x5555558ac077 <exec_byte_code+14452>, 0x5555558ad45f <exec_byte_code+19548>, 0x5555558ad4ce <exec_byte_code+19659>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558aa7d5 <exec_byte_code+8146>, 0x5555558aaf6c <exec_byte_code+10089>, 0x5555558ac2cf <exec_byte_code+15052>, 0x5555558ad6d3 <exec_byte_code+20176>, 0x5555558ad748 <exec_byte_code+20293>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad7da <exec_byte_code+20439>, 0x5555558ad861 <exec_byte_code+20574>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ada1a <exec_byte_code+21015> <repeats 64 times>} quitcounter = 86 'V' bc = 0x55555601f930 <main_thread+496> top = 0x7ffff1a00498 pc = 0x5555571118cf "\210l?\205\037" bytestr = XIL(0x555557111504) vector = XIL(0x55555710f79d) maxdepth = make_fixnum(4) const_length = 6 bytestr_length = 32 vectorp = 0x55555710f7a0 max_stack = 4 frame_base = 0x7ffff1a00490 fp = 0x7ffff1a004b0 bytestr_data = 0x5555571118b8 "\b\204\b" rest = false mandatory = 1 nonrest = 1 pushedargs = 1 saved_quitcounter = 20 '\024' saved_vectorp = 0x5555579c1258 saved_bytestr_data = 0x555557338888 "\211@\301\002A!\3022\205" result = XIL(0x48) #12 0x000055555584b978 in funcall_lambda (fun=XIL(0x55555634bc45), nargs=0, arg_vector=0x7fffffffc2e8) at eval.c:3238 syms_left = make_fixnum(0) lexenv = XIL(0x7fffffffc2b0) count = { bytes = 72198331526267408 } i = 140737488339472 optional = false rest = false previous_rest = 85 val = XIL(0) #13 0x000055555584ad18 in funcall_general (fun=XIL(0x55555634bc45), numargs=0, args=0x7fffffffc2e8) at eval.c:3030 original_fun = XIL(0x55555634bc45) #14 0x000055555584afd9 in Ffuncall (nargs=1, args=0x7fffffffc2e0) at eval.c:3079 count = { bytes = 896 } val = XIL(0x5555571a4da0) #15 0x0000555555846298 in Ffuncall_with_delayed_message (timeout=make_fixnum(2), message=XIL(0x5555571b8b34), function=XIL(0x55555634bc45)) at eval.c:1172 count = { bytes = 864 } interval = { tv_sec = 2, tv_nsec = 0 } timer = 0x55555629c1b0 result = XIL(0x4) #16 0x000055555584b363 in funcall_subr (subr=0x555556030920 <Sfuncall_with_delayed_message>, numargs=3, args=0x7ffff1a002b0) at eval.c:3151 argbuf = {XIL(0x1f2bfd730), XIL(0x30), XIL(0x555557060ce0), XIL(0x340), XIL(0x7fffffffc380), XIL(0x12558a8305), XIL(0x555556030925), XIL(0x7fffffffc3a0)} a = 0x7ffff1a002b0 maxargs = 3 fun = make_fixnum(23456248930209) #17 0x00005555558a95f3 in exec_byte_code (fun=XIL(0x7ffff24268bd), args_template=513, nargs=1, args=0x7ffff1a00368) at bytecode.c:813 call_nargs = 3 call_fun = XIL(0x555556030925) count1 = { bytes = 832 } val = XIL(0x55555634bc45) call_args = 0x7ffff1a002b0 original_fun = XIL(0x2aaa9c8c8d60) op = 3 type = CATCHER targets = {0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad565 <exec_byte_code+19810>, 0x5555558ad567 <exec_byte_code+19812>, 0x5555558ad569 <exec_byte_code+19814>, 0x5555558ad56b <exec_byte_code+19816>, 0x5555558ad56b <exec_byte_code+19816>, 0x5555558ad5d0 <exec_byte_code+19917>, 0x5555558ad644 <exec_byte_code+20033>, 0x5555558a8d31 <exec_byte_code+1326>, 0x5555558a8d33 <exec_byte_code+1328>, 0x5555558a8d35 <exec_byte_code+1330>, 0x5555558a8d37 <exec_byte_code+1332>, 0x5555558a8d39 <exec_byte_code+1334>, 0x5555558a8d39 <exec_byte_code+1334>, 0x5555558a8d3f <exec_byte_code+1340>, 0x5555558a8d00 <exec_byte_code+1277>, 0x5555558a9114 <exec_byte_code+2321>, 0x5555558a9116 <exec_byte_code+2323>, 0x5555558a9118 <exec_byte_code+2325>, 0x5555558a911a <exec_byte_code+2327>, 0x5555558a911c <exec_byte_code+2329>, 0x5555558a911c <exec_byte_code+2329>, 0x5555558a9151 <exec_byte_code+2382>, 0x5555558a9122 <exec_byte_code+2335>, 0x5555558a92fe <exec_byte_code+2811>, 0x5555558a9300 <exec_byte_code+2813>, 0x5555558a9302 <exec_byte_code+2815>, 0x5555558a9304 <exec_byte_code+2817>, 0x5555558a9306 <exec_byte_code+2819>, 0x5555558a9306 <exec_byte_code+2819>, 0x5555558a92b8 <exec_byte_code+2741>, 0x5555558a92cf <exec_byte_code+2764>, 0x5555558a93b4 <exec_byte_code+2993>, 0x5555558a93b6 <exec_byte_code+2995>, 0x5555558a93b8 <exec_byte_code+2997>, 0x5555558a93ba <exec_byte_code+2999>, 0x5555558a93bc <exec_byte_code+3001>, 0x5555558a93bc <exec_byte_code+3001>, 0x5555558a936e <exec_byte_code+2923>, 0x5555558a9385 <exec_byte_code+2946>, 0x5555558a9727 <exec_byte_code+3876>, 0x5555558a9729 <exec_byte_code+3878>, 0x5555558a972b <exec_byte_code+3880>, 0x5555558a972d <exec_byte_code+3882>, 0x5555558a972f <exec_byte_code+3884>, 0x5555558a972f <exec_byte_code+3884>, 0x5555558a96e1 <exec_byte_code+3806>, 0x5555558a96f8 <exec_byte_code+3829>, 0x5555558a9fc8 <exec_byte_code+6085>, 0x5555558a9dd0 <exec_byte_code+5581>, 0x5555558a9dc7 <exec_byte_code+5572>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558aa210 <exec_byte_code+6669>, 0x5555558aa394 <exec_byte_code+7057>, 0x5555558aa403 <exec_byte_code+7168>, 0x5555558aa470 <exec_byte_code+7277>, 0x5555558aa4df <exec_byte_code+7388>, 0x5555558a8f62 <exec_byte_code+1887>, 0x5555558a8ff1 <exec_byte_code+2030>, 0x5555558aa565 <exec_byte_code+7522>, 0x5555558a8eab <exec_byte_code+1704>, 0x5555558a905c <exec_byte_code+2137>, 0x5555558aa5da <exec_byte_code+7639>, 0x5555558aa645 <exec_byte_code+7746>, 0x5555558aa690 <exec_byte_code+7821>, 0x5555558aa6fb <exec_byte_code+7928>, 0x5555558aa764 <exec_byte_code+8033>, 0x5555558aa853 <exec_byte_code+8272>, 0x5555558aa89e <exec_byte_code+8347>, 0x5555558aaa47 <exec_byte_code+8772>, 0x5555558aac17 <exec_byte_code+9236>, 0x5555558aac62 <exec_byte_code+9311>, 0x5555558aacad <exec_byte_code+9386>, 0x5555558aad18 <exec_byte_code+9493>, 0x5555558aad83 <exec_byte_code+9600>, 0x5555558aadee <exec_byte_code+9707>, 0x5555558aae76 <exec_byte_code+9843>, 0x5555558aaec8 <exec_byte_code+9925>, 0x5555558aaf1a <exec_byte_code+10007>, 0x5555558aafea <exec_byte_code+10215>, 0x5555558ab0fa <exec_byte_code+10487>, 0x5555558ab20a <exec_byte_code+10759>, 0x5555558ab30e <exec_byte_code+11019>, 0x5555558ab422 <exec_byte_code+11295>, 0x5555558ab536 <exec_byte_code+11571>, 0x5555558ab64a <exec_byte_code+11847>, 0x5555558ab75e <exec_byte_code+12123>, 0x5555558ab8f0 <exec_byte_code+12525>, 0x5555558aba01 <exec_byte_code+12798>, 0x5555558abb90 <exec_byte_code+13197>, 0x5555558abc59 <exec_byte_code+13398>, 0x5555558abd22 <exec_byte_code+13599>, 0x5555558ac1d9 <exec_byte_code+14806>, 0x5555558a9c41 <exec_byte_code+5182>, 0x5555558ac237 <exec_byte_code+14900>, 0x5555558ac282 <exec_byte_code+14975>, 0x5555558ac34d <exec_byte_code+15178>, 0x5555558ac3ab <exec_byte_code+15272>, 0x5555558ac409 <exec_byte_code+15366>, 0x5555558ac454 <exec_byte_code+15441>, 0x5555558ac49a <exec_byte_code+15511>, 0x5555558ac4e0 <exec_byte_code+15581>, 0x5555558ac52e <exec_byte_code+15659>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ac589 <exec_byte_code+15750>, 0x5555558ac5cf <exec_byte_code+15820>, 0x5555558ac615 <exec_byte_code+15890>, 0x5555558ac65b <exec_byte_code+15960>, 0x5555558ac6a1 <exec_byte_code+16030>, 0x5555558ac6e7 <exec_byte_code+16100>, 0x5555558a9c41 <exec_byte_code+5182>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ac732 <exec_byte_code+16175>, 0x5555558ac785 <exec_byte_code+16258>, 0x5555558ac7d0 <exec_byte_code+16333>, 0x5555558ac81b <exec_byte_code+16408>, 0x5555558ac886 <exec_byte_code+16515>, 0x5555558ac8f1 <exec_byte_code+16622>, 0x5555558ac93c <exec_byte_code+16697>, 0x5555558ac987 <exec_byte_code+16772>, 0x5555558ac9f2 <exec_byte_code+16879>, 0x5555558aca5d <exec_byte_code+16986>, 0x5555558acac8 <exec_byte_code+17093>, 0x5555558acb0e <exec_byte_code+17163>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558a9b8b <exec_byte_code+5000>, 0x5555558a9795 <exec_byte_code+3986>, 0x5555558a8e19 <exec_byte_code+1558>, 0x5555558a9837 <exec_byte_code+4148>, 0x5555558a98bb <exec_byte_code+4280>, 0x5555558a993c <exec_byte_code+4409>, 0x5555558a99bd <exec_byte_code+4538>, 0x5555558a9b54 <exec_byte_code+4945>, 0x5555558a9265 <exec_byte_code+2658>, 0x5555558a9c0a <exec_byte_code+5127>, 0x5555558a9c78 <exec_byte_code+5237>, 0x5555558a9d0c <exec_byte_code+5385>, 0x5555558a9d55 <exec_byte_code+5458>, 0x5555558aa014 <exec_byte_code+6161>, 0x5555558aa091 <exec_byte_code+6286>, 0x5555558aa119 <exec_byte_code+6422>, 0x5555558aa17f <exec_byte_code+6524>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558acb59 <exec_byte_code+17238>, 0x5555558acbe1 <exec_byte_code+17374>, 0x5555558acc2c <exec_byte_code+17449>, 0x5555558acc77 <exec_byte_code+17524>, 0x5555558accc2 <exec_byte_code+17599>, 0x5555558acd0d <exec_byte_code+17674>, 0x5555558acd78 <exec_byte_code+17781>, 0x5555558acde3 <exec_byte_code+17888>, 0x5555558ace4e <exec_byte_code+17995>, 0x5555558aceb9 <exec_byte_code+18102>, 0x5555558ad052 <exec_byte_code+18511>, 0x5555558ad0bd <exec_byte_code+18618>, 0x5555558ad128 <exec_byte_code+18725>, 0x5555558ad173 <exec_byte_code+18800>, 0x5555558ad275 <exec_byte_code+19058>, 0x5555558ad377 <exec_byte_code+19316>, 0x5555558ad3c2 <exec_byte_code+19391>, 0x5555558ad40d <exec_byte_code+19466>, 0x5555558abec8 <exec_byte_code+14021>, 0x5555558ac077 <exec_byte_code+14452>, 0x5555558ad45f <exec_byte_code+19548>, 0x5555558ad4ce <exec_byte_code+19659>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558aa7d5 <exec_byte_code+8146>, 0x5555558aaf6c <exec_byte_code+10089>, 0x5555558ac2cf <exec_byte_code+15052>, 0x5555558ad6d3 <exec_byte_code+20176>, 0x5555558ad748 <exec_byte_code+20293>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad7da <exec_byte_code+20439>, 0x5555558ad861 <exec_byte_code+20574>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ada1a <exec_byte_code+21015> <repeats 64 times>} quitcounter = 15 '\017' bc = 0x55555601f930 <main_thread+496> top = 0x7ffff1a002a8 pc = 0x5555571b8e5b "\210\002\203~" bytestr = XIL(0x7ffff2426904) vector = XIL(0x7ffff24268fd) maxdepth = make_fixnum(5) const_length = 0 bytestr_length = 22 vectorp = 0x5555571b79d8 max_stack = 5 frame_base = 0x7ffff1a003e8 fp = 0x7ffff1a00410 bytestr_data = 0x5555571b8de8 "\306\307!\204\n" rest = false mandatory = 1 nonrest = 2 pushedargs = 1 saved_quitcounter = 15 '\017' saved_vectorp = 0x5555571ba540 saved_bytestr_data = 0x5555571bdd78 "\30120" result = XIL(0) #18 0x000055555584b978 in funcall_lambda (fun=XIL(0x5555571b7735), nargs=4, arg_vector=0x7fffffffc9d8) at eval.c:3238 syms_left = make_fixnum(1282) lexenv = XIL(0x7ffff25e5190) count = { bytes = 1542 } i = 140737488341280 optional = false rest = false previous_rest = 85 val = XIL(0) #19 0x000055555584ad18 in funcall_general (fun=XIL(0x5555571b7735), numargs=4, args=0x7fffffffc9d8) at eval.c:3030 original_fun = XIL(0xff0660) #20 0x000055555584afd9 in Ffuncall (nargs=5, args=0x7fffffffc9d0) at eval.c:3079 count = { bytes = 480 } val = XIL(0) #21 0x000055555584a474 in Fapply (nargs=2, args=0x7ffff1a00110) at eval.c:2751 i = 5 funcall_nargs = 5 funcall_args = 0x7fffffffc9d0 spread_arg = XIL(0) fun = XIL(0x5555571b7735) sa_avail = 16344 sa_count = { bytes = 480 } numargs = 4 retval = XIL(0xd00000000) #22 0x000055555584b563 in funcall_subr (subr=0x555556030c20 <Sapply>, numargs=2, args=0x7ffff1a00110) at eval.c:3170 maxargs = -2 fun = make_fixnum(23456248930209) #23 0x00005555558a95f3 in exec_byte_code (fun=XIL(0x5555571ad805), args_template=771, nargs=3, args=0x7ffff1a00128) at bytecode.c:813 call_nargs = 2 call_fun = XIL(0x555556030c25) count1 = { bytes = 448 } val = XIL(0) call_args = 0x7ffff1a00110 original_fun = XIL(0x3e10) op = 2 type = 1454763048 targets = {0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad565 <exec_byte_code+19810>, 0x5555558ad567 <exec_byte_code+19812>, 0x5555558ad569 <exec_byte_code+19814>, 0x5555558ad56b <exec_byte_code+19816>, 0x5555558ad56b <exec_byte_code+19816>, 0x5555558ad5d0 <exec_byte_code+19917>, 0x5555558ad644 <exec_byte_code+20033>, 0x5555558a8d31 <exec_byte_code+1326>, 0x5555558a8d33 <exec_byte_code+1328>, 0x5555558a8d35 <exec_byte_code+1330>, 0x5555558a8d37 <exec_byte_code+1332>, 0x5555558a8d39 <exec_byte_code+1334>, 0x5555558a8d39 <exec_byte_code+1334>, 0x5555558a8d3f <exec_byte_code+1340>, 0x5555558a8d00 <exec_byte_code+1277>, 0x5555558a9114 <exec_byte_code+2321>, 0x5555558a9116 <exec_byte_code+2323>, 0x5555558a9118 <exec_byte_code+2325>, 0x5555558a911a <exec_byte_code+2327>, 0x5555558a911c <exec_byte_code+2329>, 0x5555558a911c <exec_byte_code+2329>, 0x5555558a9151 <exec_byte_code+2382>, 0x5555558a9122 <exec_byte_code+2335>, 0x5555558a92fe <exec_byte_code+2811>, 0x5555558a9300 <exec_byte_code+2813>, 0x5555558a9302 <exec_byte_code+2815>, 0x5555558a9304 <exec_byte_code+2817>, 0x5555558a9306 <exec_byte_code+2819>, 0x5555558a9306 <exec_byte_code+2819>, 0x5555558a92b8 <exec_byte_code+2741>, 0x5555558a92cf <exec_byte_code+2764>, 0x5555558a93b4 <exec_byte_code+2993>, 0x5555558a93b6 <exec_byte_code+2995>, 0x5555558a93b8 <exec_byte_code+2997>, 0x5555558a93ba <exec_byte_code+2999>, 0x5555558a93bc <exec_byte_code+3001>, 0x5555558a93bc <exec_byte_code+3001>, 0x5555558a936e <exec_byte_code+2923>, 0x5555558a9385 <exec_byte_code+2946>, 0x5555558a9727 <exec_byte_code+3876>, 0x5555558a9729 <exec_byte_code+3878>, 0x5555558a972b <exec_byte_code+3880>, 0x5555558a972d <exec_byte_code+3882>, 0x5555558a972f <exec_byte_code+3884>, 0x5555558a972f <exec_byte_code+3884>, 0x5555558a96e1 <exec_byte_code+3806>, 0x5555558a96f8 <exec_byte_code+3829>, 0x5555558a9fc8 <exec_byte_code+6085>, 0x5555558a9dd0 <exec_byte_code+5581>, 0x5555558a9dc7 <exec_byte_code+5572>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558aa210 <exec_byte_code+6669>, 0x5555558aa394 <exec_byte_code+7057>, 0x5555558aa403 <exec_byte_code+7168>, 0x5555558aa470 <exec_byte_code+7277>, 0x5555558aa4df <exec_byte_code+7388>, 0x5555558a8f62 <exec_byte_code+1887>, 0x5555558a8ff1 <exec_byte_code+2030>, 0x5555558aa565 <exec_byte_code+7522>, 0x5555558a8eab <exec_byte_code+1704>, 0x5555558a905c <exec_byte_code+2137>, 0x5555558aa5da <exec_byte_code+7639>, 0x5555558aa645 <exec_byte_code+7746>, 0x5555558aa690 <exec_byte_code+7821>, 0x5555558aa6fb <exec_byte_code+7928>, 0x5555558aa764 <exec_byte_code+8033>, 0x5555558aa853 <exec_byte_code+8272>, 0x5555558aa89e <exec_byte_code+8347>, 0x5555558aaa47 <exec_byte_code+8772>, 0x5555558aac17 <exec_byte_code+9236>, 0x5555558aac62 <exec_byte_code+9311>, 0x5555558aacad <exec_byte_code+9386>, 0x5555558aad18 <exec_byte_code+9493>, 0x5555558aad83 <exec_byte_code+9600>, 0x5555558aadee <exec_byte_code+9707>, 0x5555558aae76 <exec_byte_code+9843>, 0x5555558aaec8 <exec_byte_code+9925>, 0x5555558aaf1a <exec_byte_code+10007>, 0x5555558aafea <exec_byte_code+10215>, 0x5555558ab0fa <exec_byte_code+10487>, 0x5555558ab20a <exec_byte_code+10759>, 0x5555558ab30e <exec_byte_code+11019>, 0x5555558ab422 <exec_byte_code+11295>, 0x5555558ab536 <exec_byte_code+11571>, 0x5555558ab64a <exec_byte_code+11847>, 0x5555558ab75e <exec_byte_code+12123>, 0x5555558ab8f0 <exec_byte_code+12525>, 0x5555558aba01 <exec_byte_code+12798>, 0x5555558abb90 <exec_byte_code+13197>, 0x5555558abc59 <exec_byte_code+13398>, 0x5555558abd22 <exec_byte_code+13599>, 0x5555558ac1d9 <exec_byte_code+14806>, 0x5555558a9c41 <exec_byte_code+5182>, 0x5555558ac237 <exec_byte_code+14900>, 0x5555558ac282 <exec_byte_code+14975>, 0x5555558ac34d <exec_byte_code+15178>, 0x5555558ac3ab <exec_byte_code+15272>, 0x5555558ac409 <exec_byte_code+15366>, 0x5555558ac454 <exec_byte_code+15441>, 0x5555558ac49a <exec_byte_code+15511>, 0x5555558ac4e0 <exec_byte_code+15581>, 0x5555558ac52e <exec_byte_code+15659>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ac589 <exec_byte_code+15750>, 0x5555558ac5cf <exec_byte_code+15820>, 0x5555558ac615 <exec_byte_code+15890>, 0x5555558ac65b <exec_byte_code+15960>, 0x5555558ac6a1 <exec_byte_code+16030>, 0x5555558ac6e7 <exec_byte_code+16100>, 0x5555558a9c41 <exec_byte_code+5182>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ac732 <exec_byte_code+16175>, 0x5555558ac785 <exec_byte_code+16258>, 0x5555558ac7d0 <exec_byte_code+16333>, 0x5555558ac81b <exec_byte_code+16408>, 0x5555558ac886 <exec_byte_code+16515>, 0x5555558ac8f1 <exec_byte_code+16622>, 0x5555558ac93c <exec_byte_code+16697>, 0x5555558ac987 <exec_byte_code+16772>, 0x5555558ac9f2 <exec_byte_code+16879>, 0x5555558aca5d <exec_byte_code+16986>, 0x5555558acac8 <exec_byte_code+17093>, 0x5555558acb0e <exec_byte_code+17163>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558a9b8b <exec_byte_code+5000>, 0x5555558a9795 <exec_byte_code+3986>, 0x5555558a8e19 <exec_byte_code+1558>, 0x5555558a9837 <exec_byte_code+4148>, 0x5555558a98bb <exec_byte_code+4280>, 0x5555558a993c <exec_byte_code+4409>, 0x5555558a99bd <exec_byte_code+4538>, 0x5555558a9b54 <exec_byte_code+4945>, 0x5555558a9265 <exec_byte_code+2658>, 0x5555558a9c0a <exec_byte_code+5127>, 0x5555558a9c78 <exec_byte_code+5237>, 0x5555558a9d0c <exec_byte_code+5385>, 0x5555558a9d55 <exec_byte_code+5458>, 0x5555558aa014 <exec_byte_code+6161>, 0x5555558aa091 <exec_byte_code+6286>, 0x5555558aa119 <exec_byte_code+6422>, 0x5555558aa17f <exec_byte_code+6524>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558acb59 <exec_byte_code+17238>, 0x5555558acbe1 <exec_byte_code+17374>, 0x5555558acc2c <exec_byte_code+17449>, 0x5555558acc77 <exec_byte_code+17524>, 0x5555558accc2 <exec_byte_code+17599>, 0x5555558acd0d <exec_byte_code+17674>, 0x5555558acd78 <exec_byte_code+17781>, 0x5555558acde3 <exec_byte_code+17888>, 0x5555558ace4e <exec_byte_code+17995>, 0x5555558aceb9 <exec_byte_code+18102>, 0x5555558ad052 <exec_byte_code+18511>, 0x5555558ad0bd <exec_byte_code+18618>, 0x5555558ad128 <exec_byte_code+18725>, 0x5555558ad173 <exec_byte_code+18800>, 0x5555558ad275 <exec_byte_code+19058>, 0x5555558ad377 <exec_byte_code+19316>, 0x5555558ad3c2 <exec_byte_code+19391>, 0x5555558ad40d <exec_byte_code+19466>, 0x5555558abec8 <exec_byte_code+14021>, 0x5555558ac077 <exec_byte_code+14452>, 0x5555558ad45f <exec_byte_code+19548>, 0x5555558ad4ce <exec_byte_code+19659>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558aa7d5 <exec_byte_code+8146>, 0x5555558aaf6c <exec_byte_code+10089>, 0x5555558ac2cf <exec_byte_code+15052>, 0x5555558ad6d3 <exec_byte_code+20176>, 0x5555558ad748 <exec_byte_code+20293>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad7da <exec_byte_code+20439>, 0x5555558ad861 <exec_byte_code+20574>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ad53d <exec_byte_code+19770>, 0x5555558ada1a <exec_byte_code+21015> <repeats 64 times>} quitcounter = 3 '\003' bc = 0x55555601f930 <main_thread+496> top = 0x7ffff1a00108 pc = 0x555557261f64 "\207" bytestr = XIL(0x5555571bc9e4) vector = XIL(0x5555571ad77d) maxdepth = make_fixnum(10) const_length = 16 bytestr_length = 63 vectorp = 0x5555570f6060 max_stack = 10 frame_base = 0x7ffff1a00168 fp = 0x7ffff1a001b8 bytestr_data = 0x555557261ef8 "\305\b\306\001!\t>\204\021" rest = false mandatory = 3 nonrest = 3 pushedargs = 3 saved_quitcounter = 0 '\000' saved_vectorp = 0x7fffffffcf60 saved_bytestr_data = 0x7ffff2bfd700 "\001" result = XIL(0x55555581e941) #24 0x000055555584b978 in funcall_lambda (fun=XIL(0x55555710c3bd), nargs=2, arg_vector=0x7fffffffd138) at eval.c:3238 syms_left = make_fixnum(514) lexenv = XIL(0x555556b5ec2d) count = { bytes = 93825004188672 } i = 140737488343168 optional = false rest = false previous_rest = 85 val = XIL(0) #25 0x000055555584ad18 in funcall_general (fun=XIL(0x55555710c3bd), numargs=2, args=0x7fffffffd138) at eval.c:3030 original_fun = XIL(0x11b1fc0) #26 0x000055555584afd9 in Ffuncall (nargs=3, args=0x7fffffffd130) at eval.c:3079 count = { bytes = 320 } val = XIL(0) #27 0x000055555584a474 in Fapply (nargs=2, args=0x7fffffffd1f0) at eval.c:2751 i = 3 funcall_nargs = 3 funcall_args = 0x7fffffffd130 spread_arg = XIL(0) fun = XIL(0x55555710c3bd) sa_avail = 16360 sa_count = { bytes = 320 } numargs = 2 retval = XIL(0x55555612dea0) #28 0x000055555584aa24 in apply1 (fn=XIL(0x11b1fc0), arg=XIL(0x5555566c05a3)) at eval.c:2967 #29 0x00005555558be3ad in read_process_output_call (fun_and_args=XIL(0x5555566c03e3)) at process.c:6133 #30 0x00005555558471d8 in internal_condition_case_1 (bfun=0x5555558be373 <read_process_output_call>, arg=XIL(0x5555566c03e3), handlers=XIL(0x90), hfun=0x5555558be3b3 <read_process_output_error_handler>) at eval.c:1631 val = XIL(0x555558b069c4) c = 0x55555616eb60 #31 0x00005555558bf63b in read_and_dispose_of_process_output (p=0x5555571c8708, chars=0x555558b19b00 "\\\303\"\"\366\241F\245+M\256\266\351y9\2677=\227;\364\327W|W\221\237וM\037xKy\331\377)\177\234\303-}\315\322\022x%\301\370\351S\020e\230\371\253\312\371MKHJ\362\301#\261\314\346\035\315R\222h\342\354uKf\225O&\327-Y\201:[\353{}\217!stj\0226\377bNB\242", nbytes=1169, coding=0x55555612dea0) at process.c:6502 outstream = XIL(0x11b1fc0) text = XIL(0x555558b069c4) outer_running_asynch_code = false waiting = -1 #32 0x00005555558be94c in read_process_output (proc=XIL(0x5555571c870d), channel=11) at process.c:6270 nbytes = 1169 p = 0x5555571c8708 coding = 0x55555612dea0 carryover = 0 readmax = 65536 count = { bytes = 192 } odeactivate = XIL(0) chars = 0x555558b19b00 "\\\303\"\"\366\241F\245+M\256\266\351y9\2677=\227;\364\327W|W\221\237וM\037xKy\331\377)\177\234\303-}\315\322\022x%\301\370\351S\020e\230\371\253\312\371MKHJ\362\301#\261\314\346\035\315R\222h\342\354uKf\225O&\327-Y\201:[\353{}\217!stj\0226\377bNB\242" sa_avail = 16384 sa_count = { bytes = 192 } #33 0x00005555558bdb47 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5951 nread = 8192 process_skipped = false wrapped = true channel_start = 12 child_fd = 14 last_read_channel = 11 channel = 11 nfds = 1 Available = { fds_bits = {2048, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = XIL(0x5555571c870d) timeout = { tv_sec = 0, tv_nsec = 9051247 } end_time = { tv_sec = 1730986587, tv_nsec = 189821471 } timer_delay = { tv_sec = 0, tv_nsec = 9051247 } got_output_end_time = { tv_sec = 1730986557, tv_nsec = 690698014 } wait = TIMEOUT got_some_output = 16384 prev_wait_proc_nbytes_read = 0 retry_for_async = false count = { bytes = 160 } now = { tv_sec = 0, tv_nsec = -1 } #34 0x00005555555ae650 in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6335 sec = 30 nsec = 0 do_display = true curbuf_eq_winbuf = true nbytes = 21845 #35 0x000055555576cac4 in read_char (commandflag=1, map=XIL(0x55555a924213), prev_event=XIL(0), used_mouse_menu=0x7fffffffdc7f, end_time=0x0) at keyboard.c:2926 tem0 = XIL(0xad40) timeout = 30 count1 = { bytes = 128 } delay_level = 4 buffer_size = 1 c = XIL(0) local_getcjmp = {{ __jmpbuf = {0, -3140284887290424714, 0, 140737488348288, 140737354125312, 93824997286264, -3140284887409962378, -9133824947898494346}, __mask_was_saved = 0, __saved_mask = { __val = {93824995061567, 93825004144416, 0, 0, 0, 93824994543679, 0, 140737488345984, 93824994567958, 0, 48, 93824995158337, 93825080115731, 140737488345888, 93824995043671, 140737266045088} } }} save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 <repeats 16 times>} } }} tem = XIL(0x7fffffffd990) save = XIL(0x55555674fb45) previous_echo_area_message = XIL(0) also_record = XIL(0) reread = false recorded = false polling_stopped_here = false orig_kboard = 0x555556186490 jmpcount = { bytes = 128 } c_volatile = XIL(0) #36 0x0000555555780075 in read_key_sequence (keybuf=0x7fffffffde30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at keyboard.c:10747 interrupted_kboard = 0x555556186490 interrupted_frame = 0x55555622da20 key = XIL(0x7fffffffdcc0) used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = XIL(0x7fffffffe480) count = { bytes = 96 } t = 0 echo_start = 0 keys_start = 0 current_binding = XIL(0x55555a924213) first_unbound = 31 mock_input = 0 used_mouse_menu_history = {false <repeats 30 times>} fkey = { parent = XIL(0x7ffff4f47723), map = XIL(0x7ffff4f47723), start = 0, end = 0 } keytran = { parent = XIL(0x7ffff2bd1d7b), map = XIL(0x7ffff2bd1d7b), start = 0, end = 0 } indec = { parent = XIL(0x7ffff4f47713), map = XIL(0x7ffff4f47713), start = 0, end = 0 } shift_translated = false delayed_switch_frame = XIL(0) original_uppercase = XIL(0) original_uppercase_position = -1 disabled_conversion = false starting_buffer = 0x55555674fb40 fake_prefixed_keys = XIL(0) first_event = XIL(0) second_event = XIL(0) #37 0x0000555555768380 in command_loop_1 () at keyboard.c:1424 cmd = XIL(0x78550) keybuf = {XIL(0x555557ebb963), make_fixnum(134217847), XIL(0x7fffffffdec0), XIL(0x555555824d93), XIL(0x200000080), XIL(0), XIL(0), XIL(0xb310), XIL(0x7fffffffdee0), XIL(0x7ffff2bfd750), XIL(0x5555560b0720), XIL(0xb310), XIL(0x5555560b0720), XIL(0x7ffff270f0c0), XIL(0), XIL(0x5555560bba30), XIL(0x55555581e941), XIL(0), XIL(0x7fffffffdf50), XIL(0x555555825908), XIL(0x7ffff270f0c5), XIL(0x2ffffde70), XIL(0), XIL(0xb310), XIL(0x7ffff2bfd750), XIL(0x7ffff2bdc1ab), XIL(0x7ffff296e393), XIL(0x7ffff2bfd750), XIL(0x7fffffffdf90), XIL(0xb310)} i = 1 last_pt = 4105 prev_modiff = 8517 prev_buffer = 0x55555674fb40 #38 0x00005555558470f7 in internal_condition_case (bfun=0x555555767f51 <command_loop_1>, handlers=XIL(0x90), hfun=0x5555557673d2 <cmd_error>) at eval.c:1607 val = XIL(0x12330) c = 0x55555616ea20 #39 0x0000555555767b18 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1163 val = XIL(0x12330) #40 0x000055555584654d in internal_catch (tag=XIL(0x12330), func=0x555555767aee <command_loop_2>, arg=XIL(0x90)) at eval.c:1286 val = XIL(0x5555557641bb) c = 0x55555616e8e0 #41 0x0000555555767aaa in command_loop () at keyboard.c:1141 #42 0x0000555555766e74 in recursive_edit_1 () at keyboard.c:749 count = { bytes = 32 } val = XIL(0x7fffffffe1b0) #43 0x00005555557670a0 in Frecursive_edit () at keyboard.c:832 count = { bytes = 0 } buffer = XIL(0) #44 0x0000555555762937 in main (argc=2, argv=0x7fffffffe468) at emacs.c:2625 stack_bottom_variable = 0x0 old_argc = 2 dump_file = 0x0 no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 dump_mode = 0x0 skip_args = 0 temacs = 0x0 attempt_load_pdump = true only_version = false rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } lc_all = 0x0 sockfd = -1 module_assertions = false Lisp Backtrace: "vertical-motion" (0xf1a004a0) "shr-vertical-motion" (0xf1a00430) "shr-fill-line" (0xf1a003e0) "shr-fill-lines" (0xf1a00398) "shr-insert-document" (0xf1a00308) 0x5634bc40 PVEC_CLOSURE "funcall-with-delayed-message" (0xf1a002b0) "eww-display-document" (0xf1a00240) "eww-display-html" (0xf1a001b8) "eww-render" (0xffffc9d8) "apply" (0xf1a00110) "url-http-activate-callback" (0xf1a000b0) "url-http-content-length-after-change-function" (0xf1a00050) "url-http-generic-filter" (0xffffd138) (gdb) ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 13:45 ` Visuwesh @ 2024-11-07 14:40 ` Eli Zaretskii 2024-11-07 15:13 ` Visuwesh 2024-11-08 8:08 ` Eli Zaretskii 0 siblings, 2 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-11-07 14:40 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, mituharu, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: Tim Ruffing <dev@real-or-random.org>, mituharu@math.s.chiba-u.ac.jp, > xuan@xlk.me, 73752@debbugs.gnu.org > Date: Thu, 07 Nov 2024 19:15:30 +0530 > > [வியாழன் நவம்பர் 07, 2024] Eli Zaretskii wrote: > > >> From: Tim Ruffing <dev@real-or-random.org> > >> Cc: mituharu@math.s.chiba-u.ac.jp, visuweshm@gmail.com, xuan@xlk.me, > >> 73752@debbugs.gnu.org > >> Date: Thu, 07 Nov 2024 03:12:19 +0100 > >> > >> On Wed, 2024-11-06 at 15:11 +0200, Eli Zaretskii wrote: > >> > > >> > > >> > Thanks. Can you try calling hb_font_destroy in > >> > ftcrhbfont_end_hb_font > >> > and setting ftcrfont_info->hb_font to NULL right after that? If that > >> > solves the problem, we could at least install this for now, until we > >> > have a better solution (if one exists). > >> > >> Yes, that appears to work. And I don't think there's an obvious better > >> solution. See attached patch. > > > > Thanks. Visuwesh, does this patch fix your problem as well? > > I cannot reproduce the original issue but it leads to following > backtrace when I visit dinamalar.com in eww, and click on any of the > links coloured in blue: say the one under the heading named "வாராவாரம்". > Directly visiting a link doesn't produce the backtrace though. I need > to visit a webpage with Tamil text on it twice to trigger it. It might > well be a false warning since I see the warning > > Warning: program compiled against libxml 212 using older 209 > Warning: program compiled against libxml 212 using older 209 > > in stderr printed. I updated my system (kernel updates included) but > haven't restarted it yet. Of course, I built Emacs _after_ the update. > If you want me to restart and check if you believe it is a false > warning, I am to do so. Maybe a `make bootstrap' or somesuch is also in > order? This abort is unrelated: I also get it, with no changes at all, and also in Emacs 30. It looks like we fail to decode the text there, and a buffer ends up with an invalid byte sequence, which triggers an assertion violation. Please open a separate bug report about that. As for this bug, I will install the patch soon, thanks to all for the efforts to investigate this tricky bug. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 14:40 ` Eli Zaretskii @ 2024-11-07 15:13 ` Visuwesh 2024-11-07 15:49 ` Eli Zaretskii 2024-11-08 8:08 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-11-07 15:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, mituharu, 73752 On 7 November 2024 20:10:49 GMT+05:30, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Visuwesh <visuweshm@gmail.com> >> Cc: Tim Ruffing <dev@real-or-random.org>, mituharu@math.s.chiba-u.ac.jp, >> xuan@xlk.me, 73752@debbugs.gnu.org >> Date: Thu, 07 Nov 2024 19:15:30 +0530 >> >> [வியாழன் நவம்பர் 07, 2024] Eli Zaretskii wrote: >> >> >> From: Tim Ruffing <dev@real-or-random.org> >> >> Cc: mituharu@math.s.chiba-u.ac.jp, visuweshm@gmail.com, xuan@xlk.me, >> >> 73752@debbugs.gnu.org >> >> Date: Thu, 07 Nov 2024 03:12:19 +0100 >> >> >> >> On Wed, 2024-11-06 at 15:11 +0200, Eli Zaretskii wrote: >> >> > >> >> > >> >> > Thanks. Can you try calling hb_font_destroy in >> >> > ftcrhbfont_end_hb_font >> >> > and setting ftcrfont_info->hb_font to NULL right after that? If that >> >> > solves the problem, we could at least install this for now, until we >> >> > have a better solution (if one exists). >> >> >> >> Yes, that appears to work. And I don't think there's an obvious better >> >> solution. See attached patch. >> > >> > Thanks. Visuwesh, does this patch fix your problem as well? >> >> I cannot reproduce the original issue but it leads to following >> backtrace when I visit dinamalar.com in eww, and click on any of the >> links coloured in blue: say the one under the heading named "வாராவாரம்". >> Directly visiting a link doesn't produce the backtrace though. I need >> to visit a webpage with Tamil text on it twice to trigger it. It might >> well be a false warning since I see the warning >> >> Warning: program compiled against libxml 212 using older 209 >> Warning: program compiled against libxml 212 using older 209 >> >> in stderr printed. I updated my system (kernel updates included) but >> haven't restarted it yet. Of course, I built Emacs _after_ the update. >> If you want me to restart and check if you believe it is a false >> warning, I am to do so. Maybe a `make bootstrap' or somesuch is also in >> order? > >This abort is unrelated: I also get it, with no changes at all, and >also in Emacs 30. It looks like we fail to decode the text there, and >a buffer ends up with an invalid byte sequence, which triggers an >assertion violation. Please open a separate bug report about that. Okay will do so. >As for this bug, I will install the patch soon, I would dare to merge bug#54646 with this when you close the bug since I'm confident they both have the same underlying cause. >thanks to all for the efforts to investigate this tricky bug. Thank you very much Tim for your investigation! This was a paper cut that annoyed me to no end when I was viewing composed Tamil text which forced me to abandon reading Tamil text altogether inside Emacs. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 15:13 ` Visuwesh @ 2024-11-07 15:49 ` Eli Zaretskii 2024-11-07 16:00 ` Visuwesh 0 siblings, 1 reply; 90+ messages in thread From: Eli Zaretskii @ 2024-11-07 15:49 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, mituharu, 73752 > Date: Thu, 07 Nov 2024 20:43:32 +0530 > From: Visuwesh <visuweshm@gmail.com> > CC: dev@real-or-random.org, mituharu@math.s.chiba-u.ac.jp, xuan@xlk.me, > 73752@debbugs.gnu.org > > > >As for this bug, I will install the patch soon, > > I would dare to merge bug#54646 with this when you close the bug since I'm confident they both have the same underlying cause. Does this mean you no longer see the problems in bug#54646 with this patch? ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 15:49 ` Eli Zaretskii @ 2024-11-07 16:00 ` Visuwesh 0 siblings, 0 replies; 90+ messages in thread From: Visuwesh @ 2024-11-07 16:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, mituharu, xuan, 73752 [வியாழன் நவம்பர் 07, 2024] Eli Zaretskii wrote: >> Date: Thu, 07 Nov 2024 20:43:32 +0530 >> From: Visuwesh <visuweshm@gmail.com> >> CC: dev@real-or-random.org, mituharu@math.s.chiba-u.ac.jp, xuan@xlk.me, >> 73752@debbugs.gnu.org >> >> >> >As for this bug, I will install the patch soon, >> >> I would dare to merge bug#54646 with this when you close the bug since I'm confident they both have the same underlying cause. > > Does this mean you no longer see the problems in bug#54646 with this > patch? It has become very hard to reproduce the problems in bug#54646 but I am quite confident that they boil down to the same underlying issue as the symptoms are very similar (and I was unable to reproduce the issue in the Xft build). In fact, this bug caught my eye thanks to my experience with bug#54646. If it turns out that I can still reproduce the problems in bug#54646, we can always reopen it. However, I am confident that I would fail to do so. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-07 14:40 ` Eli Zaretskii 2024-11-07 15:13 ` Visuwesh @ 2024-11-08 8:08 ` Eli Zaretskii 1 sibling, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-11-08 8:08 UTC (permalink / raw) To: visuweshm, dev, xuan; +Cc: 73752, mituharu merge 54646 73752 close 73752 30.1 thanks > Cc: dev@real-or-random.org, xuan@xlk.me, mituharu@math.s.chiba-u.ac.jp, > 73752@debbugs.gnu.org > Date: Thu, 07 Nov 2024 16:40:49 +0200 > From: Eli Zaretskii <eliz@gnu.org> > > As for this bug, I will install the patch soon, thanks to all for the > efforts to investigate this tricky bug. I decided to risk installing this on the emacs-30 branch, since it is such a fundamental issue with display of composed characters. I'm therefore closing this bug (and merging it with bug#54646, which will also close that one). ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-04 17:45 ` Eli Zaretskii 2024-11-04 18:02 ` Visuwesh 2024-11-04 23:33 ` Tim Ruffing @ 2024-11-06 14:50 ` Visuwesh 2 siblings, 0 replies; 90+ messages in thread From: Visuwesh @ 2024-11-06 14:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tim Ruffing, xuan, YAMAMOTO Mitsuharu, 73752 [திங்கள் நவம்பர் 04, 2024] Eli Zaretskii wrote: >> From: Tim Ruffing <dev@real-or-random.org> >> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org >> Date: Mon, 04 Nov 2024 01:11:39 +0100 >> >> This fixes the problem: > > Thanks. But do you understand why? > > And how did you arrive to the conclusion that this is the change which > might help? > >> diff --git a/src/ftfont.c b/src/ftfont.c >> index 882d3eec256..2be443108f1 100644 >> --- a/src/ftfont.c >> +++ b/src/ftfont.c >> @@ -2994,9 +2994,8 @@ fthbfont_begin_hb_font (struct font *font, double >> *position_unit) >> struct font_info *ftfont_info = (struct font_info *) font; >> >> *position_unit = 1.0 / (1 << 6); >> - if (! ftfont_info->hb_font) >> - ftfont_info->hb_font >> - = hb_ft_font_create_referenced (ftfont_info->ft_size->face); >> + ftfont_info->hb_font >> + = hb_ft_font_create_referenced (ftfont_info->ft_size->face); >> return ftfont_info->hb_font; >> } >> >> That is, it makes at least the bug with Yixuan's script disappear. I >> haven't yet verified if this fixes what I often see during my daily >> usage. > > That code was written by a leading HarfBuzz developer, so it's hard > for me to believe that it is so incorrect. > > OTOH, I see that ftcrhbfont is the _only_ HarfBuzz-based font backend > which implements the end_hb_font method, and I think you both told me > that only the Cairo build has this problem? If so, I think the code > to look at is the end_hb_font method and what it does to the hb_font > object. The end_hb_font method is called each time the shaper is > called, so whatever it does to the hb_font object is inherited by the > next call to the shaper. > > Visuwesh, do the problems you see also disappear when you install the > change in fthbfont_begin_hb_font which removes the > !ftfont_info->hb_font condition for calling > hb_ft_font_create_referenced? I cannot seem to reproduce the msialignment with that change either. Likewise for the change Tim posted further down the thread which changes ftcrhbfont_end_hb_font. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-11-01 17:05 ` Eli Zaretskii 2024-11-02 3:34 ` Tim Ruffing @ 2024-11-02 10:32 ` Visuwesh 1 sibling, 0 replies; 90+ messages in thread From: Visuwesh @ 2024-11-02 10:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dev, xuan, 73752 [வெள்ளி நவம்பர் 01, 2024] Eli Zaretskii wrote: > Btw, is your Emacs built with only HarfBuz, or with both HarfBuz and > m17n-flt? configure log says Does Emacs use -lm17n-flt? no and system-configuration-features does not list m17n either so I am guessing the answer is only HarfBuzz. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-30 17:46 ` Eli Zaretskii 2024-10-30 18:00 ` Tim Ruffing @ 2024-10-31 8:12 ` Visuwesh 2024-10-31 9:43 ` Eli Zaretskii 1 sibling, 1 reply; 90+ messages in thread From: Visuwesh @ 2024-10-31 8:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tim Ruffing, xuan, 73752 [-- Attachment #1: Type: text/plain, Size: 2615 bytes --] [புதன் அக்டோபர் 30, 2024] Eli Zaretskii wrote: >> From: Tim Ruffing <dev@real-or-random.org> >> Cc: dev@real-or-random.org, eggert@cs.ucla.edu, 73752@debbugs.gnu.org >> Date: Wed, 30 Oct 2024 18:34:14 +0100 >> >> >> > > pp is calling Emacs to print to its stderr. If that is redirected >> > > somewhere else you won't see the output. >> > >> >> Ah, this was the right hint. I'm using emacs in daemon mode, started >> from systemd, so I can inspect stderr via journalctl. >> >> ------ >> >> Broken rendering for ligature "===" starting at pos 1290 (emacs happens >> to be in daemon mode) >> >> [...] >> 39 480: COMP[19 (0..0)] pos=1290 w=20 a+d=20+6 face=39 MB >> 40 500: COMP[19 (1..1)] pos=1291 w=20 a+d=20+6 face=39 MB >> 41 520: COMP[19 (2..2)] pos=1292 w=20 a+d=20+6 face=39 MB >> [...] >> >> $ pp composition_gstring_from_id(19) >> >> [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]] >> >> ------- >> >> Proper rendering (emacs happens to be not in daemon mode): >> >> 39 390: COMP[13 (0..0)] pos=1290 w=10 a+d=20+6 face=39 MB >> 40 400: COMP[13 (1..1)] pos=1291 w=10 a+d=20+6 face=39 MB >> 41 410: COMP[13 (2..2)] pos=1292 w=10 a+d=20+6 face=39 MB >> >> $ pp composition_gstring_from_id(13) >> >> [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 13 [0 0 61 5852 10 1 11 11 -4 nil] [1 1 61 5896 10 -1 11 11 -4 nil] [2 2 61 5891 10 -1 9 11 -4 nil]] >> >> >> Both sessions are still running. I Hope this helps. Let me know if need >> more remote hands. I observe very similar results: Properly rendered (in a fresh Emacs session): [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2 [0 0 45 1970 9 0 9 7 -4 nil] [1 1 45 1969 9 -1 10 7 -4 nil] [2 2 62 2728 9 -1 9 11 0 nil]] Misaligned: [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2231 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]] In the misaligned session, cached entry for the same text ("-->") that is rendered properly at a different font size: [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-17-*-*-*-m-0-iso10646-1"> 45 45 62] 2179 [0 0 45 1970 10 0 11 7 -4 nil] [1 1 45 1969 10 -1 11 7 -4 nil] [2 2 62 2728 10 -1 10 12 0 nil]] [-- Attachment #2: Type: text/plain, Size: 687 bytes --] > Did the "bad" display start from "good" at the beginning of a session? > Or did it start from "bad" to begin with? If the former, the next > idea is to put a watchpoint on the cached composition in a session > with "good" display, and then do whatever it takes to make it "bad", > hoping that the watchpoint will break at some point and show us the > code which replaces nil with these [X-OFF Y-OFF WADJUST] vectors. I think it starts from "bad" to begin with. But the former theory could still apply, if you do not mind this vague answer, can you provide instructions to set a watchpoint? If the watchpoint never triggers, we might be able to at least rule out the former theory. ^ permalink raw reply [flat|nested] 90+ messages in thread
* bug#73752: 29.4; Ligatures are randomly rendered with extra spaces 2024-10-31 8:12 ` Visuwesh @ 2024-10-31 9:43 ` Eli Zaretskii 0 siblings, 0 replies; 90+ messages in thread From: Eli Zaretskii @ 2024-10-31 9:43 UTC (permalink / raw) To: Visuwesh; +Cc: dev, xuan, 73752 > From: Visuwesh <visuweshm@gmail.com> > Cc: Tim Ruffing <dev@real-or-random.org>, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Thu, 31 Oct 2024 13:42:06 +0530 > > > Did the "bad" display start from "good" at the beginning of a session? > > Or did it start from "bad" to begin with? If the former, the next > > idea is to put a watchpoint on the cached composition in a session > > with "good" display, and then do whatever it takes to make it "bad", > > hoping that the watchpoint will break at some point and show us the > > code which replaces nil with these [X-OFF Y-OFF WADJUST] vectors. > > I think it starts from "bad" to begin with. But the former theory could > still apply, if you do not mind this vague answer, can you provide > instructions to set a watchpoint? If the watchpoint never triggers, we > might be able to at least rule out the former theory. Let's first see if a breakpoint inside composition_gstring_adjust_zero_width ever breaks in your cases. If it doesn't we will try the watchpoint technique. ^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2024-11-08 8:08 UTC | newest] Thread overview: 90+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-10-11 16:18 bug#73752: 29.4; Ligatures are randomly rendered with extra spaces xuan 2024-10-12 8:02 ` Eli Zaretskii 2024-10-12 16:09 ` Yixuan Chen 2024-10-27 10:21 ` Eli Zaretskii 2024-10-27 16:19 ` Visuwesh 2024-10-27 17:19 ` Eli Zaretskii 2024-10-27 17:27 ` Eli Zaretskii 2024-10-27 17:39 ` Yixuan Chen 2024-10-27 17:43 ` Eli Zaretskii 2024-10-27 17:46 ` Yixuan Chen 2024-10-27 19:14 ` Eli Zaretskii 2024-10-27 19:36 ` Yixuan Chen 2024-10-27 19:44 ` Eli Zaretskii 2024-10-27 19:47 ` Yixuan Chen 2024-10-27 20:11 ` Eli Zaretskii 2024-10-27 19:41 ` Yixuan Chen 2024-10-27 20:07 ` Eli Zaretskii 2024-10-27 20:32 ` Yixuan Chen 2024-10-28 14:25 ` Eli Zaretskii 2024-10-28 14:44 ` Yixuan Chen 2024-10-28 14:47 ` Yixuan Chen 2024-10-28 15:05 ` Eli Zaretskii 2024-10-28 15:20 ` Yixuan Chen 2024-10-28 17:19 ` Eli Zaretskii 2024-10-28 17:26 ` Eli Zaretskii 2024-10-28 17:28 ` Yixuan Chen 2024-10-28 18:41 ` Eli Zaretskii 2024-10-28 4:26 ` Visuwesh 2024-10-28 14:59 ` Eli Zaretskii 2024-10-28 15:24 ` Yixuan Chen 2024-10-28 16:18 ` Visuwesh 2024-10-28 17:13 ` Eli Zaretskii 2024-10-29 10:59 ` Visuwesh 2024-10-29 13:04 ` Eli Zaretskii 2024-10-29 13:54 ` Visuwesh 2024-10-29 14:00 ` Visuwesh 2024-10-29 15:38 ` Eli Zaretskii 2024-10-29 16:46 ` Visuwesh 2024-10-29 17:45 ` Eli Zaretskii 2024-10-30 5:43 ` Visuwesh 2024-10-29 16:51 ` Eli Zaretskii 2024-10-27 17:29 ` Yixuan Chen 2024-10-29 23:14 ` Tim Ruffing 2024-10-30 15:12 ` Eli Zaretskii 2024-10-30 15:45 ` Eli Zaretskii [not found] ` <mvmikt9zkcq.fsf@suse.de> 2024-10-30 15:47 ` Eli Zaretskii 2024-10-30 17:34 ` Tim Ruffing 2024-10-30 17:46 ` Eli Zaretskii 2024-10-30 18:00 ` Tim Ruffing 2024-10-30 18:57 ` Eli Zaretskii 2024-10-31 1:39 ` Tim Ruffing 2024-10-31 2:36 ` Yixuan Chen 2024-10-31 2:46 ` Yixuan Chen 2024-10-31 7:44 ` Eli Zaretskii 2024-10-31 9:42 ` Eli Zaretskii 2024-11-01 17:05 ` Eli Zaretskii 2024-11-02 3:34 ` Tim Ruffing 2024-11-02 9:52 ` Eli Zaretskii 2024-11-02 10:39 ` Visuwesh 2024-11-02 12:07 ` Eli Zaretskii 2024-11-02 13:29 ` Visuwesh 2024-11-02 16:47 ` Eli Zaretskii 2024-11-02 17:04 ` Visuwesh 2024-11-02 17:18 ` Eli Zaretskii 2024-11-02 17:31 ` Visuwesh 2024-11-02 17:34 ` Eli Zaretskii 2024-11-02 17:39 ` Visuwesh 2024-11-02 17:44 ` Eli Zaretskii 2024-11-02 17:54 ` Visuwesh 2024-11-02 18:02 ` Visuwesh 2024-11-02 18:27 ` Eli Zaretskii 2024-11-04 0:11 ` Tim Ruffing 2024-11-04 17:45 ` Eli Zaretskii 2024-11-04 18:02 ` Visuwesh 2024-11-04 23:33 ` Tim Ruffing 2024-11-04 23:47 ` Tim Ruffing 2024-11-06 12:02 ` Tim Ruffing 2024-11-06 13:11 ` Eli Zaretskii 2024-11-07 2:12 ` Tim Ruffing 2024-11-07 7:05 ` Eli Zaretskii 2024-11-07 13:45 ` Visuwesh 2024-11-07 14:40 ` Eli Zaretskii 2024-11-07 15:13 ` Visuwesh 2024-11-07 15:49 ` Eli Zaretskii 2024-11-07 16:00 ` Visuwesh 2024-11-08 8:08 ` Eli Zaretskii 2024-11-06 14:50 ` Visuwesh 2024-11-02 10:32 ` Visuwesh 2024-10-31 8:12 ` Visuwesh 2024-10-31 9:43 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).