bug#19266: 24.4; Font-related window redrawing delays on OS X

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: bugreport.txt --]
[-- Type: text/plain, Size: 35326 bytes --]

[This is a copy of this question on Emacs.SE:
http://emacs.stackexchange.com/questions/4061]
At least one other person has the same problem.

Often when I'm editing a file with many uncommon unicode symbols (e.g.,
in languages like haskell, julia or c++), and (I think) especially with
an ornate color theme, I experience delays of maybe about five seconds
when switching between buffers. Running emacs under lldb show a stack
trace below; I get a similar stack trace from running `emacs -Q` and
typing `C-h h` (`view-hello-file`), which takes quite a while to display
the hello file.

What can I do about these window redrawing delays? I am not sure what I
have misconfigured.

Does emacs reload all fonts every time I switch to a different frame or
buffer? It also seems to have a delay sometimes when a previously
invisible overlay is shown.

Also related is that fontd CPU usage spikes during the delay.

I'm using `OS X 10.9.5` with emacs compiled from source

    GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)

but I've had this problem with git development version as well some time ago.

Stack trace from `-Q`. This is similar to the one below from regular
emacs use, so I suspect the slowness of `view-hello-file` is related.

* thread #1: tid = 0xfc87d, 0x00007fff86f26a1a
libsystem_kernel.dylib`mach_msg_trap + 10, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff86f26a1a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff86f25d18 libsystem_kernel.dylib`mach_msg + 64
    frame #2: 0x00007fff91f0c78d
libFontRegistry.dylib`XTSendCopyPropertyForFonts + 227
    frame #3: 0x00007fff91f2987c
libFontRegistry.dylib`TGlobalFontRegistryImp::CopyPropertyForFonts(__CFArray
const*, __CFString const*, TFontQueryOptions const&) const + 292
    frame #4: 0x00007fff91f0c16f
libFontRegistry.dylib`XTCopyPropertyForFonts + 115
    frame #5: 0x00007fff86e20817
CoreText`TBaseFont::CreateTraitsValuesPerFontInfo() const + 143
    frame #6: 0x00007fff86e2068f
CoreText`TBaseFont::CopyTraitsInternal() const + 87
    frame #7: 0x00007fff86e22e81
CoreText`TBaseFont::CreateTraitsValues() const + 29
    frame #8: 0x00007fff86e22e49
CoreText`TBaseFont::GetSymbolicTraitsInternal() const + 21
    frame #9: 0x00007fff86e22e17
CoreText`TBaseFont::GetSymbolicTraits(bool) const + 17
    frame #10: 0x00007fff86e7fe63
CoreText`CompareLocalizedDescriptorsByTraitsAndPrecedence(void const*,
void const*, void*, bool, bool) + 353
    frame #11: 0x00007fff92040547 CoreFoundation`__CFSimpleMergeSort + 455
    frame #12: 0x00007fff9204034b CoreFoundation`CFSortIndexes + 443
    frame #13: 0x00007fff92040048 CoreFoundation`CFQSortArray + 232
    frame #14: 0x00007fff9203fefe CoreFoundation`CFArraySortValues + 1054
    frame #15: 0x00007fff86e7f008
CoreText`TDescriptorSource::CopyAllDescriptorsInternal(bool,
CFComparisonResult (*)(void const*, void const*, void*)) const + 186
    frame #16: 0x00007fff86e7f142
CoreText`TDescriptorSource::CopyAllDescriptorsSorted() const + 26
    frame #17: 0x00007fff86e25bfd
CoreText`TDescriptor::CreateMatchingDescriptors(__CFSet const*,
unsigned long) const + 249
    frame #18: 0x00007fff86e6bf36
CoreText`CTFontDescriptorCreateMatchingFontDescriptors + 87
    frame #19: 0x00007fff8b55c521 AppKit`-[NSCTFontDescriptor
matchingFontDescriptorsWithMandatoryKeys:] + 12
    frame #20: 0x00000001001c5d60
Emacs`ns_findfonts(font_spec=4345331237, isMatch='\0') + 1600 at
nsfont.m:564
    frame #21: 0x000000010014ab10
Emacs`font_list_entities(f=0x000000010282b648, spec=4330619989) + 720
at font.c:2759
    frame #22: 0x000000010014cc33
Emacs`font_find_for_lface(f=0x000000010282b648,
attrs=0x00000001077b2780, spec=<unavailable>, c=-1) + 1971 at
font.c:3235
    frame #23: 0x00000001001985bb
Emacs`fontset_find_font(fontset=4329826901, c=3626,
face=0x00000001077b2780, id=<unavailable>, fallback=false) + 1755 at
fontset.c:636
    frame #24: 0x0000000100194f13
Emacs`fontset_font(fontset=4339946117, c=3626,
face=0x00000001077b2780, id=38) + 323 at fontset.c:754
    frame #25: 0x0000000100194d41
Emacs`face_for_char(f=0x000000010282b648, face=0x00000001077b2780,
c=3626, pos=<unavailable>, object=<unavailable>) + 337 at
fontset.c:956
    frame #26: 0x000000010001b19b
Emacs`get_next_display_element(it=<unavailable>) + 2907 at
xdisp.c:7193
    frame #27: 0x00000001000284d8
Emacs`display_line(it=0x00007fff5fbf76c8) + 1304 at xdisp.c:20183
    frame #28: 0x0000000100027de6
Emacs`try_window(window=<unavailable>, flags=1, pos=<unavailable>) +
214 at xdisp.c:16972
    frame #29: 0x000000010004bb43
Emacs`redisplay_window(window=4337071693, just_this_one_p=false) +
13651 at xdisp.c:16451
    frame #30: 0x00000001000524f6
Emacs`redisplay_window_0(window=<unavailable>) + 38 at xdisp.c:14348
    frame #31: 0x0000000100138b34
Emacs`internal_condition_case_1(bfun=0x00000001000524d0,
arg=4337071693, handlers=<unavailable>, hfun=<unavailable>) + 260 at
eval.c:1372
    frame #32: 0x0000000100048554
Emacs`redisplay_windows(window=<unavailable>) + 180 at xdisp.c:14328
    frame #33: 0x0000000100048512
Emacs`redisplay_windows(window=<unavailable>) + 114 at xdisp.c:14322
    frame #34: 0x0000000100026938 Emacs`redisplay_internal + 6184 at
xdisp.c:13927
    frame #35: 0x00000001000c1a5e Emacs`read_char(commandflag=1,
map=4329109910, prev_event=4328534074,
used_mouse_menu=0x00007fff5fbff31f, end_time=0x0000000000000000) +
1982 at keyboard.c:2570
    frame #36: 0x00000001000bf0dc
Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>,
prompt=<unavailable>, dont_downcase_last=<unavailable>,
can_return_switch_frame=<unavailable>,
fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) +
1964 at keyboard.c:9088
    frame #37: 0x00000001000be6f0 Emacs`command_loop_1 + 4736 at keyboard.c:1452
    frame #38: 0x0000000100138a1b
Emacs`internal_condition_case(bfun=0x00000001000bd470,
handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1348
    frame #39: 0x00000001000ceb6e
Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
    frame #40: 0x00000001001383a3
Emacs`internal_catch(tag=<unavailable>, func=0x00000001000ceb30,
arg=4328534074) + 243 at eval.c:1112
    frame #41: 0x00000001000bcaad Emacs`recursive_edit_1 [inlined]
command_loop + 68 at keyboard.c:1156
    frame #42: 0x00000001000bca69 Emacs`recursive_edit_1 + 265 at keyboard.c:777
    frame #43: 0x00000001000bcbf2 Emacs`Frecursive_edit + 242 at keyboard.c:848
    frame #44: 0x00000001000bb7da Emacs`main(argc=0,
argv=<unavailable>) + 5850 at emacs.c:1646

Stack trace from regular emacs use:

* thread #1: tid = 0xd3a52, 0x00007fff86f2a5da
libsystem_kernel.dylib`__open + 10, queue = 'com.apple.main-thread',
stop reason = signal SIGSTOP
  * frame #0: 0x00007fff86f2a5da libsystem_kernel.dylib`__open + 10
    frame #1: 0x00007fff8c6ec4f7
libFontParser.dylib`TFileDescriptorContext::TFileDescriptorContext(char
const*) + 67
    frame #2: 0x00007fff8c6ec2f5
libFontParser.dylib`TFileDataReference::TFileDataReference(char
const*) + 117
    frame #3: 0x00007fff8c6ec0fc
libFontParser.dylib`TFileDataSurrogate::TFileDataSurrogate(char
const*, bool) + 142
    frame #4: 0x00007fff8c6eaa3b
libFontParser.dylib`TFont::CreateFontEntitiesForFile(char const*,
bool, TSimpleArray<TFont*>&, bool, short, char const*) + 1847
    frame #5: 0x00007fff8c6e9e1f
libFontParser.dylib`FPFontCreateFontsWithPath + 253
    frame #6: 0x00007fff9190b1f4
libCGXType.A.dylib`create_private_data_with_path + 19
    frame #7: 0x00007fff8df42185 CoreGraphics`CGFontCreateFontsWithPath + 40
    frame #8: 0x00007fff8df41d9a CoreGraphics`CGFontCreateFontsWithURL + 383
    frame #9: 0x00007fff86e0f2ec
CoreText`CreateFontWithFontURL(__CFURL const*, bool) + 60
    frame #10: 0x00007fff86e0f10b
CoreText`TCGFontCache::CopyFont(__CFURL const*, bool) const + 91
    frame #11: 0x00007fff86e0ef35 CoreText`TBaseFont::CopyNativeFont()
const + 69
    frame #12: 0x00007fff86e0eeb6
CoreText`TBaseFont::CopyGraphicsFont() const + 26
    frame #13: 0x00007fff86e14a6b
CoreText`TBaseFont::CopyAvailableTables(unsigned int) const + 31
    frame #14: 0x00007fff86e1471b CoreText`TBaseFont::GetFormat() const + 249
    frame #15: 0x00007fff86e7713b CoreText`TBaseFont::CopyFormat() const + 21
    frame #16: 0x00007fff86e2039a
