GNU bug report logs -
#39133
28.0.50; Emacs slowdown on special char
Previous Next
Reported by: Evgeny Zajcev <lg.zevlg <at> gmail.com>
Date: Tue, 14 Jan 2020 13:22:02 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 27.1
Done: Robert Pluim <rpluim <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39133 in the body.
You can then email your comments to 39133 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Tue, 14 Jan 2020 13:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Evgeny Zajcev <lg.zevlg <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 14 Jan 2020 13:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Tue, 14 Jan 2020 15:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39133 <at> debbugs.gnu.org (full text, mbox):
> From: Evgeny Zajcev <lg.zevlg <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Tue, 14 Jan 2020 16:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 39133 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Evgeny Zajcev <lg.zevlg <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Wed, 15 Jan 2020 04:27:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 39133 <at> debbugs.gnu.org (full text, mbox):
On Wed, 15 Jan 2020 01:24:05 +0900,
Robert Pluim wrote:
>
> >>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Evgeny Zajcev <lg.zevlg <at> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Wed, 15 Jan 2020 08:27:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 39133 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <mituharu <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Wed, 15 Jan 2020 10:49:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 39133 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
ср, 15 янв. 2020 г. в 11:25, Robert Pluim <rpluim <at> gmail.com>:
> >>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <
> mituharu <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Wed, 15 Jan 2020 16:20:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 39133 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 15 Jan 2020 13:26:11 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> Evgeny Zajcev <lg.zevlg <at> gmail.com>,
> 39133 <at> debbugs.gnu.org, handa <at> 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);
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 10:15:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 39133 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz <at> 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,
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);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 10:24:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 39133 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
> 39133 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com, handa <at> gnu.org
> Date: Fri, 24 Jan 2020 11:13:54 +0100
>
> >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 13:10:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 39133 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 24 Jan 2020 12:22:38 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
>> 39133 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com, handa <at> gnu.org
>> Date: Fri, 24 Jan 2020 11:13:54 +0100
>>
>> >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 13:41:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 39133 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: lg.zevlg <at> gmail.com, 39133 <at> debbugs.gnu.org,
> mituharu <at> math.s.chiba-u.ac.jp, handa <at> 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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 13:51:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 39133 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 24 Jan 2020 15:40:19 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: lg.zevlg <at> gmail.com, 39133 <at> debbugs.gnu.org,
>> mituharu <at> math.s.chiba-u.ac.jp, handa <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 15:42:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 39133 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim <at> gmail.com> said:
Robert> Yes, I worked that out. A simple crash, for once :-)
[0001-Don-t-attempt-to-cache-glyph-metrics-for-FONT_INVALI.patch (text/x-patch, inline)]
From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim <at> 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,
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Fri, 24 Jan 2020 15:53:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 39133 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 39133 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
> mituharu <at> math.s.chiba-u.ac.jp, handa <at> gnu.org
> Date: Fri, 24 Jan 2020 16:41:40 +0100
>
> >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Mon, 02 Mar 2020 07:41:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 39133 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 24 Jan 2020 17:52:12 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: 39133 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
>> mituharu <at> math.s.chiba-u.ac.jp, handa <at> gnu.org
>> Date: Fri, 24 Jan 2020 16:41:40 +0100
>>
>> >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim <at> 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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39133; Package
emacs.
(Mon, 02 Mar 2020 08:50:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 39133 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: lg.zevlg <at> gmail.com, 39133 <at> debbugs.gnu.org,
> mituharu <at> math.s.chiba-u.ac.jp, handa <at> 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.
bug Marked as fixed in versions 27.1.
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 02 Mar 2020 09:26:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Robert Pluim <rpluim <at> gmail.com>:
You have taken responsibility.
(Mon, 02 Mar 2020 09:26:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Evgeny Zajcev <lg.zevlg <at> gmail.com>:
bug acknowledged by developer.
(Mon, 02 Mar 2020 09:26:03 GMT)
Full text and
rfc822 format available.
Message #57 received at 39133-done <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 02 Mar 2020 10:49:33 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: lg.zevlg <at> gmail.com, 39133 <at> debbugs.gnu.org,
>> mituharu <at> math.s.chiba-u.ac.jp, handa <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 30 Mar 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.