* bug#39133: 28.0.50; Emacs slowdown on special char @ 2020-01-14 13:21 Evgeny Zajcev 2020-01-14 15:26 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Evgeny Zajcev @ 2020-01-14 13:21 UTC (permalink / raw) To: 39133 [-- Attachment #1: Type: text/plain, Size: 11078 bytes --] I'm experiencing extreme Emacs slowdown when VARIATION SELECTOR-16 char is used somewhere in Emacs buffer. For example, I just executed: (insert "a\xfe0f") in *scratch* buffer. Moving cursor (when this char is visible) become unbearable. Here is the results of cpu profiling: - command-execute 776 62% - call-interactively 776 62% - funcall-interactively 675 54% - previous-line 476 38% - line-move 476 38% - line-move-1 476 38% + vertical-motion 225 18% - next-line 198 15% - line-move 198 15% - line-move-1 198 15% + vertical-motion 94 7% + execute-extended-command 1 0% + byte-code 101 8% auto-compose-chars 185 14% + timer-event-handler 175 14% - redisplay_internal (C function) 75 6% auto-compose-chars 75 6% - ... 30 2% Automatic GC 30 2% As I remember I did not experienced something similar in Emacs 26/27 Thanks -------------------- In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.18.9, cairo version 1.14.6) of 2020-01-13 built on wrt Repository revision: 7c5d6a2afc6c23a7fff8456f506ee2aa2d37a3b9 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.11804000 System Description: Ubuntu 16.04.1 LTS Recent messages: next-line: End of buffer [2 times] Mark activated [2 times] CPU profiler stopped CPU profiler started Mark set Quit Mark set CPU profiler stopped CPU profiler started Mark set Configured using: 'configure --with-modules --with-cairo' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2 GMP Important settings: value of $LC_MONETARY: ru_RU.UTF-8 value of $LC_NUMERIC: ru_RU.UTF-8 value of $LC_TIME: ru_RU.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tracking-mode: t telega-mode-line-mode: t icomplete-mode: t save-place-mode: t pyvenv-mode: t shell-dirtrack-mode: t display-time-mode: t global-undo-tree-mode: t undo-tree-mode: t override-global-mode: t cl-old-struct-compat-mode: t global-eldoc-mode: t eldoc-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t auto-fill-function: do-auto-fill transient-mark-mode: t Load-path shadows: /home/lg/.emacs.d/elpa/circe-20180105.1158/tracking hides /home/lg/.emacs.d/elpa/tracking-20171210.2102/tracking /home/lg/.emacs.d/elpa/circe-20180105.1158/shorten hides /home/lg/.emacs.d/elpa/tracking-20171210.2102/shorten ~/dev/xelb/xcb-renderutil hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-renderutil ~/dev/xelb/xcb-xinput hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xinput ~/dev/xelb/xcb-shape hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-shape ~/dev/xelb/xcb-icccm hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-icccm ~/dev/xelb/xcb-dri3 hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-dri3 ~/dev/xelb/xcb-xc_misc hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xc_misc ~/dev/xelb/xcb-render hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-render ~/dev/xelb/xcb-xf86vidmode hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xf86vidmode ~/dev/xelb/xcb-cursor hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-cursor ~/dev/xelb/xcb-dri2 hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-dri2 ~/dev/xelb/xcb-xprint hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xprint ~/dev/xelb/xcb-systemtray hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-systemtray ~/dev/xelb/xcb-composite hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-composite ~/dev/xelb/xcb-types hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-types ~/dev/xelb/xcb-dpms hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-dpms ~/dev/xelb/xcb-bigreq hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-bigreq ~/dev/xelb/xcb-xselinux hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xselinux ~/dev/xelb/xcb-xproto hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xproto ~/dev/xelb/xcb-xlib hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xlib ~/dev/xelb/xcb-xf86dri hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xf86dri ~/dev/xelb/xcb hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb ~/dev/xelb/xcb-xembed hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xembed ~/dev/xelb/xcb-present hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-present ~/dev/xelb/xcb-screensaver hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-screensaver ~/dev/xelb/xcb-shm hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-shm ~/dev/xelb/xcb-ge hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-ge ~/dev/xelb/xcb-xinerama hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xinerama ~/dev/xelb/xcb-xim hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xim ~/dev/xelb/xcb-damage hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-damage ~/dev/xelb/xcb-glx hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-glx ~/dev/xelb/xcb-sync hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-sync ~/dev/xelb/xcb-res hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-res ~/dev/xelb/xcb-xfixes hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xfixes ~/dev/xelb/xcb-xtest hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xtest ~/dev/xelb/xcb-keysyms hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-keysyms ~/dev/xelb/xcb-ewmh hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-ewmh ~/dev/xelb/el_client hides /home/lg/.emacs.d/elpa/xelb-0.18/el_client ~/dev/xelb/xcb-record hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-record ~/dev/xelb/xcb-xv hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xv ~/dev/xelb/xcb-randr hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-randr ~/dev/xelb/xcb-xkb hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xkb ~/dev/xelb/xcb-xevie hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xevie ~/dev/xelb/xcb-xvmc hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xvmc ~/dev/xelb/xelb hides /home/lg/.emacs.d/elpa/xelb-0.18/xelb Features: (shadow sort mail-extr emacsbug sendmail descr-text bug-reference cc-mode cc-fonts cc-guess cc-menus cc-styles cc-align apropos profiler find-func disp-table fill-column-indicator vc vc-dispatcher vc-git smerge-mode git log-edit pcvs-util add-log misearch multi-isearch wordfreq face-remap rect mm-archive gnutls network-stream url-cache multitran mule-util hl-line tracking shorten telega telega-modes telega-webpage telega-tme visual-fill-column telega-chat telega-i18n telega-company telega-user telega-sticker telega-notifications notifications dbus telega-msg telega-vvnote telega-media telega-root telega-voip telega-ffplay telega-info telega-filter telega-ins telega-inline telega-tdlib telega-util color svg dom xml ewoc telega-server telega-core cursor-sensor telega-customize exwm-wconf winner exwm-misc exwm exwm-match exwm-input xcb-keysyms exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types work desktop frameset gnus-demon nntp gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc gnus-spec gnus-win nnoo gnus-int gnus-range message rfc822 mml mml-sec epa epg epg-config mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus nnheader gnus-util rmail rmail-loaddefs text-property-search mail-utils autoinsert cal-menu calendar cal-loaddefs icomplete saveplace cython-mode company-capf company pcase help-fns radix-tree elpy find-file-in-project ivy delsel ivy-overlay ffap windmove diff-mode elpy-shell pyvenv elpy-profile elpy-django elpy-refactor python tramp-sh tramp tramp-loaddefs trampver tramp-integration tramp-compat parse-time iso8601 time-date ls-lisp format-spec grep files-x etags fileloop generator xref project cus-edit cus-start cus-load wid-edit python-mode info-look which-func imenu shell pcomplete hippie-exp flymake-proc flymake warnings thingatpt compile cc-cmds cc-engine cc-vars cc-defs dot-mode gist dired dired-loaddefs gh-gist gh-oauth gh-api logito gh-cache pcache gh-auth gh-url url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny timezone eieio-base server time google-translate google-translate-default-ui google-translate-core-ui google-translate-core google-translate-tk url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap whitespace undo-tree diff ido comint ansi-color ring avoid ibuffer-vc ibuf-ext ibuffer ibuffer-loaddefs edmacro kmacro browse-kill-ring derived cl cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core tex-site gh-common gh-profile rx s marshal eieio-compat dash advice info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 844236 204685) (symbols 48 53129 1) (strings 32 212317 6977) (string-bytes 1 7670144) (vectors 16 104746) (vector-slots 8 3029493 25214) (floats 8 5990 341) (intervals 56 26458 1076) (buffers 1000 53) (heap 1024 91340 6613)) -- lg [-- Attachment #2: Type: text/html, Size: 12412 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-14 13:21 bug#39133: 28.0.50; Emacs slowdown on special char Evgeny Zajcev @ 2020-01-14 15:26 ` Eli Zaretskii 2020-01-14 16:24 ` Robert Pluim 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-01-14 15:26 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: 39133 > From: Evgeny Zajcev <lg.zevlg@gmail.com> > Date: Tue, 14 Jan 2020 16:21:23 +0300 > > I'm experiencing extreme Emacs slowdown when VARIATION SELECTOR-16 char > is used somewhere in Emacs buffer. For example, I just executed: > > (insert "a\xfe0f") > > in *scratch* buffer. Moving cursor (when this char is visible) become > unbearable. Here is the results of cpu profiling: > > - command-execute 776 62% > - call-interactively 776 62% > - funcall-interactively 675 54% > - previous-line 476 38% > - line-move 476 38% > - line-move-1 476 38% > + vertical-motion 225 18% Does it help to set inhibit-compacting-font-caches non-nil? > As I remember I did not experienced something similar in Emacs 26/27 I don't think Emacs < 27 supported variation selectors, did it? ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-14 15:26 ` Eli Zaretskii @ 2020-01-14 16:24 ` Robert Pluim 2020-01-15 4:26 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-01-14 16:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Evgeny Zajcev, 39133 >>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: Evgeny Zajcev <lg.zevlg@gmail.com> >> Date: Tue, 14 Jan 2020 16:21:23 +0300 >> >> I'm experiencing extreme Emacs slowdown when VARIATION SELECTOR-16 char >> is used somewhere in Emacs buffer. For example, I just executed: >> >> (insert "a\xfe0f") >> >> in *scratch* buffer. Moving cursor (when this char is visible) become >> unbearable. Here is the results of cpu profiling: >> >> - command-execute 776 62% >> - call-interactively 776 62% >> - funcall-interactively 675 54% >> - previous-line 476 38% >> - line-move 476 38% >> - line-move-1 476 38% >> + vertical-motion 225 18% Eli> Does it help to set inhibit-compacting-font-caches non-nil? >> As I remember I did not experienced something similar in Emacs 26/27 Eli> I don't think Emacs < 27 supported variation selectors, did it? Itʼs coming from the caching in ftcrfont_glyph_extents: row = glyph / METRICS_NCOLS_PER_ROW; <== glyph == 0xFFFFFFFF, row -> 0x1FFFFFF col = glyph % METRICS_NCOLS_PER_ROW; if (row >= ftcrfont_info->metrics_nrows) { ftcrfont_info->metrics = xrealloc (ftcrfont_info->metrics, sizeof (struct font_metrics *) * (row + 1)); memset (ftcrfont_info->metrics + ftcrfont_info->metrics_nrows, 0, (sizeof (struct font_metrics *) * (row + 1 - ftcrfont_info->metrics_nrows))); ftcrfont_info->metrics_nrows = row + 1; <=== weʼre updating metrics_nrows, lets look in ftfont.h } ftfont.h: #ifdef USE_CAIRO cairo_scaled_font_t *cr_scaled_font; /* Scale factor from the bitmap strike metrics in 1/64 pixels, used as the hb_position_t value in HarfBuzz, to those in (scaled) pixels. The value is 0 for scalable fonts. */ double bitmap_position_unit; /* Font metrics cache. */ struct font_metrics **metrics; short metrics_nrows; ^^^^^ oops! Now we end up calling xrealloc every time we enter ftctfont_glyph_extents for that glyph. Of course, I donʼt think glyph should be 0xFFFFFFFF, but thatʼs a different problem. Robert ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-14 16:24 ` Robert Pluim @ 2020-01-15 4:26 ` YAMAMOTO Mitsuharu 2020-01-15 8:25 ` Robert Pluim 2020-01-15 16:19 ` Eli Zaretskii 0 siblings, 2 replies; 17+ messages in thread From: YAMAMOTO Mitsuharu @ 2020-01-15 4:26 UTC (permalink / raw) To: Robert Pluim; +Cc: Evgeny Zajcev, 39133 On Wed, 15 Jan 2020 01:24:05 +0900, Robert Pluim wrote: > > >>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <eliz@gnu.org> said: > > >> From: Evgeny Zajcev <lg.zevlg@gmail.com> > >> Date: Tue, 14 Jan 2020 16:21:23 +0300 > >> > >> I'm experiencing extreme Emacs slowdown when VARIATION SELECTOR-16 char > >> is used somewhere in Emacs buffer. For example, I just executed: > >> > >> (insert "a\xfe0f") > >> > >> in *scratch* buffer. Moving cursor (when this char is visible) become > >> unbearable. Here is the results of cpu profiling: > >> > >> - command-execute 776 62% > >> - call-interactively 776 62% > >> - funcall-interactively 675 54% > >> - previous-line 476 38% > >> - line-move 476 38% > >> - line-move-1 476 38% > >> + vertical-motion 225 18% > > Eli> Does it help to set inhibit-compacting-font-caches non-nil? > > >> As I remember I did not experienced something similar in Emacs 26/27 > > Eli> I don't think Emacs < 27 supported variation selectors, did it? > > Itʼs coming from the caching in ftcrfont_glyph_extents: > > row = glyph / METRICS_NCOLS_PER_ROW; <== glyph == 0xFFFFFFFF, row -> 0x1FFFFFF > col = glyph % METRICS_NCOLS_PER_ROW; > if (row >= ftcrfont_info->metrics_nrows) > { > ftcrfont_info->metrics = > xrealloc (ftcrfont_info->metrics, > sizeof (struct font_metrics *) * (row + 1)); > memset (ftcrfont_info->metrics + ftcrfont_info->metrics_nrows, 0, > (sizeof (struct font_metrics *) > * (row + 1 - ftcrfont_info->metrics_nrows))); > ftcrfont_info->metrics_nrows = row + 1; <=== weʼre updating > metrics_nrows, lets look in ftfont.h > } > > ftfont.h: > > #ifdef USE_CAIRO > cairo_scaled_font_t *cr_scaled_font; > /* Scale factor from the bitmap strike metrics in 1/64 pixels, used > as the hb_position_t value in HarfBuzz, to those in (scaled) > pixels. The value is 0 for scalable fonts. */ > double bitmap_position_unit; > /* Font metrics cache. */ > struct font_metrics **metrics; > short metrics_nrows; > ^^^^^ oops! Now we end up calling xrealloc every time we enter > ftctfont_glyph_extents for that glyph. > > Of course, I donʼt think glyph should be 0xFFFFFFFF, but thatʼs a > different problem. > > Robert 0xFFFFFFFF comes from FONT_INVALID_CODE. font->driver->text_extents shouldn't be called if font->font->driver->encode_char returns it. diff --git a/src/font.c b/src/font.c index 2b90903c90..03e6176220 100644 --- a/src/font.c +++ b/src/font.c @@ -4420,15 +4420,19 @@ font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object) { struct font *font = XFONT_OBJECT (font_object); unsigned code = font->driver->encode_char (font, LGLYPH_CHAR (glyph)); - struct font_metrics metrics; - - LGLYPH_SET_CODE (glyph, code); - font->driver->text_extents (font, &code, 1, &metrics); - LGLYPH_SET_LBEARING (glyph, metrics.lbearing); - LGLYPH_SET_RBEARING (glyph, metrics.rbearing); - LGLYPH_SET_WIDTH (glyph, metrics.width); - LGLYPH_SET_ASCENT (glyph, metrics.ascent); - LGLYPH_SET_DESCENT (glyph, metrics.descent); + + if (code != FONT_INVALID_CODE) + { + struct font_metrics metrics; + + LGLYPH_SET_CODE (glyph, code); + font->driver->text_extents (font, &code, 1, &metrics); + LGLYPH_SET_LBEARING (glyph, metrics.lbearing); + LGLYPH_SET_RBEARING (glyph, metrics.rbearing); + LGLYPH_SET_WIDTH (glyph, metrics.width); + LGLYPH_SET_ASCENT (glyph, metrics.ascent); + LGLYPH_SET_DESCENT (glyph, metrics.descent); + } } But I'm not sure if it is ok to leave the code and metrics-related fields nil when encode_char returns FONT_INVALID_CODE. Handa-san? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-15 4:26 ` YAMAMOTO Mitsuharu @ 2020-01-15 8:25 ` Robert Pluim 2020-01-15 10:47 ` Evgeny Zajcev 2020-01-15 16:19 ` Eli Zaretskii 1 sibling, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-01-15 8:25 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Evgeny Zajcev, 39133 >>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said: YAMAMOTO> 0xFFFFFFFF comes from FONT_INVALID_CODE. font->driver->text_extents YAMAMOTO> shouldn't be called if font->font->driver->encode_char returns it. YAMAMOTO> diff --git a/src/font.c b/src/font.c YAMAMOTO> index 2b90903c90..03e6176220 100644 YAMAMOTO> --- a/src/font.c YAMAMOTO> +++ b/src/font.c YAMAMOTO> @@ -4420,15 +4420,19 @@ font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object) YAMAMOTO> { YAMAMOTO> struct font *font = XFONT_OBJECT (font_object); YAMAMOTO> unsigned code = font->driver->encode_char (font, LGLYPH_CHAR (glyph)); YAMAMOTO> - struct font_metrics metrics; YAMAMOTO> - YAMAMOTO> - LGLYPH_SET_CODE (glyph, code); YAMAMOTO> - font->driver->text_extents (font, &code, 1, &metrics); YAMAMOTO> - LGLYPH_SET_LBEARING (glyph, metrics.lbearing); YAMAMOTO> - LGLYPH_SET_RBEARING (glyph, metrics.rbearing); YAMAMOTO> - LGLYPH_SET_WIDTH (glyph, metrics.width); YAMAMOTO> - LGLYPH_SET_ASCENT (glyph, metrics.ascent); YAMAMOTO> - LGLYPH_SET_DESCENT (glyph, metrics.descent); YAMAMOTO> + YAMAMOTO> + if (code != FONT_INVALID_CODE) YAMAMOTO> + { YAMAMOTO> + struct font_metrics metrics; YAMAMOTO> + YAMAMOTO> + LGLYPH_SET_CODE (glyph, code); YAMAMOTO> + font->driver->text_extents (font, &code, 1, &metrics); YAMAMOTO> + LGLYPH_SET_LBEARING (glyph, metrics.lbearing); YAMAMOTO> + LGLYPH_SET_RBEARING (glyph, metrics.rbearing); YAMAMOTO> + LGLYPH_SET_WIDTH (glyph, metrics.width); YAMAMOTO> + LGLYPH_SET_ASCENT (glyph, metrics.ascent); YAMAMOTO> + LGLYPH_SET_DESCENT (glyph, metrics.descent); YAMAMOTO> + } YAMAMOTO> } YAMAMOTO> But I'm not sure if it is ok to leave the code and metrics-related YAMAMOTO> fields nil when encode_char returns FONT_INVALID_CODE. Handa-san? I donʼt know either, but your patch fixes the slowdown and Iʼve seen no negative effects yet. Robert ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-15 8:25 ` Robert Pluim @ 2020-01-15 10:47 ` Evgeny Zajcev 0 siblings, 0 replies; 17+ messages in thread From: Evgeny Zajcev @ 2020-01-15 10:47 UTC (permalink / raw) To: Robert Pluim; +Cc: 39133 [-- Attachment #1: Type: text/plain, Size: 2372 bytes --] ср, 15 янв. 2020 г. в 11:25, Robert Pluim <rpluim@gmail.com>: > >>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu < > mituharu@math.s.chiba-u.ac.jp> said: > > YAMAMOTO> 0xFFFFFFFF comes from FONT_INVALID_CODE. > font->driver->text_extents > YAMAMOTO> shouldn't be called if font->font->driver->encode_char > returns it. > > YAMAMOTO> diff --git a/src/font.c b/src/font.c > YAMAMOTO> index 2b90903c90..03e6176220 100644 > YAMAMOTO> --- a/src/font.c > YAMAMOTO> +++ b/src/font.c > YAMAMOTO> @@ -4420,15 +4420,19 @@ font_fill_lglyph_metrics > (Lisp_Object glyph, Lisp_Object font_object) > YAMAMOTO> { > YAMAMOTO> struct font *font = XFONT_OBJECT (font_object); > YAMAMOTO> unsigned code = font->driver->encode_char (font, > LGLYPH_CHAR (glyph)); > YAMAMOTO> - struct font_metrics metrics; > YAMAMOTO> - > YAMAMOTO> - LGLYPH_SET_CODE (glyph, code); > YAMAMOTO> - font->driver->text_extents (font, &code, 1, &metrics); > YAMAMOTO> - LGLYPH_SET_LBEARING (glyph, metrics.lbearing); > YAMAMOTO> - LGLYPH_SET_RBEARING (glyph, metrics.rbearing); > YAMAMOTO> - LGLYPH_SET_WIDTH (glyph, metrics.width); > YAMAMOTO> - LGLYPH_SET_ASCENT (glyph, metrics.ascent); > YAMAMOTO> - LGLYPH_SET_DESCENT (glyph, metrics.descent); > YAMAMOTO> + > YAMAMOTO> + if (code != FONT_INVALID_CODE) > YAMAMOTO> + { > YAMAMOTO> + struct font_metrics metrics; > YAMAMOTO> + > YAMAMOTO> + LGLYPH_SET_CODE (glyph, code); > YAMAMOTO> + font->driver->text_extents (font, &code, 1, &metrics); > YAMAMOTO> + LGLYPH_SET_LBEARING (glyph, metrics.lbearing); > YAMAMOTO> + LGLYPH_SET_RBEARING (glyph, metrics.rbearing); > YAMAMOTO> + LGLYPH_SET_WIDTH (glyph, metrics.width); > YAMAMOTO> + LGLYPH_SET_ASCENT (glyph, metrics.ascent); > YAMAMOTO> + LGLYPH_SET_DESCENT (glyph, metrics.descent); > YAMAMOTO> + } > YAMAMOTO> } > > > YAMAMOTO> But I'm not sure if it is ok to leave the code and > metrics-related > YAMAMOTO> fields nil when encode_char returns FONT_INVALID_CODE. > Handa-san? > > I donʼt know either, but your patch fixes the slowdown and Iʼve seen > no negative effects yet. > Yeah, this patch fixes the slowdown! -- lg [-- Attachment #2: Type: text/html, Size: 3182 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-15 4:26 ` YAMAMOTO Mitsuharu 2020-01-15 8:25 ` Robert Pluim @ 2020-01-15 16:19 ` Eli Zaretskii 2020-01-24 10:13 ` Robert Pluim 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-01-15 16:19 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: lg.zevlg, rpluim, 39133 > Date: Wed, 15 Jan 2020 13:26:11 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Eli Zaretskii <eliz@gnu.org>, > Evgeny Zajcev <lg.zevlg@gmail.com>, > 39133@debbugs.gnu.org, handa@gnu.org > > + if (code != FONT_INVALID_CODE) > + { > + struct font_metrics metrics; > + > + LGLYPH_SET_CODE (glyph, code); > + font->driver->text_extents (font, &code, 1, &metrics); > + LGLYPH_SET_LBEARING (glyph, metrics.lbearing); > + LGLYPH_SET_RBEARING (glyph, metrics.rbearing); > + LGLYPH_SET_WIDTH (glyph, metrics.width); > + LGLYPH_SET_ASCENT (glyph, metrics.ascent); > + LGLYPH_SET_DESCENT (glyph, metrics.descent); > + } > } > > > But I'm not sure if it is ok to leave the code and metrics-related > fields nil when encode_char returns FONT_INVALID_CODE. Handa-san? We could do in the 'else' branch the same we do in the single caller of this function, fill_gstring_body, when we don't call font_fill_lglyph_metrics: if (FONT_OBJECT_P (font_object)) { font_fill_lglyph_metrics (g, font_object); } else { int width = XFIXNAT (CHAR_TABLE_REF (Vchar_width_table, c)); LGLYPH_SET_CODE (g, c); LGLYPH_SET_LBEARING (g, 0); LGLYPH_SET_RBEARING (g, width); LGLYPH_SET_WIDTH (g, width); LGLYPH_SET_ASCENT (g, 1); LGLYPH_SET_DESCENT (g, 0); } ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-15 16:19 ` Eli Zaretskii @ 2020-01-24 10:13 ` Robert Pluim 2020-01-24 10:22 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-01-24 10:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39133, lg.zevlg >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz@gnu.org> said: Eli> We could do in the 'else' branch the same we do in the single caller Eli> of this function, fill_gstring_body, when we don't call Eli> font_fill_lglyph_metrics: Rather than duplicate that code, I moved the FONT_INVALID_CODE check up. This works for me: diff --git a/src/composite.c b/src/composite.c index 53e6930b5f..bf5884fa55 100644 --- a/src/composite.c +++ b/src/composite.c @@ -818,6 +818,7 @@ fill_gstring_body (Lisp_Object gstring) Lisp_Object header = AREF (gstring, 0); ptrdiff_t len = LGSTRING_CHAR_LEN (gstring); ptrdiff_t i; + struct font *font = XFONT_OBJECT (font_object); for (i = 0; i < len; i++) { @@ -832,9 +833,12 @@ fill_gstring_body (Lisp_Object gstring) LGLYPH_SET_FROM (g, i); LGLYPH_SET_TO (g, i); LGLYPH_SET_CHAR (g, c); - if (FONT_OBJECT_P (font_object)) + + unsigned int code = font->driver->encode_char (font, LGLYPH_CHAR (g)); + + if (FONT_OBJECT_P (font_object) && code != FONT_INVALID_CODE) { - font_fill_lglyph_metrics (g, font_object); + font_fill_lglyph_metrics (g, font_object, code); } else { diff --git a/src/font.c b/src/font.c index bb39aef92d..03d9cc50ae 100644 --- a/src/font.c +++ b/src/font.c @@ -4416,10 +4416,9 @@ DEFUN ("clear-font-cache", Fclear_font_cache, Sclear_font_cache, 0, 0, 0, \f void -font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object) +font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object, unsigned int code) { struct font *font = XFONT_OBJECT (font_object); - unsigned code = font->driver->encode_char (font, LGLYPH_CHAR (glyph)); struct font_metrics metrics; LGLYPH_SET_CODE (glyph, code); diff --git a/src/font.h b/src/font.h index 0561e3c83f..d82039eed8 100644 --- a/src/font.h +++ b/src/font.h @@ -886,7 +886,7 @@ valid_font_driver (struct font_driver const *d) extern Lisp_Object font_range (ptrdiff_t, ptrdiff_t, ptrdiff_t *, struct window *, struct face *, Lisp_Object); -extern void font_fill_lglyph_metrics (Lisp_Object, Lisp_Object); +extern void font_fill_lglyph_metrics (Lisp_Object, Lisp_Object, unsigned int); extern Lisp_Object font_put_extra (Lisp_Object font, Lisp_Object prop, Lisp_Object val); ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 10:13 ` Robert Pluim @ 2020-01-24 10:22 ` Eli Zaretskii 2020-01-24 13:09 ` Robert Pluim 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-01-24 10:22 UTC (permalink / raw) To: Robert Pluim; +Cc: 39133, lg.zevlg > From: Robert Pluim <rpluim@gmail.com> > Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, > 39133@debbugs.gnu.org, lg.zevlg@gmail.com, handa@gnu.org > Date: Fri, 24 Jan 2020 11:13:54 +0100 > > >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz@gnu.org> said: > Eli> We could do in the 'else' branch the same we do in the single caller > Eli> of this function, fill_gstring_body, when we don't call > Eli> font_fill_lglyph_metrics: > > Rather than duplicate that code, I moved the FONT_INVALID_CODE check > up. This works for me: Looks reasonable, thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 10:22 ` Eli Zaretskii @ 2020-01-24 13:09 ` Robert Pluim 2020-01-24 13:40 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-01-24 13:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lg.zevlg, 39133 >>>>> On Fri, 24 Jan 2020 12:22:38 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: Robert Pluim <rpluim@gmail.com> >> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, >> 39133@debbugs.gnu.org, lg.zevlg@gmail.com, handa@gnu.org >> Date: Fri, 24 Jan 2020 11:13:54 +0100 >> >> >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz@gnu.org> said: Eli> We could do in the 'else' branch the same we do in the single caller Eli> of this function, fill_gstring_body, when we don't call Eli> font_fill_lglyph_metrics: >> >> Rather than duplicate that code, I moved the FONT_INVALID_CODE check >> up. This works for me: Eli> Looks reasonable, thanks. Except it crashes under -nw. More investigation required. Robert ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 13:09 ` Robert Pluim @ 2020-01-24 13:40 ` Eli Zaretskii 2020-01-24 13:50 ` Robert Pluim 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-01-24 13:40 UTC (permalink / raw) To: Robert Pluim; +Cc: lg.zevlg, 39133 > From: Robert Pluim <rpluim@gmail.com> > Cc: lg.zevlg@gmail.com, 39133@debbugs.gnu.org, > mituharu@math.s.chiba-u.ac.jp, handa@gnu.org > Date: Fri, 24 Jan 2020 14:09:22 +0100 > > >> Rather than duplicate that code, I moved the FONT_INVALID_CODE check > >> up. This works for me: > > Eli> Looks reasonable, thanks. > > Except it crashes under -nw. Yes, because the call to the font driver should only be done when 'font_object' is a font object (it isn't on TTY frames). Otherwise, simply assign FONT_INVALID_CODE to 'code'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 13:40 ` Eli Zaretskii @ 2020-01-24 13:50 ` Robert Pluim 2020-01-24 15:41 ` Robert Pluim 0 siblings, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-01-24 13:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lg.zevlg, 39133 >>>>> On Fri, 24 Jan 2020 15:40:19 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: Robert Pluim <rpluim@gmail.com> >> Cc: lg.zevlg@gmail.com, 39133@debbugs.gnu.org, >> mituharu@math.s.chiba-u.ac.jp, handa@gnu.org >> Date: Fri, 24 Jan 2020 14:09:22 +0100 >> >> >> Rather than duplicate that code, I moved the FONT_INVALID_CODE check >> >> up. This works for me: >> Eli> Looks reasonable, thanks. >> >> Except it crashes under -nw. Eli> Yes, because the call to the font driver should only be done when Eli> 'font_object' is a font object (it isn't on TTY frames). Otherwise, Eli> simply assign FONT_INVALID_CODE to 'code'. Yes, I worked that out. A simple crash, for once :-) Robert ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 13:50 ` Robert Pluim @ 2020-01-24 15:41 ` Robert Pluim 2020-01-24 15:52 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-01-24 15:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39133, lg.zevlg [-- Attachment #1: Type: text/plain, Size: 146 bytes --] >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim@gmail.com> said: Robert> Yes, I worked that out. A simple crash, for once :-) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Don-t-attempt-to-cache-glyph-metrics-for-FONT_INVALI.patch --] [-- Type: text/x-patch, Size: 3179 bytes --] From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001 From: Robert Pluim <rpluim@gmail.com> Date: Fri, 24 Jan 2020 14:11:44 +0100 Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE This was causing massive slowdown in redisplay when eg #xfe0f (VARIATION SELECTOR-16) was present, as the cache ended up very large, unused, and being recreated on every call to font_fill_lglyph_metrics (Bug#39133). * src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out of loop. Calculate glyph code and check for FONT_INVALID_CODE before calling font_fill_lglyph_metrics. Pass glyph code to it. * src/font.c (font_fill_lglyph_metrics): Add code parameter, move glyph code calculation up the call stack into fill_gstring_body. * src/font.h: Adjust font_fill_lglyph_metrics prototype. --- src/composite.c | 18 ++++++++++++++---- src/font.c | 4 +--- src/font.h | 2 +- 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/src/composite.c b/src/composite.c index 53e6930b5f..364d5c9316 100644 --- a/src/composite.c +++ b/src/composite.c @@ -818,6 +818,11 @@ fill_gstring_body (Lisp_Object gstring) Lisp_Object header = AREF (gstring, 0); ptrdiff_t len = LGSTRING_CHAR_LEN (gstring); ptrdiff_t i; + struct font *font = NULL; + unsigned int code; + + if (FONT_OBJECT_P (font_object)) + font = XFONT_OBJECT (font_object); for (i = 0; i < len; i++) { @@ -832,10 +837,15 @@ fill_gstring_body (Lisp_Object gstring) LGLYPH_SET_FROM (g, i); LGLYPH_SET_TO (g, i); LGLYPH_SET_CHAR (g, c); - if (FONT_OBJECT_P (font_object)) - { - font_fill_lglyph_metrics (g, font_object); - } + + if (font != NULL) + code = font->driver->encode_char (font, LGLYPH_CHAR (g)); + else + code = FONT_INVALID_CODE; + if (code != FONT_INVALID_CODE) + { + font_fill_lglyph_metrics (g, font, code); + } else { int width = XFIXNAT (CHAR_TABLE_REF (Vchar_width_table, c)); diff --git a/src/font.c b/src/font.c index bb39aef92d..2a45630061 100644 --- a/src/font.c +++ b/src/font.c @@ -4416,10 +4416,8 @@ DEFUN ("clear-font-cache", Fclear_font_cache, Sclear_font_cache, 0, 0, 0, \f void -font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object) +font_fill_lglyph_metrics (Lisp_Object glyph, struct font *font, unsigned int code) { - struct font *font = XFONT_OBJECT (font_object); - unsigned code = font->driver->encode_char (font, LGLYPH_CHAR (glyph)); struct font_metrics metrics; LGLYPH_SET_CODE (glyph, code); diff --git a/src/font.h b/src/font.h index 0561e3c83f..8614e7fa10 100644 --- a/src/font.h +++ b/src/font.h @@ -886,7 +886,7 @@ valid_font_driver (struct font_driver const *d) extern Lisp_Object font_range (ptrdiff_t, ptrdiff_t, ptrdiff_t *, struct window *, struct face *, Lisp_Object); -extern void font_fill_lglyph_metrics (Lisp_Object, Lisp_Object); +extern void font_fill_lglyph_metrics (Lisp_Object, struct font *, unsigned int); extern Lisp_Object font_put_extra (Lisp_Object font, Lisp_Object prop, Lisp_Object val); -- 2.23.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 15:41 ` Robert Pluim @ 2020-01-24 15:52 ` Eli Zaretskii 2020-03-02 7:40 ` Robert Pluim 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-01-24 15:52 UTC (permalink / raw) To: Robert Pluim; +Cc: 39133, lg.zevlg > From: Robert Pluim <rpluim@gmail.com> > Cc: 39133@debbugs.gnu.org, lg.zevlg@gmail.com, > mituharu@math.s.chiba-u.ac.jp, handa@gnu.org > Date: Fri, 24 Jan 2020 16:41:40 +0100 > > >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim@gmail.com> said: > Robert> Yes, I worked that out. A simple crash, for once :-) > > >From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001 > From: Robert Pluim <rpluim@gmail.com> > Date: Fri, 24 Jan 2020 14:11:44 +0100 > Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE > > This was causing massive slowdown in redisplay when eg #xfe0f > (VARIATION SELECTOR-16) was present, as the cache ended up very large, > unused, and being recreated on every call to font_fill_lglyph_metrics > (Bug#39133). > > * src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out > of loop. Calculate glyph code and check for FONT_INVALID_CODE before > calling font_fill_lglyph_metrics. Pass glyph code to it. > > * src/font.c (font_fill_lglyph_metrics): Add code parameter, move > glyph code calculation up the call stack into fill_gstring_body. > > * src/font.h: Adjust font_fill_lglyph_metrics prototype. Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-01-24 15:52 ` Eli Zaretskii @ 2020-03-02 7:40 ` Robert Pluim 2020-03-02 8:49 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Robert Pluim @ 2020-03-02 7:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lg.zevlg, 39133 >>>>> On Fri, 24 Jan 2020 17:52:12 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: Robert Pluim <rpluim@gmail.com> >> Cc: 39133@debbugs.gnu.org, lg.zevlg@gmail.com, >> mituharu@math.s.chiba-u.ac.jp, handa@gnu.org >> Date: Fri, 24 Jan 2020 16:41:40 +0100 >> >> >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim@gmail.com> said: Robert> Yes, I worked that out. A simple crash, for once :-) >> >> >From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001 >> From: Robert Pluim <rpluim@gmail.com> >> Date: Fri, 24 Jan 2020 14:11:44 +0100 >> Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE >> >> This was causing massive slowdown in redisplay when eg #xfe0f >> (VARIATION SELECTOR-16) was present, as the cache ended up very large, >> unused, and being recreated on every call to font_fill_lglyph_metrics >> (Bug#39133). >> >> * src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out >> of loop. Calculate glyph code and check for FONT_INVALID_CODE before >> calling font_fill_lglyph_metrics. Pass glyph code to it. >> >> * src/font.c (font_fill_lglyph_metrics): Add code parameter, move >> glyph code calculation up the call stack into fill_gstring_body. >> >> * src/font.h: Adjust font_fill_lglyph_metrics prototype. Eli> Thanks. So Mike Fabian has tested this, and it works for him. Which branch would you like me to push this to? Robert ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-03-02 7:40 ` Robert Pluim @ 2020-03-02 8:49 ` Eli Zaretskii 2020-03-02 9:25 ` Robert Pluim 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-03-02 8:49 UTC (permalink / raw) To: Robert Pluim; +Cc: lg.zevlg, 39133 > From: Robert Pluim <rpluim@gmail.com> > Cc: lg.zevlg@gmail.com, 39133@debbugs.gnu.org, > mituharu@math.s.chiba-u.ac.jp, handa@gnu.org > Date: Mon, 02 Mar 2020 08:40:02 +0100 > > So Mike Fabian has tested this, and it works for him. Which branch > would you like me to push this to? The release branch, please. Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#39133: 28.0.50; Emacs slowdown on special char 2020-03-02 8:49 ` Eli Zaretskii @ 2020-03-02 9:25 ` Robert Pluim 0 siblings, 0 replies; 17+ messages in thread From: Robert Pluim @ 2020-03-02 9:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lg.zevlg, 39133-done >>>>> On Mon, 02 Mar 2020 10:49:33 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: Robert Pluim <rpluim@gmail.com> >> Cc: lg.zevlg@gmail.com, 39133@debbugs.gnu.org, >> mituharu@math.s.chiba-u.ac.jp, handa@gnu.org >> Date: Mon, 02 Mar 2020 08:40:02 +0100 >> >> So Mike Fabian has tested this, and it works for him. Which branch >> would you like me to push this to? Eli> The release branch, please. Done as fe1a447d52 Closing. Robert ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-03-02 9:25 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-14 13:21 bug#39133: 28.0.50; Emacs slowdown on special char Evgeny Zajcev 2020-01-14 15:26 ` Eli Zaretskii 2020-01-14 16:24 ` Robert Pluim 2020-01-15 4:26 ` YAMAMOTO Mitsuharu 2020-01-15 8:25 ` Robert Pluim 2020-01-15 10:47 ` Evgeny Zajcev 2020-01-15 16:19 ` Eli Zaretskii 2020-01-24 10:13 ` Robert Pluim 2020-01-24 10:22 ` Eli Zaretskii 2020-01-24 13:09 ` Robert Pluim 2020-01-24 13:40 ` Eli Zaretskii 2020-01-24 13:50 ` Robert Pluim 2020-01-24 15:41 ` Robert Pluim 2020-01-24 15:52 ` Eli Zaretskii 2020-03-02 7:40 ` Robert Pluim 2020-03-02 8:49 ` Eli Zaretskii 2020-03-02 9:25 ` Robert Pluim
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).