CoreText`TBaseFont::CopyAttribute(unsigned long) const + 874
    frame #17: 0x00007fff86e0e291
CoreText`TDescriptor::CopyAttribute(__CFString const*) const + 175
    frame #18: 0x00007fff86e0e1bf CoreText`CTFontDescriptorCopyAttribute + 99
    frame #19: 0x00000001001c6f1a Emacs`macfont_list(f=<unavailable>,
spec=4345331237) + 2986 at macfont.m:2313
    frame #20: 0x000000010014ab10
Emacs`font_list_entities(f=0x000000010104f248, spec=4782535053) + 720
at font.c:2759
    frame #21: 0x000000010014cc33
Emacs`font_find_for_lface(f=0x000000010104f248,
attrs=0x000000010d1adb60, spec=<unavailable>, c=949) + 1971 at
font.c:3235
    frame #22: 0x0000000100198711
Emacs`fontset_find_font(fontset=4325821517, c=<unavailable>,
face=0x000000010d1adb60, id=<unavailable>, fallback=false) + 2097 at
fontset.c:681
    frame #23: 0x0000000100194f13
Emacs`fontset_font(fontset=4440753229, c=949, face=0x000000010d1adb60,
id=-1) + 323 at fontset.c:754
    frame #24: 0x0000000100194d41
Emacs`face_for_char(f=0x000000010104f248, face=0x000000010d1adb60,
c=949, pos=<unavailable>, object=<unavailable>) + 337 at fontset.c:956
    frame #25: 0x000000010001b19b
Emacs`get_next_display_element(it=<unavailable>) + 2907 at
xdisp.c:7193
    frame #26: 0x000000010002d4cf
Emacs`display_string(string=<unavailable>, lisp_string=<unavailable>,
face_string=<unavailable>, face_string_pos=<unavailable>,
start=<unavailable>, it=0x00007fff5fbf7678, field_width=<unavailable>,
precision=<unavailable>, max_x=<unavailable>, multibyte=<unavailable>)
+ 1599 at xdisp.c:23391
    frame #27: 0x00000001000303fb
Emacs`display_mode_element(it=0x00007fff5fbf7678, depth=<unavailable>,
field_width=<unavailable>, precision=<unavailable>, elt=<unavailable>,
props=<unavailable>, risky=1) + 9115 at xdisp.c:21980
    frame #28: 0x000000010002e428
Emacs`display_mode_element(it=<unavailable>, depth=<unavailable>,
field_width=<unavailable>, precision=<unavailable>, elt=<unavailable>,
props=4328534074, risky=1) + 968 at xdisp.c:22274
    frame #29: 0x000000010002e428
Emacs`display_mode_element(it=<unavailable>, depth=<unavailable>,
field_width=<unavailable>, precision=<unavailable>, elt=<unavailable>,
props=4328534074, risky=1) + 968 at xdisp.c:22274
    frame #30: 0x0000000100019df2
Emacs`display_mode_line(w=<unavailable>, face_id=MODE_LINE_FACE_ID,
format=4322675206) + 402 at xdisp.c:21791
    frame #31: 0x0000000100050ac7
Emacs`display_mode_lines(w=0x0000000101046248) + 359 at xdisp.c:21734
    frame #32: 0x0000000100049c1a
Emacs`redisplay_window(window=4312031821, just_this_one_p=false) +
5674 at xdisp.c:16804
    frame #33: 0x00000001000524f6
Emacs`redisplay_window_0(window=<unavailable>) + 38 at xdisp.c:14348
    frame #34: 0x0000000100138b34
Emacs`internal_condition_case_1(bfun=0x00000001000524d0,
arg=4312031821, handlers=<unavailable>, hfun=<unavailable>) + 260 at
eval.c:1372
    frame #35: 0x0000000100048554
Emacs`redisplay_windows(window=<unavailable>) + 180 at xdisp.c:14328
    frame #36: 0x0000000100048512
Emacs`redisplay_windows(window=<unavailable>) + 114 at xdisp.c:14322
    frame #37: 0x0000000100026938 Emacs`redisplay_internal + 6184 at
xdisp.c:13927
    frame #38: 0x00000001000c1a5e Emacs`read_char(commandflag=1,
map=4326491702, prev_event=4328534074,
used_mouse_menu=0x00007fff5fbff31f, end_time=0x0000000000000000) +
1982 at keyboard.c:2570
    frame #39: 0x00000001000bf0dc
Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>,
prompt=<unavailable>, dont_downcase_last=<unavailable>,
can_return_switch_frame=<unavailable>,
fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) +
1964 at keyboard.c:9088
    frame #40: 0x00000001000be6f0 Emacs`command_loop_1 + 4736 at keyboard.c:1452
    frame #41: 0x0000000100138a1b
Emacs`internal_condition_case(bfun=0x00000001000bd470,
handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1348
    frame #42: 0x00000001000ceb6e
Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
    frame #43: 0x00000001001383a3
Emacs`internal_catch(tag=<unavailable>, func=0x00000001000ceb30,
arg=4328534074) + 243 at eval.c:1112
    frame #44: 0x00000001000bcaad Emacs`recursive_edit_1 [inlined]
command_loop + 68 at keyboard.c:1156
    frame #45: 0x00000001000bca69 Emacs`recursive_edit_1 + 265 at keyboard.c:777
    frame #46: 0x00000001000bcbf2 Emacs`Frecursive_edit + 242 at keyboard.c:848
    frame #47: 0x00000001000bb7da Emacs`main(argc=0,
argv=<unavailable>) + 5850 at emacs.c:1646



In GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
 of 2014-10-20 on user209-131.wireless.utoronto.ca
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --with-ns CPPFLAGS=-I/sw/include LDFLAGS=-L/sw/lib'

Important settings:
  value of $LANG: en_IE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  electric-pair-mode: t
  winner-mode: t
  shell-dirtrack-mode: t
  global-company-mode: t
  company-mode: t
  pyvenv-mode: t
  projectile-global-mode: t
  projectile-mode: t
  hli-minor-mode: t
  highlight-fixme-minor-mode: t
  global-flycheck-mode: t
  flx-ido-mode: t
  ido-everywhere: t
  show-paren-mode: t
  display-time-mode: t
  override-global-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent input:
C-h h C-n C-p C-n C-p C-n C-p C-n C-p C-n C-p C-n C-p
M-> M-< M-x e m a c s SPC r e <tab> <M-backspace> <M-backspace>
r e p o r t <tab> <tab> <return>

Recent messages:
[yas] Prepared just-in-time loading for ~/.emacs.d/snippets
[yas] Reloaded everything (snippets will load just-in-time)....
Loading /Users/kirill/Sandboxes/git/haskell-mode/haskell-mode-autoloads.el
(source)...
[yas] Loading compiled snippets from
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/snippets/haskell-mode
Loading /Users/kirill/Sandboxes/git/haskell-mode/haskell-mode-autoloads.el
(source)...done
[sml] sml/theme set to automatic
dot-emacs takes 14.186 seconds to load.
For information about GNU Emacs and the GNU system, type C-h C-a.
View mode: type C-h for help, h for commands, q to quit.
Quit

Load-path shadows:
~/Sandboxes/git/haskell-mode/w3m-haddock hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/w3m-haddock
~/Sandboxes/git/haskell-mode/inf-haskell hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/inf-haskell
~/Sandboxes/git/haskell-mode/haskell-yas hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-yas
~/Sandboxes/git/haskell-mode/haskell-utils hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-utils
~/Sandboxes/git/haskell-mode/haskell-unicode-input-method hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-unicode-input-method
~/Sandboxes/git/haskell-mode/haskell-string hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-string
~/Sandboxes/git/haskell-mode/haskell-str hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-str
~/Sandboxes/git/haskell-mode/haskell-sort-imports hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-sort-imports
~/Sandboxes/git/haskell-mode/haskell-simple-indent hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-simple-indent
~/Sandboxes/git/haskell-mode/haskell-show hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-show
~/Sandboxes/git/haskell-mode/haskell-session hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-session
~/Sandboxes/git/haskell-mode/haskell-process hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-process
~/Sandboxes/git/haskell-mode/haskell-presentation-mode hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-presentation-mode
~/Sandboxes/git/haskell-mode/haskell-package hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-package
~/Sandboxes/git/haskell-mode/haskell-navigate-imports hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-navigate-imports
~/Sandboxes/git/haskell-mode/haskell-move-nested hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-move-nested
~/Sandboxes/git/haskell-mode/haskell-mode hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-mode
~/Sandboxes/git/haskell-mode/haskell-mode-autoloads hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-mode-autoloads
~/Sandboxes/git/haskell-mode/haskell-menu hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-menu
~/Sandboxes/git/haskell-mode/haskell-interactive-mode hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-interactive-mode
~/Sandboxes/git/haskell-mode/haskell-indentation hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-indentation
~/Sandboxes/git/haskell-mode/haskell-indent hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-indent
~/Sandboxes/git/haskell-mode/haskell-font-lock hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-font-lock
~/Sandboxes/git/haskell-mode/haskell-doc hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-doc
~/Sandboxes/git/haskell-mode/haskell-decl-scan hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-decl-scan
~/Sandboxes/git/haskell-mode/haskell-debug hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-debug
~/Sandboxes/git/haskell-mode/haskell-complete-module hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-complete-module
~/Sandboxes/git/haskell-mode/haskell-compile hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-compile
~/Sandboxes/git/haskell-mode/haskell-compat hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-compat
~/Sandboxes/git/haskell-mode/haskell-collapse hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-collapse
~/Sandboxes/git/haskell-mode/haskell-checkers hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-checkers
~/Sandboxes/git/haskell-mode/haskell-cabal hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-cabal
~/Sandboxes/git/haskell-mode/haskell-c hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-c
~/Sandboxes/git/haskell-mode/haskell-bot hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-bot
~/Sandboxes/git/haskell-mode/haskell-align-imports hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/haskell-align-imports
~/Sandboxes/git/haskell-mode/ghc-core hides
/Users/kirill/.emacs.d/elpa/haskell-mode-20141130.1012/ghc-core
/Users/kirill/.emacs.d/elpa/glsl-mode-20140930.1148/glsl-mode hides
~/.emacs.d/lisp/glsl-mode
~/.emacs.d/ikirill/custom hides
/Applications/Emacs.app/Contents/Resources/lisp/custom
/Users/kirill/.emacs.d/elpa/org-20141201/ox hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox
/Users/kirill/.emacs.d/elpa/org-20141201/ox-texinfo hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-texinfo
/Users/kirill/.emacs.d/elpa/org-20141201/ox-publish hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-publish
/Users/kirill/.emacs.d/elpa/org-20141201/ox-org hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-org
/Users/kirill/.emacs.d/elpa/org-20141201/ox-odt hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-odt
/Users/kirill/.emacs.d/elpa/org-20141201/ox-md hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-md
/Users/kirill/.emacs.d/elpa/org-20141201/ox-man hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-man
/Users/kirill/.emacs.d/elpa/org-20141201/ox-latex hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-latex
/Users/kirill/.emacs.d/elpa/org-20141201/ox-icalendar hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-icalendar
/Users/kirill/.emacs.d/elpa/org-20141201/ox-html hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-html
/Users/kirill/.emacs.d/elpa/org-20141201/ox-beamer hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-beamer
/Users/kirill/.emacs.d/elpa/org-20141201/ox-ascii hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ox-ascii
/Users/kirill/.emacs.d/elpa/org-20141201/org hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org
/Users/kirill/.emacs.d/elpa/org-20141201/org-w3m hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-w3m
/Users/kirill/.emacs.d/elpa/org-20141201/org-version hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-version
/Users/kirill/.emacs.d/elpa/org-20141201/org-timer hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-timer
/Users/kirill/.emacs.d/elpa/org-20141201/org-table hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-table
/Users/kirill/.emacs.d/elpa/org-20141201/org-src hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-src
/Users/kirill/.emacs.d/elpa/org-20141201/org-rmail hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-rmail
/Users/kirill/.emacs.d/elpa/org-20141201/org-protocol hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-protocol
/Users/kirill/.emacs.d/elpa/org-20141201/org-plot hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-plot
/Users/kirill/.emacs.d/elpa/org-20141201/org-pcomplete hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-pcomplete
/Users/kirill/.emacs.d/elpa/org-20141201/org-mouse hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-mouse
/Users/kirill/.emacs.d/elpa/org-20141201/org-mobile hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-mobile
/Users/kirill/.emacs.d/elpa/org-20141201/org-mhe hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-mhe
/Users/kirill/.emacs.d/elpa/org-20141201/org-macs hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-macs
/Users/kirill/.emacs.d/elpa/org-20141201/org-macro hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-macro
/Users/kirill/.emacs.d/elpa/org-20141201/org-loaddefs hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-loaddefs
/Users/kirill/.emacs.d/elpa/org-20141201/org-list hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-list
/Users/kirill/.emacs.d/elpa/org-20141201/org-irc hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-irc
/Users/kirill/.emacs.d/elpa/org-20141201/org-install hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-install
/Users/kirill/.emacs.d/elpa/org-20141201/org-inlinetask hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-inlinetask
/Users/kirill/.emacs.d/elpa/org-20141201/org-info hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-info
/Users/kirill/.emacs.d/elpa/org-20141201/org-indent hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-indent
/Users/kirill/.emacs.d/elpa/org-20141201/org-id hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-id
/Users/kirill/.emacs.d/elpa/org-20141201/org-habit hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-habit
/Users/kirill/.emacs.d/elpa/org-20141201/org-gnus hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-gnus
/Users/kirill/.emacs.d/elpa/org-20141201/org-footnote hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-footnote
/Users/kirill/.emacs.d/elpa/org-20141201/org-feed hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-feed
/Users/kirill/.emacs.d/elpa/org-20141201/org-faces hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-faces
/Users/kirill/.emacs.d/elpa/org-20141201/org-eshell hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-eshell
/Users/kirill/.emacs.d/elpa/org-20141201/org-entities hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-entities
/Users/kirill/.emacs.d/elpa/org-20141201/org-element hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-element
/Users/kirill/.emacs.d/elpa/org-20141201/org-docview hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-docview
/Users/kirill/.emacs.d/elpa/org-20141201/org-datetree hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-datetree
/Users/kirill/.emacs.d/elpa/org-20141201/org-ctags hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-ctags
/Users/kirill/.emacs.d/elpa/org-20141201/org-crypt hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-crypt
/Users/kirill/.emacs.d/elpa/org-20141201/org-compat hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-compat
/Users/kirill/.emacs.d/elpa/org-20141201/org-colview hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-colview
/Users/kirill/.emacs.d/elpa/org-20141201/org-clock hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-clock
/Users/kirill/.emacs.d/elpa/org-20141201/org-capture hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-capture
/Users/kirill/.emacs.d/elpa/org-20141201/org-bibtex hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-bibtex
/Users/kirill/.emacs.d/elpa/org-20141201/org-bbdb hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-bbdb
/Users/kirill/.emacs.d/elpa/org-20141201/org-attach hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-attach
/Users/kirill/.emacs.d/elpa/org-20141201/org-archive hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-archive
/Users/kirill/.emacs.d/elpa/org-20141201/org-agenda hides
/Applications/Emacs.app/Contents/Resources/lisp/org/org-agenda
/Users/kirill/.emacs.d/elpa/org-20141201/ob hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob
/Users/kirill/.emacs.d/elpa/org-20141201/ob-tangle hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-tangle
/Users/kirill/.emacs.d/elpa/org-20141201/ob-table hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-table
/Users/kirill/.emacs.d/elpa/org-20141201/ob-sqlite hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-sqlite
/Users/kirill/.emacs.d/elpa/org-20141201/ob-sql hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-sql
/Users/kirill/.emacs.d/elpa/org-20141201/ob-shen hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-shen
/Users/kirill/.emacs.d/elpa/org-20141201/ob-sh hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-sh
/Users/kirill/.emacs.d/elpa/org-20141201/ob-screen hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-screen
/Users/kirill/.emacs.d/elpa/org-20141201/ob-scheme hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-scheme
/Users/kirill/.emacs.d/elpa/org-20141201/ob-scala hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-scala
/Users/kirill/.emacs.d/elpa/org-20141201/ob-sass hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-sass
/Users/kirill/.emacs.d/elpa/org-20141201/ob-ruby hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-ruby
/Users/kirill/.emacs.d/elpa/org-20141201/ob-ref hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-ref
/Users/kirill/.emacs.d/elpa/org-20141201/ob-R hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-R
/Users/kirill/.emacs.d/elpa/org-20141201/ob-python hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-python
/Users/kirill/.emacs.d/elpa/org-20141201/ob-plantuml hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-plantuml
/Users/kirill/.emacs.d/elpa/org-20141201/ob-picolisp hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-picolisp
/Users/kirill/.emacs.d/elpa/org-20141201/ob-perl hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-perl
/Users/kirill/.emacs.d/elpa/org-20141201/ob-org hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-org
/Users/kirill/.emacs.d/elpa/org-20141201/ob-octave hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-octave
/Users/kirill/.emacs.d/elpa/org-20141201/ob-ocaml hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-ocaml
/Users/kirill/.emacs.d/elpa/org-20141201/ob-mscgen hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-mscgen
/Users/kirill/.emacs.d/elpa/org-20141201/ob-maxima hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-maxima
/Users/kirill/.emacs.d/elpa/org-20141201/ob-matlab hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-matlab
/Users/kirill/.emacs.d/elpa/org-20141201/ob-makefile hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-makefile
/Users/kirill/.emacs.d/elpa/org-20141201/ob-lob hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-lob
/Users/kirill/.emacs.d/elpa/org-20141201/ob-lisp hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-lisp
/Users/kirill/.emacs.d/elpa/org-20141201/ob-lilypond hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-lilypond
/Users/kirill/.emacs.d/elpa/org-20141201/ob-ledger hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-ledger
/Users/kirill/.emacs.d/elpa/org-20141201/ob-latex hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-latex
/Users/kirill/.emacs.d/elpa/org-20141201/ob-keys hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-keys
/Users/kirill/.emacs.d/elpa/org-20141201/ob-js hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-js
/Users/kirill/.emacs.d/elpa/org-20141201/ob-java hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-java
/Users/kirill/.emacs.d/elpa/org-20141201/ob-io hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-io
/Users/kirill/.emacs.d/elpa/org-20141201/ob-haskell hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-haskell
/Users/kirill/.emacs.d/elpa/org-20141201/ob-gnuplot hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/kirill/.emacs.d/elpa/org-20141201/ob-fortran hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-fortran
/Users/kirill/.emacs.d/elpa/org-20141201/ob-exp hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-exp
/Users/kirill/.emacs.d/elpa/org-20141201/ob-eval hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-eval
/Users/kirill/.emacs.d/elpa/org-20141201/ob-emacs-lisp hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/kirill/.emacs.d/elpa/org-20141201/ob-dot hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-dot
/Users/kirill/.emacs.d/elpa/org-20141201/ob-ditaa hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-ditaa
/Users/kirill/.emacs.d/elpa/org-20141201/ob-css hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-css
/Users/kirill/.emacs.d/elpa/org-20141201/ob-core hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-core
/Users/kirill/.emacs.d/elpa/org-20141201/ob-comint hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-comint
/Users/kirill/.emacs.d/elpa/org-20141201/ob-clojure hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-clojure
/Users/kirill/.emacs.d/elpa/org-20141201/ob-calc hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-calc
/Users/kirill/.emacs.d/elpa/org-20141201/ob-C hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-C
/Users/kirill/.emacs.d/elpa/org-20141201/ob-awk hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-awk
/Users/kirill/.emacs.d/elpa/org-20141201/ob-asymptote hides
/Applications/Emacs.app/Contents/Resources/lisp/org/ob-asymptote

Features:
(shadow sort elec-pair superword subword mail-extr emacsbug message
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mail-utils thai-util thai-word lao-util view company-files
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-capf company-cmake
company-ropemacs company-xcode company-clang company-semantic
company-eclim company-template company-css company-nxml company-bbdb
company-irony irony-completion irony-snippet irony custom-init winner
exec-path-from-shell my-default-theme server my-skeletons
custom-remote-compile shell-help custom-julia tramp tramp-compat
auth-source eieio eieio-core gnus-util mm-util mail-prsvr password-cache
tramp-loaddefs trampver ess-toolbar ess-mouse mouseme browse-url
ess-menu ess-swv ess-noweb ess-noweb-font-lock-mode ess-bugs-l essd-els
ess-sas-d ess-sas-l ess-sas-a shell pcomplete ess-sta-d ess-sta-l
cc-vars cc-defs make-regexp ess-sp6-d ess-sp3-d ess-julia ess-r-d
ess-tracebug format-spec ess-roxy hideshow ess-help ess-developer
ess-r-args ess-s-l ess ess-inf ess-mode ess-noweb-mode ess-utils
ess-custom executable ess-compat ess-site custom-abbrev custom-org
custom-elisp highlight-parentheses paredit custom-haskell
haskell-mode-autoloads custom-python highlight-indentation flymake eldoc
company elpy pyvenv elpy-refactor derived python json files-x etags
cus-edit wid-edit cl-macs projectile ibuf-ext ibuffer pkg-info lisp-mnt
epl grep compile comint ring f s ucs-normalize thingatpt
smart-mode-line-light-theme rich-minority smart-mode-line mule-util
ikirill-deftheme-help hexrgb ikirill-custom-frame-sizes
ikirill-custom-buffer-window-frame ikirill-custom-themes-faces-fonts
my-special-symbols hli-minor-mode hl-indent-mode face-remap
highlight-fixme ikirill-custom-c++ hl-fold-mode flycheck find-func rx
pcase subr-x dash windmove screenshot-deftheme ikirill-count-words
custom-cuda rainbow-mode ansi-color color fold hungry-delete flx-ido
byte-opt advice help-fns flx ido window+ haskell-yas yasnippet help-mode
cl gv paren hl-line time cus-start cus-load use-package diminish
bytecomp byte-compile cconv bind-key easy-mmode tex-site charmap
ctags-autoloads ctags-update-autoloads ess-R-data-view-autoloads
ess-R-object-popup-autoloads flymake-haskell-multi-autoloads edmacro
kmacro cl-loaddefs cl-lib latex-pretty-symbols-autoloads slime-autoloads
info easymenu package epg-config time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
cocoa ns multi-tty emacs)

Memory information:
((conses 16 471282 9736)
 (symbols 48 48111 6)
 (miscs 40 137 834)
 (strings 32 96176 13657)
 (string-bytes 1 2486813)
 (vectors 16 51494)
 (vector-slots 8 911711 81461)
 (floats 8 440 19)
 (intervals 56 384 0)
 (buffers 960 14))

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> Date: Thu, 4 Dec 2014 02:13:30 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> 
> [This is a copy of this question on Emacs.SE:
> http://emacs.stackexchange.com/questions/4061]
> At least one other person has the same problem.

Please ask those persons to report here directly, and to read the
responses and discussions.

> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
> in languages like haskell, julia or c++), and (I think) especially with
> an ornate color theme, I experience delays of maybe about five seconds
> when switching between buffers. Running emacs under lldb show a stack
> trace below; I get a similar stack trace from running `emacs -Q` and
> typing `C-h h` (`view-hello-file`), which takes quite a while to display
> the hello file.

AFAICT, these delays are due to Emacs searching the system for
appropriate fonts needed to display those unusual symbols.

> What can I do about these window redrawing delays? I am not sure what I
> have misconfigured.

Optimize your font configuration, so that the font search becomes
faster.

> Does emacs reload all fonts every time I switch to a different frame or
> buffer? It also seems to have a delay sometimes when a previously
> invisible overlay is shown.

Emacs only looks for a font when it needs to display something.  when
previously invisible portion is about to be displayed, Emacs needs the
fonts to display it.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

On 4 December 2014 at 02:30, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 4 Dec 2014 02:13:30 -0500
>> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
>>
>> [This is a copy of this question on Emacs.SE:
>> http://emacs.stackexchange.com/questions/4061]
>> At least one other person has the same problem.
>
> Please ask those persons to report here directly, and to read the
> responses and discussions.
>
>> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
>> in languages like haskell, julia or c++), and (I think) especially with
>> an ornate color theme, I experience delays of maybe about five seconds
>> when switching between buffers. Running emacs under lldb show a stack
>> trace below; I get a similar stack trace from running `emacs -Q` and
>> typing `C-h h` (`view-hello-file`), which takes quite a while to display
>> the hello file.
>
> AFAICT, these delays are due to Emacs searching the system for
> appropriate fonts needed to display those unusual symbols.

I understand that this needs to happen once. Is it reasonable that the
delay happens many times during normal editing?

The description of what triggers the delays is unclear because for me
it's only reproducible incidentally, during normal work. I have
fold-mode that hides large portions of text, and a number of frames.
If I hide some previously-displayed text, go work in another frame,
then come back and unhide the text, then there is the font-searching
delay. Something similar happens if I switch to a different buffer,
then some time later switch back.

>> What can I do about these window redrawing delays? I am not sure what I
>> have misconfigured.
>
> Optimize your font configuration, so that the font search becomes
> faster.
>
>> Does emacs reload all fonts every time I switch to a different frame or
>> buffer? It also seems to have a delay sometimes when a previously
>> invisible overlay is shown.
>
> Emacs only looks for a font when it needs to display something.  when
> previously invisible portion is about to be displayed, Emacs needs the
> fonts to display it.

The reason I suspect this may be an actual bug is not that the delay
happens at all, but rather that it happens quite often, and the text
that causes the search for fonts used to be displayed only a short
time ago.

That said, I'm not familiar with how emacs manages fonts. Is it
reasonable to expect to keep all recently used fonts in memory and not
search for them again?

Thanks for the very quick reply.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> Date: Thu, 4 Dec 2014 02:41:34 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> Cc: 19266@debbugs.gnu.org
> 
> > AFAICT, these delays are due to Emacs searching the system for
> > appropriate fonts needed to display those unusual symbols.
> 
> I understand that this needs to happen once.

It can happen once for each portion of a buffer that was not yet
displayed.

> The description of what triggers the delays is unclear because for me
> it's only reproducible incidentally, during normal work. I have
> fold-mode that hides large portions of text, and a number of frames.
> If I hide some previously-displayed text, go work in another frame,
> then come back and unhide the text, then there is the font-searching
> delay. Something similar happens if I switch to a different buffer,
> then some time later switch back.

Emacs releases unused font slots from time to time, which might be the
reason here.

But this is speculation; a reproducible recipe is required to
investigate and come up with specifics.  And yes, it could be a bug.

> Is it reasonable to expect to keep all recently used fonts in memory
> and not search for them again?

For some value of "recently", yes.  Again, more data is needed to
determine whether this is an Emacs bug or a system configuration
issue.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On 4 December 2014 at 03:03, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 4 Dec 2014 02:41:34 -0500
>> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
>> Cc: 19266@debbugs.gnu.org
>
> Emacs releases unused font slots from time to time, which might be the
> reason here.
>
> But this is speculation; a reproducible recipe is required to
> investigate and come up with specifics.  And yes, it could be a bug.

Okay, here's one attempt to reproduce it (sorry about the length). The
idea is to view lots of files, then later viewing a buffer that was
previously displayed causes a delay.

1. Start with -Q.
2. Open file uncommon_symbols.txt (attached). There's a delay but it opens fine.
3. Select the entire file; there is another delay (presumably font for
selected region is loaded separately).
4. C-h h to view hello file. Scroll all the way down with C-v.
5. Mark entire hello file, scroll all the way up from bottom.
6. View src/font.c (in emacs source), scroll all the way down to
render the whole file.
7. Mark the entire file, scroll all the way up, to view the entire
file in selected color.

Now:
8. View uncommon_symbols.txt: no delay.
9. Mark the entire file: no delay again.
10. View hello file: there is a noticeable delay of a few seconds with
the stack trace attached below.

This delay is, I think, identical to what I sometimes experience. Also
the reproduction's length can maybe be reduced somehow. I don't think
viewing three unicode-rich files should lead to such a noticeable
redrawing delay.

It's not so much that the delay is terribly long, it's that it
interrupts typing and normal workflow.

[-- Attachment #2: uncommon_symbols_bt.txt --]
[-- Type: text/plain, Size: 6086 bytes --]

* thread #1: tid = 0x978a, 0x00007fff828f6a1a libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff828f6a1a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff828f5d18 libsystem_kernel.dylib`mach_msg + 64
    frame #2: 0x00007fff8d8dc78d libFontRegistry.dylib`XTSendCopyPropertyForFonts + 227
    frame #3: 0x00007fff8d8f987c libFontRegistry.dylib`TGlobalFontRegistryImp::CopyPropertyForFonts(__CFArray const*, __CFString const*, TFontQueryOptions const&) const + 292
    frame #4: 0x00007fff8d8dc16f libFontRegistry.dylib`XTCopyPropertyForFonts + 115
    frame #5: 0x00007fff827f0817 CoreText`TBaseFont::CreateTraitsValuesPerFontInfo() const + 143
    frame #6: 0x00007fff827f068f CoreText`TBaseFont::CopyTraitsInternal() const + 87
    frame #7: 0x00007fff827f2e81 CoreText`TBaseFont::CreateTraitsValues() const + 29
    frame #8: 0x00007fff827f2e49 CoreText`TBaseFont::GetSymbolicTraitsInternal() const + 21
    frame #9: 0x00007fff827f2e17 CoreText`TBaseFont::GetSymbolicTraits(bool) const + 17
    frame #10: 0x00007fff8284fe56 CoreText`CompareLocalizedDescriptorsByTraitsAndPrecedence(void const*, void const*, void*, bool, bool) + 340
    frame #11: 0x00007fff8da10547 CoreFoundation`__CFSimpleMergeSort + 455
    frame #12: 0x00007fff8da10484 CoreFoundation`__CFSimpleMergeSort + 260
    frame #13: 0x00007fff8da10484 CoreFoundation`__CFSimpleMergeSort + 260
    frame #14: 0x00007fff8da1034b CoreFoundation`CFSortIndexes + 443
    frame #15: 0x00007fff8da10048 CoreFoundation`CFQSortArray + 232
    frame #16: 0x00007fff8da0fefe CoreFoundation`CFArraySortValues + 1054
    frame #17: 0x00007fff8284f008 CoreText`TDescriptorSource::CopyAllDescriptorsInternal(bool, CFComparisonResult (*)(void const*, void const*, void*)) const + 186
    frame #18: 0x00007fff8284f142 CoreText`TDescriptorSource::CopyAllDescriptorsSorted() const + 26
    frame #19: 0x00007fff827f5bfd CoreText`TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 249
    frame #20: 0x00007fff8283bf36 CoreText`CTFontDescriptorCreateMatchingFontDescriptors + 87
    frame #21: 0x00007fff86f2c521 AppKit`-[NSCTFontDescriptor matchingFontDescriptorsWithMandatoryKeys:] + 12
    frame #22: 0x00000001001c5d60 Emacs`ns_findfonts(font_spec=4345331237, isMatch='\0') + 1600 at nsfont.m:564
    frame #23: 0x000000010014ab10 Emacs`font_list_entities(f=0x0000000101065848, spec=4338851493) + 720 at font.c:2759
    frame #24: 0x000000010014cc33 Emacs`font_find_for_lface(f=0x0000000101065848, attrs=0x000000010a109f60, spec=<unavailable>, c=-1) + 1971 at font.c:3235
    frame #25: 0x00000001001985bb Emacs`fontset_find_font(fontset=4338292981, c=2870, face=0x000000010a109f60, id=<unavailable>, fallback=false) + 1755 at fontset.c:636
    frame #26: 0x0000000100194f13 Emacs`fontset_font(fontset=4471797549, c=2870, face=0x000000010a109f60, id=143) + 323 at fontset.c:754
    frame #27: 0x00000001001951a4 Emacs`font_for_char(face=0x000000010a109f60, c=2870, pos=<unavailable>, object=<unavailable>) + 260 at fontset.c:1023
    frame #28: 0x000000010014e4f7 Emacs`font_range(pos=<unavailable>, pos_byte=<unavailable>, limit=0x00007fff5fbf5a80, w=<unavailable>, face=<unavailable>, string=4328534074) + 903 at font.c:3774
    frame #29: 0x00000001001912dd Emacs`autocmp_chars(rule=4328841365, charpos=416, bytepos=542, limit=418, win=0x0000000101076c48, face=0x000000010a109f60, string=4328534074) + 349 at composite.c:900
    frame #30: 0x0000000100190f7a Emacs`composition_reseat_it(cmp_it=0x00007fff5fbf8020, charpos=416, bytepos=542, endpos=<unavailable>, w=0x0000000101076c48, face=0x000000010a109f60, string=140734799764272) + 634 at composite.c:1227
    frame #31: 0x0000000100053ac5 Emacs`next_element_from_buffer(it=0x00007fff5fbf77c8) + 357 at xdisp.c:8338
    frame #32: 0x000000010001a670 Emacs`get_next_display_element(it=0x00007fff5fbf77c8) + 48 at xdisp.c:6925
    frame #33: 0x00000001000284d8 Emacs`display_line(it=0x00007fff5fbf77c8) + 1304 at xdisp.c:20183
    frame #34: 0x0000000100027de6 Emacs`try_window(window=<unavailable>, flags=1, pos=<unavailable>) + 214 at xdisp.c:16972
    frame #35: 0x000000010004bb43 Emacs`redisplay_window(window=4312230989, just_this_one_p=false) + 13651 at xdisp.c:16451
    frame #36: 0x00000001000524f6 Emacs`redisplay_window_0(window=<unavailable>) + 38 at xdisp.c:14348
    frame #37: 0x0000000100138b34 Emacs`internal_condition_case_1(bfun=0x00000001000524d0, arg=4312230989, handlers=<unavailable>, hfun=<unavailable>) + 260 at eval.c:1372
    frame #38: 0x0000000100048554 Emacs`redisplay_windows(window=<unavailable>) + 180 at xdisp.c:14328
    frame #39: 0x0000000100026938 Emacs`redisplay_internal + 6184 at xdisp.c:13927
    frame #40: 0x00000001000c1a5e Emacs`read_char(commandflag=1, map=4497713446, prev_event=4328534074, used_mouse_menu=0x00007fff5fbff3df, end_time=0x0000000000000000) + 1982 at keyboard.c:2570
    frame #41: 0x00000001000bf0dc Emacs`read_key_sequence(bufsize=<unavailable>, keybuf=<unavailable>, prompt=<unavailable>, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) + 1964 at keyboard.c:9088
    frame #42: 0x00000001000be6f0 Emacs`command_loop_1 + 4736 at keyboard.c:1452
    frame #43: 0x0000000100138a1b Emacs`internal_condition_case(bfun=0x00000001000bd470, handlers=<unavailable>, hfun=<unavailable>) + 251 at eval.c:1348
    frame #44: 0x00000001000ceb6e Emacs`command_loop_2(ignore=<unavailable>) + 62 at keyboard.c:1177
    frame #45: 0x00000001001383a3 Emacs`internal_catch(tag=<unavailable>, func=0x00000001000ceb30, arg=4328534074) + 243 at eval.c:1112
    frame #46: 0x00000001000bcaad Emacs`recursive_edit_1 [inlined] command_loop + 68 at keyboard.c:1156
    frame #47: 0x00000001000bca69 Emacs`recursive_edit_1 + 265 at keyboard.c:777
    frame #48: 0x00000001000bcbf2 Emacs`Frecursive_edit + 242 at keyboard.c:848
    frame #49: 0x00000001000bb7da Emacs`main(argc=0, argv=<unavailable>) + 5850 at emacs.c:1646

[-- Attachment #3: uncommon_symbols.txt --]
[-- Type: text/plain, Size: 1164 bytes --]


nil !: ¬
nil !=: ≢
nil /=: ≢
nil ==: ≡
nil &&: ∧
nil ||: ∨
nil not: ¬
nil and: ∧
nil or: ∨
nil >=: ≥
nil <=: ≤
nil ->: →
nil <-: ←
nil ~: ∼
nil ::: ∷
nil ->: →
nil nullptr: ∅
nil null: ∅
nil NULL: ∅
nil None: ∅
nil undefined: ⟂
nil -<: ⤙
nil >-: ⤚
nil <*>: ⊛
nil >>: ≫
nil <<: ≪
nil >>=: ⤜
nil =<<: ⤛
nil >>>: ⋙
nil <<<: ⋘
nil ***: ⁂
nil ++: ⧺
nil +++: ⧻
nil |||: ⫴
nil elem: ∈
nil notElem: ∉
nil union: ∪
nil intersect: ∩
nil msum: ⊕
nil Integer: ℤ
nil Ratio Integer: ℚ
nil Double: ℝ
nil Bool: 𝔹
nil Gamma: Γ
nil Delta: Δ
nil Theta: Θ
nil Lambda: Λ
nil Xi: Ξ
nil Pi: Π
nil Sigma: Σ
nil Upsilon: ϒ
nil Phi: Φ
nil Psi: Ψ
nil Omega: Ω
nil alpha: α
nil beta: β
nil gamma: γ
nil delta: δ
nil epsilon: ε
nil zeta: ζ
nil eta: η
nil theta: θ
nil vartheta: ϑ
nil kappa: κ
nil lambda: λ
nil mu: μ
nil nu: ν
nil xi: ξ
nil pi: π
nil varpi: ϖ
nil rho: ρ
nil varrho: ϱ
nil varsigma: ς
nil sigma: σ
nil tau: τ
nil upsilon: υ
nil phi: ϕ
nil varphi: φ
nil chi: χ
nil psi: ψ
nil omega: ω
nil RussianR: Я
nil RussianZ: З
nil RussianZH: Ж
nil RussianE: Э

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Sebastian Wiesner]

> Am 04.12.2014 um 08:30 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> Date: Thu, 4 Dec 2014 02:13:30 -0500
>> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
>> 
>> [This is a copy of this question on Emacs.SE:
>> http://emacs.stackexchange.com/questions/4061]
>> At least one other person has the same problem.
> 
> Please ask those persons to report here directly, and to read the
> responses and discussions.

So here I am.  How do I subscribe to this bug so that I get replies per mail?

>> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
>> in languages like haskell, julia or c++), and (I think) especially with
>> an ornate color theme, I experience delays of maybe about five seconds
>> when switching between buffers. Running emacs under lldb show a stack
>> trace below; I get a similar stack trace from running `emacs -Q` and
>> typing `C-h h` (`view-hello-file`), which takes quite a while to display
>> the hello file.
> 
> AFAICT, these delays are due to Emacs searching the system for
> appropriate fonts needed to display those unusual symbols.
> 
>> What can I do about these window redrawing delays? I am not sure what I
>> have misconfigured.
> 
> Optimize your font configuration, so that the font search becomes
> faster.

I do not know about the OP, but I do not have any “font configuration”.  All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.

Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?  Shouldn't Emacs pick reasonable defaults by itself, and remember them?  I don't mean to blame anyone, but see, all other applications on my system work fine with my fonts…

>> Does emacs reload all fonts every time I switch to a different frame or
>> buffer? It also seems to have a delay sometimes when a previously
>> invisible overlay is shown.
> 
> Emacs only looks for a font when it needs to display something.  when
> previously invisible portion is about to be displayed, Emacs needs the
> fonts to display it.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> From: Sebastian Wiesner <swiesner@lunaryorn.com>
> Date: Thu, 4 Dec 2014 10:55:21 +0100
> Cc: Kirill Ignatiev <kirill.ignatiev@gmail.com>,
>  19266@debbugs.gnu.org
> 
> > Please ask those persons to report here directly, and to read the
> > responses and discussions.
> 
> So here I am.

Thanks for responding.

> How do I subscribe to this bug so that I get replies per mail?

You will be CC'ed on responses, so no need to subscribe.

> > Optimize your font configuration, so that the font search becomes
> > faster.
> 
> I do not know about the OP, but I do not have any “font configuration”.  All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.

I meant your system-wide font configuration, not what you do in Emacs.

> Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?

Sorry, I don't know that.  If you didn't install too many optional
fonts that didn't come with your system, then I think you are already
set.  Otherwise, perhaps some OS X expert, here or on some other
forum, could help.

> Shouldn't Emacs pick reasonable defaults by itself, and remember them?

It should, and it tries to.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Sebastian Wiesner]

> Am 04.12.2014 um 11:17 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Sebastian Wiesner <swiesner@lunaryorn.com>
>> Date: Thu, 4 Dec 2014 10:55:21 +0100
>> Cc: Kirill Ignatiev <kirill.ignatiev@gmail.com>,
>> 19266@debbugs.gnu.org
>> 
>>> Please ask those persons to report here directly, and to read the
>>> responses and discussions.
>> 
>> So here I am.
> 
> Thanks for responding.
> 
>> How do I subscribe to this bug so that I get replies per mail?
> 
> You will be CC'ed on responses, so no need to subscribe.
> 
>>> Optimize your font configuration, so that the font search becomes
>>> faster.
>> 
>> I do not know about the OP, but I do not have any “font configuration”.  All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.
> 
> I meant your system-wide font configuration, not what you do in Emacs.

I don't have that either :)  OS X comes with all sorts of fonts pre-installed, and I just added some five fonts or so.

>> Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?
> 
> Sorry, I don't know that.  If you didn't install too many optional
> fonts that didn't come with your system, then I think you are already
> set.  Otherwise, perhaps some OS X expert, here or on some other
> forum, could help.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

I tried looking into this a bit more, and I'm not very familiar with
emacs's internals.

I find that many faces that were previously used get garbage collected
(I see macfont_close being called from cleanup_vector), but I don't
know how faces are stored, nor do I understand why they are no longer
referenced (common sense suggests that they should remain in memory as
long as the buffer that used them is still there). It seems that the
faces are not actively used for displaying the buffer, but can be
expected to be reused in a short time (e.g., region face or comment
face).

Can someone explain where faces are stored and why they are no longer
referenced, even though the buffer that used them is still active?

I am not sure if this is related to this bug, but there is a constant
CLEAR_FACE_CACHE_COUNT (=500) that causes face cache to be cleared
every 500 redisplays. Does anyone understand why this is really
necessary? If the fonts/faces are still in use, that seems wasteful,
unless I misunderstand something.

On 4 December 2014 at 05:19, Sebastian Wiesner <swiesner@lunaryorn.com> wrote:
>
>> Am 04.12.2014 um 11:17 schrieb Eli Zaretskii <eliz@gnu.org>:
>>
>>> From: Sebastian Wiesner <swiesner@lunaryorn.com>
>>> Date: Thu, 4 Dec 2014 10:55:21 +0100
>>> Cc: Kirill Ignatiev <kirill.ignatiev@gmail.com>,
>>> 19266@debbugs.gnu.org
>>>
>>>> Please ask those persons to report here directly, and to read the
>>>> responses and discussions.
>>>
>>> So here I am.
>>
>> Thanks for responding.
>>
>>> How do I subscribe to this bug so that I get replies per mail?
>>
>> You will be CC'ed on responses, so no need to subscribe.
>>
>>>> Optimize your font configuration, so that the font search becomes
>>>> faster.
>>>
>>> I do not know about the OP, but I do not have any “font configuration”.  All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.
>>
>> I meant your system-wide font configuration, not what you do in Emacs.
>
> I don't have that either :)  OS X comes with all sorts of fonts pre-installed, and I just added some five fonts or so.
>
>>> Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?
>>
>> Sorry, I don't know that.  If you didn't install too many optional
>> fonts that didn't come with your system, then I think you are already
>> set.  Otherwise, perhaps some OS X expert, here or on some other
>> forum, could help.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> Date: Sun, 7 Dec 2014 00:50:01 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 19266@debbugs.gnu.org
> 
> I find that many faces that were previously used get garbage collected
> (I see macfont_close being called from cleanup_vector), but I don't
> know how faces are stored, nor do I understand why they are no longer
> referenced (common sense suggests that they should remain in memory as
> long as the buffer that used them is still there).

Face realizations are not specific to buffers, they are specific to
frames.  So the same face can be realized differently on each frame,
and the same buffer displayed on 2 different frames might look
differently.

OTOH, a given face can be used by many buffers on a frame.

So we cannot easily make a simple one-to-one connection between
buffers and faces they use.

> It seems that the faces are not actively used for displaying the
> buffer, but can be expected to be reused in a short time (e.g.,
> region face or comment face).

You forgot the 'default' face, by far the most reused face.

Also, Emacs consults the face every time it needs to display a
character which uses that face.  So caching is really a necessity.

> Can someone explain where faces are stored and why they are no longer
> referenced, even though the buffer that used them is still active?

Realized faces are stored in the frame's face_cache.  As for the
second part of your question, I hope I clarified the issue at least to
some extent.

> I am not sure if this is related to this bug, but there is a constant
> CLEAR_FACE_CACHE_COUNT (=500) that causes face cache to be cleared
> every 500 redisplays. Does anyone understand why this is really
> necessary?

Because we don't really know when a face is no longer needed.
Tracking that could be more hassle than throwing the cache away from
time to time.

Anyway, if you enlarge that number 100-fold, does the problem go away?
If not, then this is not the cause of your problem.

Also, font objects are stored and maintained differently than faces.
So I'm not sure you are on the right track looking into faces.

Thanks.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

[-- Attachment #1: Type: text/plain, Size: 7725 bytes --]

Can someone familiar with emacs' font internals check if this makes
sense as the cause of the problem, please? I really don't understand
how/where fonts are stored/cached/used; I did read
font/fontset/macfont/alloc.c, but I'm still unclear.

To summarize: My interpretation of what's happening is that when emacs
looks at some fonts to see if they contain a certain characters and
neither of them does, emacs *does not* cache the fonts. So the next
time redisplay happens after those fonts are garbage-collected, emacs
has to load the fonts all over again, causing a noticeable redisplay
delay.

Shouldn't these fonts be cached as well?

For testing, how do I turn off font garbage collection, so that no
font is ever closed?

How do I trigger font garbage collection manually?

Is this the right mailing list for this?

So now:

Apply the attached patch that traces every call to
font_driver->{open,close} with printf, *no actual changes*. I tested
this on OS X, maybe it's the same on linux. Now consider the following
commands, executed in patched emacs with -Q:

(set-fontset-font
 t '(#x1d400 . #x1d7ff)
 (font-xlfd-name (find-font (font-spec :family "Symbola"))))

(progn
  (insert ?\n)
  (dotimes (i (- #x1d800 #x1d400))
    (insert (+ #x1d400 i)))
  (insert ?\n))

Here, Symbola is a font that includes uncommon characters
#x1d400..#x1d7ff (not all of that range is valid unicode characters),
while the font chosen by emacs by default ("Menlo", there's nothing
special about it, I think) does not. On a different computer with different
fonts, you might need to set some other fonts.

For reference, the font specs are (from describe-fontset)
    -*-Symbola-normal-normal-semicondensed-*-*-*-*-*-p-0-iso10646-1
    -*-Menlo-normal-normal-normal-*-*-*-*-*-m-0-fontset-startup

This example uses invalid characters (rather than characters missing
from Symbola) because Symbola includes a lot of characters, and my
previous testing suggested that if I pick a font that actually misses
some characters the results are the same, but then I have to try to
also figure out which exact characters are missing, which is very
font-dependent. Invalid characters are always missing.

It seems to be those characters not present in either Symbola or the
default font that are causing delays.

I run emacs with -Q, and execute those two commands in the scratch
buffer.  The output is this:

font_open_entity: 0x10280fe30 4336959717 0 => 4321797773
font_open_entity: 0x10280fe30 4322249501 12 => 4322240165
font_open_entity: 0x10280fe30 4322249381 12 => 4322313893
compact_font_cache_entry: dropped 2 entries
cleanup_vector: drv->close 0x101a026a0
font_open_entity: 0x10280fe30 4346667037 12 => 4346773157
font_open_entity: 0x10280fe30 4321497117 12 => 4322359973
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x101a146a0
font_open_entity: 0x10280fe30 4346850893 12 => 4346855205
font_open_entity: 0x10280fe30 4346855581 12 => 4338042813
font_open_entity: 0x10280fe30 4346864757 12 => 4347020349
font_open_entity: 0x10280fe30 4314058597 12 => 4314214573
font_open_entity: 0x10280fe30 4314313573 12 => 4314346005
font_open_entity: 0x10280fe30 4314342253 12 => 4314776629
font_open_entity: 0x10280fe30 4338539877 12 => 4338731989
font_open_entity: 0x10280fe30 4338728301 12 => 4315110181
font_open_entity: 0x10280fe30 4315102573 12 => 4338889725
font_open_entity: 0x10280fe30 4315401573 12 => 4315429429
font_open_entity: 0x10280fe30 4337120613 12 => 4339102261
font_open_entity: 0x10280fe30 4339702117 12 => 4339661005
font_open_entity: 0x10280fe30 4339664797 12 => 4339599381
font_open_entity: 0x10280fe30 4339591533 7 => 4315644109
compact_font_cache_entry: dropped 15 entries

The number of font_open_entity seems to correspond to the number of
different fonts on my computer matching the default font spec, or
something like this.  None of them contain missing characters.  Now I
go to, say, emacs/src/font.c, scroll up and down for a while (I'm not
sure how this garbage collection is triggered, I'd rather trigger it
manually but I don't know how), and eventually I get this:

font_open_entity: 0x10280fe30 4347168317 12 => 4347168797
font_open_entity: 0x10280fe30 4347168557 12 => 4347247269
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x1013b80c8
cleanup_vector: drv->close 0x102a9f8c8
cleanup_vector: drv->close 0x102a90810
cleanup_vector: drv->close 0x102a17230
cleanup_vector: drv->close 0x101383a30
cleanup_vector: drv->close 0x1029e33f8
cleanup_vector: drv->close 0x101335b20
cleanup_vector: drv->close 0x1029bcbd0
cleanup_vector: drv->close 0x1012e4430
cleanup_vector: drv->close 0x10127b210
cleanup_vector: drv->close 0x10125b0a8
cleanup_vector: drv->close 0x1029147b8
cleanup_vector: drv->close 0x1031a4438
cleanup_vector: drv->close 0x10317bf20
cleanup_vector: drv->close 0x101a1faa0
cleanup_vector: drv->close 0x103167ea0

This looks (?) like the fonts that don't contain the characters
missing from "Symbola" (which are invalid, so they can be expected to
be missing) and that emacs looked through, are garbage-collected.
Now I go back to the scratch buffer, and see this in the output:

font_open_entity: 0x10280fe30 4313918837 12 => 4322005021
font_open_entity: 0x10280fe30 4347261093 12 => 4347020349
font_open_entity: 0x10280fe30 4315110293 12 => 4346845997
font_open_entity: 0x10280fe30 4346846261 12 => 4346946861
font_open_entity: 0x10280fe30 4346947125 12 => 4322621621
font_open_entity: 0x10280fe30 4322621885 12 => 4314086573
font_open_entity: 0x10280fe30 4314086837 12 => 4314116149
font_open_entity: 0x10280fe30 4314111805 12 => 4314181685
font_open_entity: 0x10280fe30 4314181949 12 => 4314333237
font_open_entity: 0x10280fe30 4314000621 12 => 4314399253
font_open_entity: 0x10280fe30 4314399517 12 => 4314468405
font_open_entity: 0x10280fe30 4314465117 12 => 4314653901
font_open_entity: 0x10280fe30 4314649741 12 => 4314723381
font_open_entity: 0x10280fe30 4314715909 7 => 4314724005
compact_font_cache_entry: dropped 14 entries

The redisplay to go back to the scratch buffer takes a fair amount of
time (several seconds), and it looks like the fonts that don't contain
missing characters are loaded again, examined, and they still don't
contain those characters.

The rest of the session looks like this, where I did some editing.

font_open_entity: 0x10280fe30 4314826397 12 => 4314833973
font_open_entity: 0x10280fe30 4314822261 12 => 4338334365
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x1012d7430
cleanup_vector: drv->close 0x1012d76a0
cleanup_vector: drv->close 0x1012c64c8
cleanup_vector: drv->close 0x101299030
cleanup_vector: drv->close 0x101288210
cleanup_vector: drv->close 0x101278030
cleanup_vector: drv->close 0x101253030
cleanup_vector: drv->close 0x101243030
cleanup_vector: drv->close 0x10123bca8
cleanup_vector: drv->close 0x101a5f8b0
cleanup_vector: drv->close 0x103192528
cleanup_vector: drv->close 0x1031dbaa0
cleanup_vector: drv->close 0x1031c8818
cleanup_vector: drv->close 0x1031a4438
cleanup_vector: drv->close 0x103179b28
cleanup_vector: drv->close 0x1019c9018
font_open_entity: 0x10280fe30 4338666765 12 => 4338670133
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x10295ba98
cleanup_vector: drv->close 0x1012f2430
font_open_entity: 0x10280fe30 4338678941 14 => 4338683037
font_open_entity: 0x10280fe30 4338691229 12 => 4338695325
font_open_entity: 0x10280fe30 4338691349 12 => 4338715805
font_open_entity: 0x10280fe30 4338687245 10 => 4338471477
font_open_entity: 0x10280fe30 4338740325 12 => 4338744093
font_open_entity: 0x10280fe30 4338687245 7 => 4314561589
font_open_entity: 0x10280fe30 4338687365 12 => 4314566357
compact_font_cache_entry: dropped 3 entries

[-- Attachment #2: bugreport2_patch.txt --]
[-- Type: text/plain, Size: 3473 bytes --]

diff --git a/src/alloc.c b/src/alloc.c
index 1019c2a..2c01fb8 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -2996,6 +2996,7 @@ cleanup_vector (struct Lisp_Vector *vector)
 	  /* Attempt to catch subtle bugs like Bug#16140.  */
 	  eassert (valid_font_driver (drv));
 	  drv->close ((struct font *) vector);
+	  fprintf(stderr, "cleanup_vector: drv->close %p\n", (struct font *) vector);
 	}
     }
 }
@@ -5438,6 +5439,7 @@ static Lisp_Object
 compact_font_cache_entry (Lisp_Object entry)
 {
   Lisp_Object tail, *prev = &entry;
+  int count_dropped = 0;
 
   for (tail = entry; CONSP (tail); tail = XCDR (tail))
     {
@@ -5461,11 +5463,13 @@ compact_font_cache_entry (Lisp_Object entry)
 	  if (i == size)
 	    drop = 1;
 	}
+      count_dropped += drop;
       if (drop)
 	*prev = XCDR (tail);
       else
 	prev = xcdr_addr (tail);
     }
+  if (count_dropped) fprintf(stderr, "compact_font_cache_entry: dropped %d entries\n", count_dropped);
   return entry;
 }
 
diff --git a/src/font.c b/src/font.c
index 70e6316..7f83acc 100644
--- a/src/font.c
+++ b/src/font.c
@@ -2663,6 +2663,7 @@ font_clear_cache (struct frame *f, Lisp_Object cache, struct font_driver *driver
 			{
 			  eassert (font && driver == font->driver);
 			  driver->close (font);
+			  fprintf(stderr, "font_clear_cache: driver->close %p\n", font);
 			}
 		    }
 		  if (driver->free_entity)
@@ -2951,6 +2952,7 @@ font_open_entity (struct frame *f, Lisp_Object entity, int pixel_size)
     }
 #endif
 
+  fprintf(stderr, "font_open_entity: %p %ld %d => %ld\n", f, entity, pixel_size, font_object);
   return font_object;
 }
 
@@ -2971,6 +2973,8 @@ font_close_object (struct frame *f, Lisp_Object font_object)
   eassert (FRAME_DISPLAY_INFO (f)->n_fonts);
   FRAME_DISPLAY_INFO (f)->n_fonts--;
 #endif
+
+  fprintf(stderr, "font_close_object: %p %ld\n", f, font_object);
 }
 
 
diff --git a/src/macfont.m b/src/macfont.m
index 7054839..9104352 100644
--- a/src/macfont.m
+++ b/src/macfont.m
@@ -2440,8 +2440,10 @@ macfont_open (struct frame * f, Lisp_Object entity, int pixel_size)
   val = assq_no_quit (QCfont_entity, AREF (entity, FONT_EXTRA_INDEX));
   if (! CONSP (val)
       || XTYPE (XCDR (val)) != Lisp_Misc
-      || XMISCTYPE (XCDR (val)) != Lisp_Misc_Save_Value)
+      || XMISCTYPE (XCDR (val)) != Lisp_Misc_Save_Value) {
+    // fprintf(stderr, "macfont_open: %p, %ld, %d => %ld\n", f, entity, pixel_size, Qnil);
     return Qnil;
+  }
   font_name = XSAVE_POINTER (XCDR (val), 0);
   sym_traits = XSAVE_INTEGER (XCDR (val), 1);
 
@@ -2457,8 +2459,10 @@ macfont_open (struct frame * f, Lisp_Object entity, int pixel_size)
       if (fontsize != size) size = fontsize;
     }
   unblock_input ();
-  if (! macfont)
+  if (! macfont) {
+    // fprintf(stderr, "macfont_open: %p, %ld, %d => %ld\n", f, entity, pixel_size, Qnil);
     return Qnil;
+  }
 
   font_object = font_build_object (VECSIZE (struct macfont_info),
                                    Qmac_ct, entity, size);
@@ -2580,6 +2584,7 @@ macfont_open (struct frame * f, Lisp_Object entity, int pixel_size)
   font->default_ascent = 0;
   font->vertical_centering = 0;
 
+  // fprintf(stderr, "macfont_open: %p, %ld, %d => %ld\n", f, entity, pixel_size, Qnil);
   return font_object;
 }
 
@@ -2588,6 +2593,8 @@ macfont_close (struct font *font)
 {
   struct macfont_info *macfont_info = (struct macfont_info *) font;
 
+  // fprintf(stderr, "macfont_close: %p\n", font);
+
   if (macfont_info->cache)
     {
       int i;

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> Date: Wed, 10 Dec 2014 18:50:01 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> Cc: Sebastian Wiesner <swiesner@lunaryorn.com>, 19266@debbugs.gnu.org
> 
> Can someone familiar with emacs' font internals check if this makes
> sense as the cause of the problem, please? I really don't understand
> how/where fonts are stored/cached/used; I did read
> font/fontset/macfont/alloc.c, but I'm still unclear.

Unfortunately, we don't have too many experts on this, to put it
mildly.  Dmitry, could you please take a look?

> To summarize: My interpretation of what's happening is that when emacs
> looks at some fonts to see if they contain a certain characters and
> neither of them does, emacs *does not* cache the fonts. So the next
> time redisplay happens after those fonts are garbage-collected, emacs
> has to load the fonts all over again, causing a noticeable redisplay
> delay.

This does sound like the truth, although I'm not sure.

> For testing, how do I turn off font garbage collection, so that no
> font is ever closed?

Comment out the call to cleanup_vector?

> How do I trigger font garbage collection manually?

Did you try "M-x garbage-collect RET"?

> Is this the right mailing list for this?

Yes, it is.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

On 11 December 2014 at 12:45, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 10 Dec 2014 18:50:01 -0500
>> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
>> Cc: Sebastian Wiesner <swiesner@lunaryorn.com>, 19266@debbugs.gnu.org
>
> Comment out the call to cleanup_vector?

Oops, I only tried to turn compact_font_cache_entry into a noop. But
neither that, nor doing nothing in cleanup_vector works. If I comment
out drv->close, I see a bunch of calls to drv->close not being made,
but new fonts are *still* being opened in font_open_entity.

I'm guessing that when fonts are garbage collected, they are already
genuinely discarded, not pointed to from elisp structures (or where
they are stored), and are genuine garbage. Do you know where the
pointers to fonts live? I haven't figured out where they are being
discarded, and I'd like to stop them from becoming garbage in the
first place.

>
>> How do I trigger font garbage collection manually?
>
> Did you try "M-x garbage-collect RET"?

Yes, but it doesn't seem to trigger closing fonts. Perhaps there is
some other process at work there?

Thanks for your help, these redrawing delays are really irritating.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> Date: Thu, 11 Dec 2014 21:10:32 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>, Sebastian Wiesner <swiesner@lunaryorn.com>, 19266@debbugs.gnu.org
> 
> On 11 December 2014 at 12:45, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Wed, 10 Dec 2014 18:50:01 -0500
> >> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> >> Cc: Sebastian Wiesner <swiesner@lunaryorn.com>, 19266@debbugs.gnu.org
> >
> > Comment out the call to cleanup_vector?
> 
> Oops, I only tried to turn compact_font_cache_entry into a noop. But
> neither that, nor doing nothing in cleanup_vector works. If I comment
> out drv->close, I see a bunch of calls to drv->close not being made,
> but new fonts are *still* being opened in font_open_entity.
> 
> I'm guessing that when fonts are garbage collected, they are already
> genuinely discarded, not pointed to from elisp structures (or where
> they are stored), and are genuine garbage. Do you know where the
> pointers to fonts live? I haven't figured out where they are being
> discarded, and I'd like to stop them from becoming garbage in the
> first place.

Look up the call chain (best done by setting a breakpoint and looking
at the backtrace), and you will certainly find a place which decides
to discard them.  Then comment out or change the code which does that.

> >> How do I trigger font garbage collection manually?
> >
> > Did you try "M-x garbage-collect RET"?
> 
> Yes, but it doesn't seem to trigger closing fonts. Perhaps there is
> some other process at work there?

Again, look at the backtrace at a breakpoint in cleanup_vector and in
compact_font_cache_entry.  Isn't there some GC-related function on the
callstack?  Perhaps post that here, if you cannot figure that out.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Sebastian Wiesner]

> Am 12.12.2014 um 03:10 schrieb Kirill Ignatiev <kirill.ignatiev@gmail.com>:
> 
> On 11 December 2014 at 12:45, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Wed, 10 Dec 2014 18:50:01 -0500
>>> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
>>> Cc: Sebastian Wiesner <swiesner@lunaryorn.com>, 19266@debbugs.gnu.org
>> 
>> Comment out the call to cleanup_vector?
> 
> …
> 
> Thanks for your help, these redrawing delays are really irritating.

You have long lost me on your discussion about Emacs internals, but I should just like to say that the unicode-fonts package from https://github.com/rolandwalker/unicode-fonts has fixed all these delays for me.

As far as I understand, this package maps Unicode blocks to specific fonts.  I presume that Emacs would otherwise search through all installed fonts for one that supports the Unicode character that needs to be drawn, and that the explicit mapping prevents Emacs from doing that.

Seems that Eli was right with his “Fix your font configuration” remark.

Thanks for your help and your effort!

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

On 12 December 2014 at 03:29, Sebastian Wiesner <swiesner@lunaryorn.com> wrote:
>
>> Am 12.12.2014 um 03:10 schrieb Kirill Ignatiev <kirill.ignatiev@gmail.com>:
>>
>> On 11 December 2014 at 12:45, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> Date: Wed, 10 Dec 2014 18:50:01 -0500
>>>> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
>>>> Cc: Sebastian Wiesner <swiesner@lunaryorn.com>, 19266@debbugs.gnu.org
>>>
>>> Comment out the call to cleanup_vector?
>>
>> …
>>
>> Thanks for your help, these redrawing delays are really irritating.
>
> You have long lost me on your discussion about Emacs internals, but I should just like to say that the unicode-fonts package from https://github.com/rolandwalker/unicode-fonts has fixed all these delays for me.

I tried unicode-fonts now, and it does seem to fix the delays. Thanks!
But I still think there's a problem: my configuration, which led to
these delays, and my other example with one default font and one
special font for uncommon symbols, are both perfectly ordinary and
simple configurations. I'd say they shouldn't cause these kinds of
problems at all. In particular, unicode-fonts is not actually part of
emacs, so it's reasonable to expect emacs to work well enough without
it.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Eli Zaretskii]

> Date: Fri, 12 Dec 2014 04:33:06 -0500
> From: Kirill Ignatiev <kirill.ignatiev@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Dmitry Antipov <dmantipov@yandex.ru>, 19266@debbugs.gnu.org
> 
> I tried unicode-fonts now, and it does seem to fix the delays. Thanks!
> But I still think there's a problem: my configuration, which led to
> these delays, and my other example with one default font and one
> special font for uncommon symbols, are both perfectly ordinary and
> simple configurations. I'd say they shouldn't cause these kinds of
> problems at all. In particular, unicode-fonts is not actually part of
> emacs, so it's reasonable to expect emacs to work well enough without
> it.

You are encouraged to continue investigating this problem and
reporting your findings here.  It's quite possible that there's
something we need to fix, as the font releasing process was changed
lately, and could likely need improvements.

Thanks.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

On 12 December 2014 at 03:06, Eli Zaretskii <eliz@gnu.org> wrote:
> Look up the call chain (best done by setting a breakpoint and looking
> at the backtrace), and you will certainly find a place which decides
> to discard them.  Then comment out or change the code which does that.
>
> ...
>
> Again, look at the backtrace at a breakpoint in cleanup_vector and in
> compact_font_cache_entry.  Isn't there some GC-related function on the
> callstack?  Perhaps post that here, if you cannot figure that out.

The top function is garbage_collect, but whatever leads it to close
the fonts isn't triggered by a manual call to garbage-collect in
emacs.

Also: if the garbage collector isn't wrong, the fact that font
entities are garbage means that it really is okay to close them: they
wouldn't be accessible to all the other code anyway. I don't quite
understand how font_open_entity decides to load a font against using a
cache, but making sure fonts remain accessible to the call path

face_for_char -> fontset_font -> fontset_find_font -> font_open_entity

is probably the thing to do. Setting compact_font_cache_entry to a
noop doesn't seem to do the trick, font_open_entity gets called too
many times anyway, if I'm not mistaken.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

On some further testing, it seems that commenting out the section of
compact_font_caches that calls compact_font_cache_entry works (the
section surrounded in !defined(HAVE_NTGUI)). There are no more
repeated calls to font_open_entity, and fonts are not closed as
before. I am unable to reproduce the redisplay delay with the two-font
example above.

This presumably stops all cached fonts from being closed at all, ever,
so maybe there should be a more elegant solution. This could (?) be an
issue that mark_face_cache just doesn't mark enough fonts, so unused
fonts get discarded and must be loaded again. Also, this doesn't
explain why garbage-collect doesn't seem to trigger font closing.

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Lars Ingebrigtsen]

Kirill Ignatiev <kirill.ignatiev@gmail.com> writes:

> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
> in languages like haskell, julia or c++), and (I think) especially with
> an ornate color theme, I experience delays of maybe about five seconds
> when switching between buffers. Running emacs under lldb show a stack
> trace below; I get a similar stack trace from running `emacs -Q` and
> typing `C-h h` (`view-hello-file`), which takes quite a while to display
> the hello file.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Do you still see these delays in recent Emacs/OS versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Kirill Ignatiev]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Sat 30 Apr 2022 at 16:44 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Kirill Ignatiev <kirill.ignatiev@gmail.com> writes:
>
> > Often when I'm editing a file with many uncommon unicode symbols (e.g.,
> > in languages like haskell, julia or c++), and (I think) especially with
> > an ornate color theme, I experience delays of maybe about five seconds
> > when switching between buffers. Running emacs under lldb show a stack
> > trace below; I get a similar stack trace from running `emacs -Q` and
> > typing `C-h h` (`view-hello-file`), which takes quite a while to display
> > the hello file.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> Do you still see these delays in recent Emacs/OS versions?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
No, I don’t. This was such a long time ago, but between improvements to
emacs itself and using the unicode-fonts package I haven’t had font issues
in ages now.

[-- Attachment #2: Type: text/html, Size: 1525 bytes --]

bug#19266: 24.4; Font-related window redrawing delays on OS X

[Lars Ingebrigtsen]

Kirill Ignatiev <kirill.ignatiev@gmail.com> writes:

> No, I don’t. This was such a long time ago, but between improvements to emacs
> itself and using the unicode-fonts package I haven’t had font issues in ages now.

Thanks; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no