bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

Hello,

I use the new native line number display feature in this fashion:

=====
(defconst modi/linum-mode-hooks '(verilog-mode-hook
                                  emacs-lisp-mode-hook
                                  cperl-mode-hook
                                  c-mode-hook
                                  python-mode-hook
                                  matlab-mode-hook
                                  sh-mode-hook
                                  web-mode-hook
                                  html-mode-hook
                                  css-mode-hook
                                  makefile-gmake-mode-hook
                                  tcl-mode-hook
                                  conf-space-mode-hook
                                  d-mode-hook
                                  sml-mode-hook
                                  nim-mode-hook
                                  yaml-mode-hook)
  "List of hooks of major modes in which a “linum” mode should be
enabled.") ;I know I should switch to using prog-mode-hook at some point

(defun modi/native-linum-absolute ()
  "Set buffer-local variable `display-line-numbers' to t."
  (interactive)
  (setq display-line-numbers t))

(defun modi/turn-on-native-linum ()
  "Turn on native line numbers in specific modes."
  (interactive)
  (if modi/linum-mode-enable-global
      (progn
        (dolist (hook modi/linum-mode-hooks)
          (remove-hook hook #'modi/native-linum-absolute))
        (setq-default display-line-numbers t))
    (progn
      (when global-linum-mode
        (setq-default display-line-numbers nil))
      (dolist (hook modi/linum-mode-hooks)
        (add-hook hook #'modi/native-linum-absolute)))))

(modi/turn-on-native-linum)
=====

The full linum management code is here[1]; above is just the relevant part
from that.

It works.

But seemingly randomly, the line numbers disappear when the emacs frame is
not in focus.

I do not know if my setup has to do with this but here are the details:

- I build emacs master on RHEL 6.6.
- I access the RHEL machine via VNC on Windows 7 Enterprise (work)
- Occasionally I would venture into Windows to get work email (Outlook) or
to the Chrome browwer in Windows.
- With the way my monitors are set up, one monitor would should the VNC
window showing the emacs frame and another monitor would should Outlook.

Then as I would be working on something in Outlook, I would see from the
corner of my eye that the line numbers disappeared from the emacs window
with code in verilog-mode. Clicking again on the emacs frame (in VNC,
remember) would bring the line numbers back.

As I mentioned on emacs-devel, I cannot recreate this behavior and so
cannot come up with steps to recreate this on emacs -Q.

How can I help debug this otherwise:
- Can I add something locally to the C code so that certain hooks get
triggered when the line numbers display is turned on/off?

[1]:
https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-linum.el

In GNU Emacs 26.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 2.24.23)
 of 2017-07-10
Repository revision: 0440c748aaec9b8b32c8cb268f6e24e874fedc75
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6
(Santiago)

Recent messages:
Finished reverting buffers containing unmodified files.
Desktop saved in ~/.emacs.d/
Note: file is write protected
Mark set
Note: file is write protected

Configured using:
 'configure --with-modules
 --prefix=/home/kmodi/usr_local/apps/6/emacs/master
 '--program-transform-name=s/^ctags$/ctags_emacs/'
 'CPPFLAGS=-I/home/kmodi/usr_local/6/include -I/usr/include/freetype2
 -I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0'
 'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64
 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Verilog

Minor modes in effect:
  ace-window-display-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  yas-minor-mode: t
  minibuffer-line-mode: t
  flyspell-mode: t
  which-key-mode: t
  ivy-mode: t
  projectile-mode: t
  global-hardcore-mode: t
  hardcore-mode: t
  modi/verilog-do-not-read-includes-defines-mode: t
  desktop-save-mode: t
  save-place-mode: t
  minibuffer-depth-indicate-mode: t
  winner-mode: t
  smart-mark-mode: t
  delete-selection-mode: t
  which-function-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  rainbow-delimiters-mode: t
  global-page-break-lines-mode: t
  outline-minor-mode: t
  keyfreq-autosave-mode: t
  keyfreq-mode: t
  global-hungry-delete-mode: t
  hungry-delete-mode: t
  volatile-highlights-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  diff-auto-refine-mode: t
  global-git-commit-mode: t
  recentf-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  async-bytecomp-package-mode: t
  engine-mode: t
  beacon-mode: t
  shackle-mode: t
  mode-line-space-mode: t
  display-time-mode: t
  ctags-auto-update-mode: t
  ggtags-mode: t
  modi-mode: t
  override-global-mode: t
  show-paren-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  prettify-symbols-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: (only . t)
  abbrev-mode: t

Load-path shadows:
/home/kmodi/.emacs.d/elisp/verilog-mode/verilog-mode hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/progmodes/verilog-mode
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-macro
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-macro
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-texinfo
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-texinfo
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-publish
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-publish
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-org
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-org
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-odt
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-odt
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-md
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-md
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-man
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-man
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-latex
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-latex
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-icalendar
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-icalendar
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-html
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-html
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-list
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-list
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-bbdb
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-bbdb
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-attach
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-attach
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-shen
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-shen
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-shell
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-shell
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-js
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-js
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-haskell
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-haskell
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-faces
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-faces
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-beamer
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-beamer
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-w3m
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-w3m
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ox-ascii
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ox-ascii
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-table
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-table
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-python
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-python
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-timer
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-timer
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-table
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-table
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-src
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-src
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-rmail
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-rmail
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-protocol
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-protocol
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-plot
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-plot
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-pcomplete
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-pcomplete
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-mouse
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-mouse
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-mobile
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-mobile
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-mhe
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-mhe
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-macs
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-macs
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-lint
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-lint
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-irc
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-irc
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-inlinetask
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-inlinetask
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-info
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-info
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-indent
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-indent
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-id
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-id
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-habit
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-habit
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-gnus
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-gnus
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-footnote
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-footnote
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-feed
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-feed
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-eww
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-eww
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-eshell
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-eshell
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-entities
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-entities
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-element
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-element
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-docview
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-docview
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-datetree
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-datetree
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-ctags
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-ctags
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-crypt
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-crypt
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-compat
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-compat
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-colview
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-colview
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-clock
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-clock
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-capture
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-capture
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-bibtex
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-bibtex
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-archive
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-archive
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-agenda
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-agenda
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-tangle
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-tangle
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-stan
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-stan
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-sqlite
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-sqlite
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-sql
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-sql
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-sed
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-sed
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-screen
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-screen
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-fortran
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-fortran
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-scheme
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-scheme
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-scala
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-scala
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-sass
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-sass
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-ruby
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-ruby
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-R
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-R
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-ref
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-ref
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-processing
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-processing
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-plantuml
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-plantuml
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-picolisp
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-picolisp
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-perl
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-perl
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-org
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-org
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-octave
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-octave
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-ocaml
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-ocaml
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-mscgen
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-mscgen
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-maxima
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-maxima
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-matlab
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-matlab
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-makefile
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-makefile
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-lua
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-lua
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-lob
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-lob
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-lisp
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-lisp
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-lilypond
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-lilypond
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-ledger
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-ledger
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-latex
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-latex
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-keys
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-keys
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-J
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-J
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-java
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-java
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-io
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-io
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-groovy
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-groovy
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-gnuplot
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-gnuplot
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-forth
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-forth
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-exp
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-exp
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-eval
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-eval
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-emacs-lisp
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-emacs-lisp
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-ebnf
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-ebnf
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-dot
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-dot
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-ditaa
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-ditaa
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-css
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-css
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-core
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-core
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-coq
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-coq
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-comint
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-comint
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-clojure
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-clojure
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-C
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-C
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-asymptote
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-asymptote
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-calc
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-calc
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-awk
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-awk
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-version
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-version
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-loaddefs
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-loaddefs
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/org-install
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/org-install
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/ob-abc
hides
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/26.0.50/lisp/org/ob-abc

Features:
(shadow sort mail-extr emacsbug sendmail expand-region
text-mode-expansions cc-mode-expansions the-org-mode-expansions
js-mode-expansions web-mode-expansions html-mode-expansions
css-mode-expansions er-basic-expansions expand-region-core
expand-region-custom mc-mark-more multiple-cursors-core rect web-mode
mhtml-mode css-mode js cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs sgml-mode ox-hugo
ox-blackfriday ox-md ox-minutes ox-twbs ox-reveal ox-html-fancybox
ox-latex ox-html table ox-ascii ox-publish ox drag-stuff info-look
two-column vc-annotate whitespace eieio-opt speedbar sb-image ezimage
dframe ace-window avy smex ido bug-reference warnings log-view
magit-submodule magit-obsolete magit-blame magit-stash magit-bisect
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-branch magit-files magit-refs magit-status magit magit-repos
magit-apply magit-wip misearch multi-isearch mm-archive network-stream
starttls url-http tls gnutls url-gw nsm url-cache url-auth paradox
paradox-menu paradox-commit-list paradox-execute paradox-github
paradox-core spinner xsos-fns sos-fns vc-mtn vc-hg org-table
markdown-mode eww mm-url gnus nnheader time-stamp vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs copyright cursor-sensor colir color counsel
esh-util swiper tabify org-datetree org-eldoc org-indent org-info
org-capture auto-complete-config setup-desktop header2 iso-transl
jka-compr fill-column-indicator conf-mode csh-mode sh-script smie
executable flycheck flymake auto-complete popup yasnippet tramp
tramp-compat tramp-loaddefs trampver ucs-normalize parse-time
minibuffer-line flyspell ispell which-key ivy-hydra ivy ivy-overlay ffap
ibuffer-projectile projectile grep ibuf-ext ibuffer ibuffer-loaddefs
hardcore-mode vc-git verilog-mode desktop frameset
setup-pragmata-ligatures setup-font-check smyx-theme diff-hl vc-dir vc
vc-dispatcher setup-misc saveplace setup-personal my-patches setup-meme
setup-work setup-windows-buffers mb-depth winner setup-unicode
setup-toggles setup-spell setup-search setup-registers setup-print
setup-pdf setup-navigation setup-mouse setup-launcher setup-image
setup-editing smart-mark unfill zop-to-char delsel setup-compile
setup-backup setup-yaml-mode setup-web-mode setup-verilog setup-toml
setup-hugo setup-tcl setup-sml setup-spice setup-shell setup-python
setup-perl setup-nim setup-matlab setup-markdown setup-latex
preview-latex tex-site auto-loads setup-elisp easy-escape setup-conf
setup-clojure setup-yasnippet setup-xkcd setup-writegood writegood-mode
setup-wrap-region wrap-region setup-wordnut setup-wolfram
setup-which-key setup-which-func which-func imenu setup-weather
setup-undo-tree undo-tree diff setup-tldr setup-tiny setup-term setup-sx
setup-smex setup-server setup-rainbow-mode setup-rainbow-delimiters
rainbow-delimiters setup-projectile setup-poporg setup-pomodoro
setup-pcache pcache eieio-base cl setup-page-break-lines disp-table
page-break-lines setup-outshine foldout outshine outshine-org-cmds
outorg org-sticky-header org-include-img-from-archive
org-include-img-from-pdf org-include-src-lines ob-org ob-latex ob-dot
ob-ditaa ob-plantuml ob-awk ob-python ob-shell org-link-ref elfeed-link
org-element elfeed-show elfeed-search bookmark pp shr svg dom elfeed-csv
elfeed elfeed-curl url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf mailcap elfeed-log elfeed-db
elfeed-lib url-util avl-tree url-queue browse-url xml-query xml org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs noutline outline
setup-orgstruct setup-org setup-news setup-neotree
setup-multiple-cursors setup-manage-minor-mode setup-linum nlinum linum
setup-kurecolor setup-keyfreq keyfreq setup-info info+ thingatpt
setup-indent-guide setup-imenu-list setup-ivy setup-ibuffer
setup-hungry-delete hungry-delete setup-htmlize setup-highlight hl-line+
hl-line volatile-highlights hi-lock setup-header2 setup-hardcore
setup-magit magit-log magit-diff smerge-mode diff-mode git-commit
recentf tree-widget log-edit message subr-x puny dired+ image-dired
image-mode image-file help-fns+ wid-edit help-fns radix-tree dired-aux
dired-x dired dired-loaddefs rfc822 mml mml-sec epa derived epg
gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader pcvs-util add-log magit-core
magit-autorevert autorevert filenotify magit-process with-editor shell
pcomplete server magit-margin magit-mode magit-git magit-section
magit-utils crm magit-popup async-bytecomp async format-spec
setup-git-timemachine setup-git-link setup-diff setup-gist
setup-flycheck setup-fold yafolding fold-this setup-fci
setup-expand-region setup-engine-mode engine-mode setup-el2markdown
setup-eww setup-emamux setup-elfeed setup-drag-stuff setup-dired
setup-deft setup-de-ansify setup-counsel setup-command-log-mode
setup-calc setup-buffer-move setup-bookmarks setup-beacon beacon
setup-auto-complete setup-artist setup-all setup-ag setup-ace-window
setup-abbrev setup-shackle shackle setup-visual generic setup-mode-line
smart-mode-line-dark-theme smart-mode-line rich-minority time setup-tags
ctags-update ggtags etags xref project compile comint ansi-color ewoc
pcase setup-hydra hydra ring lv setup-key-chord
setup-region-bindings-mode region-bindings-mode cl-extra help-mode
setup-paradox temp-mode modi-mode use-package-chords bind-chord
key-chord use-package diminish bind-key easy-mmode benchmark-init advice
setup-packages gh-common gh-profile rx s marshal eieio-compat ht json
map dash finder-inf info edmacro kmacro package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib general time-date paren cus-start
cus-load setup-var-overrides mule-util 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 menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 minibuffer 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 dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 1183215 148637)
 (symbols 48 67796 6)
 (miscs 40 3522 2777)
 (strings 32 513032 17874)
 (string-bytes 1 20726162)
 (vectors 16 107472)
 (vector-slots 8 2530595 135460)
 (floats 8 1157 1484)
 (intervals 56 11547 29183)
 (buffers 976 143)
 (heap 1024 296711 191906))

-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 10 Jul 2017 20:52:49 +0000
> 
> - I build emacs master on RHEL 6.6.
> - I access the RHEL machine via VNC on Windows 7 Enterprise (work)
> - Occasionally I would venture into Windows to get work email (Outlook) or to the Chrome browwer in
> Windows.
> - With the way my monitors are set up, one monitor would should the VNC window showing the emacs frame
> and another monitor would should Outlook.
> 
> Then as I would be working on something in Outlook, I would see from the corner of my eye that the line
> numbers disappeared from the emacs window with code in verilog-mode. Clicking again on the emacs frame
> (in VNC, remember) would bring the line numbers back.

When you say "line numbers disappeared", do you mean as if you set
display-line-numbers to nil, i.e. the text starts at the left edge of
the window?  Or do you mean that there's still the line-number field
to the left of the text, but it is empty instead of showing the
numbers?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Mon, Jul 10, 2017, 10:38 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> When you say "line numbers disappeared", do you mean as if you set
> display-line-numbers to nil, i.e. the text starts at the left edge of
> the window?


Yes. Exactly. And they reappear automatically too once that window is in
focus again.

I enable the line numbers via only major mode hooks, for some major modes.
I am not 100% sure but each time this has happened, probably one window had
a buffer with a major mode where the line numbers should be enabled, and
the other didn't (I normally work in a 2-window frame). But also, I have
never been able to recreate the problem.
-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 11 Jul 2017 03:43:07 +0000
> Cc: 27647@debbugs.gnu.org
> 
>  When you say "line numbers disappeared", do you mean as if you set
>  display-line-numbers to nil, i.e. the text starts at the left edge of
>  the window? 
> 
> Yes. Exactly. And they reappear automatically too once that window is in focus again. 

In that case, I suspect that some of your customizations somehow
temporarily reset display-line-numbers to nil.  You could try to use
Lisp watchpoints (see "Watching Variables" in the ELisp manual) for a
single buffer where this happens, to find out which code does that.

Alternatively, instrument your functions that reset
display-line-numbers to log messages to some buffer with useful
information, such as the Lisp backtrace, and when the problem happens,
examine the log for clues.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Tue, Jul 11, 2017 at 10:31 AM Eli Zaretskii <eliz@gnu.org> wrote:

> In that case, I suspect that some of your customizations somehow
> temporarily reset display-line-numbers to nil.  You could try to use
> Lisp watchpoints (see "Watching Variables" in the ELisp manual) for a
> single buffer where this happens, to find out which code does that.
>
> Alternatively, instrument your functions that reset
> display-line-numbers to log messages to some buffer with useful
> information, such as the Lisp backtrace, and when the problem happens,
> examine the log for clues.
>

I will set up the Lisp watchpoints and debug more, thanks.

I have one more data point. Apparently I do not need to "click" on the
emacs frame to make the line numbers reappear. They reappeared seemingly
randomly or just as I was just hovering the mouse over the emacs frame..
odd.  This happened just as I was preparing to record "line num
reappearance on click" effect, but the line numbers reappeared by
themselves even before I clicked.
-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Tue, Jul 11, 2017 at 10:38 AM Kaushal Modi <kaushal.modi@gmail.com>
wrote:

>
> I will set up the Lisp watchpoints and debug more, thanks.
>
> I have one more data point. Apparently I do not need to "click" on the
> emacs frame to make the line numbers reappear. They reappeared seemingly
> randomly or just as I was just hovering the mouse over the emacs frame..
> odd.  This happened just as I was preparing to record "line num
> reappearance on click" effect, but the line numbers reappeared by
> themselves even before I clicked.
>

This is what I see (I was able to record the moment when the lines
reappeared on clicking anywhere in the window):
http://i.imgur.com/5C5FmGS.gifv

When the above happened, the point was in a Fundamental Mode buffer window
and the other window had this file in emacs-lisp-mode. I do not have
display-line-numbers set to t globally; so fundamental-mode has that value
at nil and the elisp window had that set to t. Again the line num
disappearance happened when the emacs frame was out of focus.

Interestingly the variable watcher did not get triggered.

This is how I set the watcher:

=====
(defvar modi/variables-to-be-watched '(display-line-numbers)
  "List of variables to be watched.
Used by `modi/set-variable-watchers' and
`modi/unset-variable-watchers'")

(defun modi/variable-watcher-fn (symbol newval operation where)
  "Print message when the value of variable SYMBOL changes.
The message shows the NEWVAL it changed to, the OPERATION that
caused that, and the buffer WHERE that happened if the value
change was buffer-local."
  (message (format "[Watcher: %s] Now set to %S, by `%S'%s"
                   (symbol-name symbol)
                   newval
                   operation
                   (if where
                       (format " in %S" where)
                     ""))))

(defun modi/set-variable-watchers ()
  "Enable printing messages when any watched variable changes.
The variables to be watched should be added to
`modi/variables-to-be-watched'."
  (interactive)
  (dolist (var modi/variables-to-be-watched)
    (add-variable-watcher var #'modi/variable-watcher-fn)))

(modi/set-variable-watchers)
=====

When I revert-buffer in an emacs-lisp-mode file, I see these:

[Watcher: display-line-numbers] Now set to nil, by ‘makunbound’ in #<buffer
setup-linum.el>
[Watcher: display-line-numbers] Now set to nil, by ‘set’ in #<buffer
setup-linum.el>
[Watcher: display-line-numbers] Now set to t, by ‘set’ in #<buffer
setup-linum.el>

But none of those [Watcher:..] messages showed up when the line numbers
auto-disappeared and also when re-appeared on the click in the buffer.

Not sure if this would help, but here is how I enable the line numbers
(modified compared to the version I posted earlier in this thread):

=====
(defvar modi/native-linum-default t
  "Value set for `display-line-numbers' when enabled.
Valid values are t, `visual', `relative' and nil. See
`display-line-numbers' for more information.")

(defun modi/native-linum--on (&optional global)
  "Enable native line number display in the current buffer.
If GLOBAL is non-nil, enable this globally."
  (interactive "P")
  (if global
      (setq-default display-line-numbers modi/native-linum-default)
    (setq-local display-line-numbers modi/native-linum-default)))

(defun modi/native-linum--off (&optional global)
  "Disable native line number display in the current buffer.
If GLOBAL is non-nil, disable this globally."
  (interactive "P")
  (if global
      (setq-default display-line-numbers nil)
    (setq-local display-line-numbers nil)))

(defun modi/turn-on-native-linum ()
  "Turn on native line numbers in specific modes.
In enabled state, `display-line-numbers' is set to
`modi/native-linum-default'."
  (interactive)
  (if modi/linum-mode-enable-global
      (progn
        (dolist (hook modi/linum-mode-hooks)
          (remove-hook hook #'modi/native-linum--on))
        (modi/native-linum--on :global))
    (progn
      (modi/native-linum--off :global)
      (dolist (hook modi/linum-mode-hooks)
        (add-hook hook #'modi/native-linum--on)))))

(defun modi/linum--enable (&optional frame)
  "Set “linum” using the default package set by the user in
`modi/linum-fn-default'.

The optional FRAME argument is added as it is needed if this
function is added to the `after-make-frame-functions' hook."
  (modi/turn-on-native-linum))

(if (daemonp)
    (add-hook 'after-make-frame-functions #'modi/linum--enable)
  (add-hook 'after-init-hook #'modi/linum--enable))
=====

Does anything look problematic in the above code from a quick glance.


-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 11 Jul 2017 20:08:47 +0000
> Cc: 27647@debbugs.gnu.org
> 
> This is what I see (I was able to record the moment when the lines reappeared on clicking anywhere in the
> window): http://i.imgur.com/5C5FmGS.gifv
> 
> When the above happened, the point was in a Fundamental Mode buffer window and the other window had
> this file in emacs-lisp-mode. I do not have display-line-numbers set to t globally; so fundamental-mode has
> that value at nil and the elisp window had that set to t. Again the line num disappearance happened when the
> emacs frame was out of focus.
> 
> Interestingly the variable watcher did not get triggered.

I guess the variable gets changed by one of the ways that Lisp-level
watchers cannot catch.

> Does anything look problematic in the above code from a quick glance.

Not at a glance.  But the key to this mystery is most probably in your
customizations.  Some code which probably runs off a timer or some X
event does something that directly or indirectly resets the variable
in that buffer.  Maybe you have some code which directly or indirectly
calls kill-all-local-variables, for example.  Or something else to
that effect.

You could add logging to your functions that turn off the line
numbers, and see what's in the log when this happens.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

Hello,

On Wed, Jul 12, 2017 at 10:44 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Not at a glance.  But the key to this mystery is most probably in your
> customizations.  Some code which probably runs off a timer or some X
> event does something that directly or indirectly resets the variable
> in that buffer.  Maybe you have some code which directly or indirectly
> calls kill-all-local-variables, for example.  Or something else to
> that effect.
>

I am still trying to find out what is doing that if something is doing
that. Unfortunately no message statement inserted anywhere in my native
linum enabling code is getting executed when this anomaly happens.


> You could add logging to your functions that turn off the line
> numbers, and see what's in the log when this happens.
>

None of those message statements gets triggered.

I have a feeling that this is happening due to some state change at
system/GTK2 level.. because no messages in elisp are catching the line
number toggling, and this happens when I move the focus out of the VNC
viewer window to Windows. When I return to the VNC viewer and click on the
window with the missing line numbers, they show up magically.

You would have a better idea if there are any hooks in display engine that
get affected by GTK..

-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 19 Jul 2017 15:13:31 +0000
> Cc: 27647@debbugs.gnu.org
> 
> I am still trying to find out what is doing that if something is doing that. Unfortunately no message statement
> inserted anywhere in my native linum enabling code is getting executed when this anomaly happens.
> 
>  You could add logging to your functions that turn off the line
>  numbers, and see what's in the log when this happens.
> 
> None of those message statements gets triggered.

I'd begin by removing your line-number setup and replacing it with a
much simpler one, which doesn't involve linum/nlinum, and instead
simply sets display-line-numbers.

If that doesn't help, I'd go on bisecting your customizations.

Alternatively, a reproducing recipe would be useful.

> You would have a better idea if there are any hooks in display engine that get affected by GTK..

None that I know of, sorry, not hooks which could somehow reset an
Emacs Lisp variable.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Noam Postavsky]

On Wed, Jul 12, 2017 at 10:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Kaushal Modi <kaushal.modi@gmail.com>
>> Date: Tue, 11 Jul 2017 20:08:47 +0000
>> Cc: 27647@debbugs.gnu.org
>>
>> This is what I see (I was able to record the moment when the lines reappeared on clicking anywhere in the
>> window): http://i.imgur.com/5C5FmGS.gifv
>>
>> When the above happened, the point was in a Fundamental Mode buffer window and the other window had
>> this file in emacs-lisp-mode. I do not have display-line-numbers set to t globally; so fundamental-mode has
>> that value at nil and the elisp window had that set to t. Again the line num disappearance happened when the
>> emacs frame was out of focus.
>>
>> Interestingly the variable watcher did not get triggered.
>
> I guess the variable gets changed by one of the ways that Lisp-level
> watchers cannot catch.

Perhaps 'watch Vdisplay_line_numbers' in gdb would help?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 19 Jul 2017 13:52:28 -0400
> Cc: Kaushal Modi <kaushal.modi@gmail.com>, 27647@debbugs.gnu.org
> 
> Perhaps 'watch Vdisplay_line_numbers' in gdb would help?

I thought about that, but I'm afraid it could cause an infinite series
of unrelated hits, each time Kaushal switches between buffers.  It may
make editing impractical.

But if I'm mistaken, why not?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, frame out of focus

[jonas]

I can replicate this behavior using flycheck and flycheck-pos-tip enabled.
Place mark at anything marked with a squiggly line, wait for the pop up, 
1-2 seconds later
line numbers disappear.

Using  GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 
3.18.9) of 2017-07-17

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, frame out of focus

[Eli Zaretskii]

> From: jonas <jonaswestlund101@gmail.com>
> Date: Fri, 21 Jul 2017 19:49:19 +0200
> 
> I can replicate this behavior using flycheck and flycheck-pos-tip enabled.
> Place mark at anything marked with a squiggly line, wait for the pop up, 
> 1-2 seconds later
> line numbers disappear.

Can you provide a detailed recipe, please?  I don't use flycheck, so I
don't think I understand how to reproduce the problem.

Thanks.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Wed, Jul 19, 2017 at 2:10 PM Eli Zaretskii <eliz@gnu.org> wrote:

> I thought about that, but I'm afraid it could cause an infinite series
> of unrelated hits, each time Kaushal switches between buffers.  It may
> make editing impractical.
>
> But if I'm mistaken, why not?
>

Hi Eli, Noam,

As you know from my other thread, I am unable to use gdb. As I don't know
enough C to hack it myself, can you provide pointers to where I can put
print statements or something like that in the C code directly to help with
this debug?

Another thing, debbugs seems to have stopped emailing the bug authors!

Emails sent to just this debbugs don't reach me, like this reply[1] or
this[2]. Can you guys please CC me on further replies?

@Jonas: Any luck creating a recipe for this?

@Eli: This problem is consistent, though not consistent enough to yet
create a recipe. But it does happen at least once a day. I am still
sticking on to native line numbers and not giving up. Can this be please
made a blocker for 26.1?


[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27647#38
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27647#39
-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[jonas]

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

Unfortunately, no. The issue is consistent, but I had difficulties 
creating a detailed recipe for it.

For me, the issue was limited to flycheck-pos-tip which interacts with 
the windowing system through the pos-tip package. No modification of 
display-line-numbers took place.

I ended up replacing the package with flycheck-popup-tip, which displays 
its information inside an emacs buffer, and the problem disappeared. So 
at a glance the issue seem to be deeper than just being config-related, 
but I am not knowledgeable enough to draw any real conclusions.


On 2017-10-05 14:40, Kaushal Modi wrote:
> On Wed, Jul 19, 2017 at 2:10 PM Eli Zaretskii <eliz@gnu.org 
> <mailto:eliz@gnu.org>> wrote:
>
>     I thought about that, but I'm afraid it could cause an infinite series
>     of unrelated hits, each time Kaushal switches between buffers.  It may
>     make editing impractical.
>
>     But if I'm mistaken, why not?
>
>
> Hi Eli, Noam,
>
> As you know from my other thread, I am unable to use gdb. As I don't 
> know enough C to hack it myself, can you provide pointers to where I 
> can put print statements or something like that in the C code directly 
> to help with this debug?
>
> Another thing, debbugs seems to have stopped emailing the bug authors!
>
> Emails sent to just this debbugs don't reach me, like this reply[1] or 
> this[2]. Can you guys please CC me on further replies?
>
> @Jonas: Any luck creating a recipe for this?
>
> @Eli: This problem is consistent, though not consistent enough to yet 
> create a recipe. But it does happen at least once a day. I am still 
> sticking on to native line numbers and not giving up. Can this be 
> please made a blocker for 26.1?
>
>
> [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27647#38
> [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27647#39
> -- 
>
> Kaushal Modi
>


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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 05 Oct 2017 12:40:35 +0000
> Cc: 27647@debbugs.gnu.org, jonaswestlund101@gmail.com
> 
> As you know from my other thread, I am unable to use gdb. As I don't know enough C to hack it myself, can
> you provide pointers to where I can put print statements or something like that in the C code directly to help
> with this debug?

I couldn't think of anything useful.  Which is not surprising, as I
have no idea what could be involved in this.

> @Eli: This problem is consistent, though not consistent enough to yet create a recipe. But it does happen at
> least once a day. I am still sticking on to native line numbers and not giving up. Can this be please made a
> blocker for 26.1?

I don't think it's an Emacs bug.  It's most probably something related
to some hook or timer that you set up in your customizations.  That's
the only way a frame without a focus could get redrawn.  So please
look through all of your customizations to find the one that is
responsible.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 27647@debbugs.gnu.org, jonaswestlund101@gmail.com,
> 	npostavs@users.sourceforge.net
> 
> It's most probably something related to some hook or timer that you
> set up in your customizations.

Or maybe some feature calls kill-all-local-variables, but doesn't
restore display-line-numbers until later.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Romanos Skiadas]

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



On 05/10/17 14:39, Eli Zaretskii wrote:
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 27647@debbugs.gnu.org, jonaswestlund101@gmail.com,
>> 	npostavs@users.sourceforge.net
>>
>> It's most probably something related to some hook or timer that you
>> set up in your customizations.
> Or maybe some feature calls kill-all-local-variables, but doesn't
> restore display-line-numbers until later.
>
>
>
I have been seeing this problem for a while due to something happening 
with flycheck-pos-tip, like in the original report. I disabled the 
package, but today I started seeing it (or could it be something 
different?) again in a buffer. It's far from a recipe, but I was seeing 
this:

- In a buffer, the line numbers looked like attached screenshot (1)
- in a buffer, I pressed any combination of keys that would cause 
which-key to pop up
- I pressed C-g to close which-key. At this point, the line numbers 
would look like screenshot (2). They don't go away per se, it looks like 
something goes wrong in some calculation maybe?
- Pressing C-g restored the line numbers to state (1)

I played with adding debug-watch to a couple of variables, this was a 
few hours ago so I only remember I did it with display-line-numbers and 
nothing showed up. I also did debug-on-entry on 
kill-all-local-variables, it never gets called.

After playing with the buffer for a while, I found out that this 
behaviour goes away with git-gutter-mode disabled. I'll find some time 
to try to get something reproducible with stock Emacs within the next 
couple of days.

@Eli, I still have the buffer around and can try out things. Do you have 
any debugging hints for this?

Best,
Romanos

[-- Attachment #2: line_numbers_2.png --]
[-- Type: image/png, Size: 1079 bytes --]

[-- Attachment #3: line_numbers_1.png --]
[-- Type: image/png, Size: 9443 bytes --]

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Cc: 27647@debbugs.gnu.org, jonaswestlund101@gmail.com,
>  npostavs@users.sourceforge.net
> From: Romanos Skiadas <rom.skiad@gmail.com>
> Date: Thu, 5 Oct 2017 23:17:30 +0100
> 
> - In a buffer, the line numbers looked like attached screenshot (1)
> - in a buffer, I pressed any combination of keys that would cause 
> which-key to pop up
> - I pressed C-g to close which-key. At this point, the line numbers 
> would look like screenshot (2). They don't go away per se, it looks like 
> something goes wrong in some calculation maybe?
> - Pressing C-g restored the line numbers to state (1)

This is not "line numbers disappearing", this is something else.  Can
you show a larger portion of the window, including the text to the
right of the numbers in the 2nd case?

> After playing with the buffer for a while, I found out that this 
> behaviour goes away with git-gutter-mode disabled. I'll find some time 
> to try to get something reproducible with stock Emacs within the next 
> couple of days.

Thanks.  I tried loading git-gutter, but saw no problems with line
numbers.  So I guess it isn't just that package, but some interaction
between it and other packages.

> @Eli, I still have the buffer around and can try out things. Do you have 
> any debugging hints for this?

I might have ideas once I see a larger view of the problematic
display.  E.e., where there any display margins to the left of the
numbers?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Romanos Skiadas]

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



On 05/10/17 14:10, Eli Zaretskii wrote:
>> From: Kaushal Modi <kaushal.modi@gmail.com>
>> Date: Thu, 05 Oct 2017 12:40:35 +0000
>> Cc: 27647@debbugs.gnu.org, jonaswestlund101@gmail.com
>>
>> As you know from my other thread, I am unable to use gdb. As I don't know enough C to hack it myself, can
>> you provide pointers to where I can put print statements or something like that in the C code directly to help
>> with this debug?
> I couldn't think of anything useful.  Which is not surprising, as I
> have no idea what could be involved in this.
>
>> @Eli: This problem is consistent, though not consistent enough to yet create a recipe. But it does happen at
>> least once a day. I am still sticking on to native line numbers and not giving up. Can this be please made a
>> blocker for 26.1?
> I don't think it's an Emacs bug.  It's most probably something related
> to some hook or timer that you set up in your customizations.  That's
> the only way a frame without a focus could get redrawn.  So please
> look through all of your customizations to find the one that is
> responsible.
Evil is very probably doing something funky like this. I started seeing 
line-numbers disappearing completely again, not partially as I mentioned 
at some point in the thread, with flycheck-pos-tip disabled. Turns out 
it was some interaction between flyspell's overlays & evil. A recipe to 
reliably reproduce this with evil is:

echo "foo" > /tmp/test.txt

(cd /tmp && git clone https://github.com/emacs-evil/evil)

Add this to a file, eg /tmp/test-init.el:

    (add-hook 'text-mode-hook (lambda () (display-line-numbers-mode)))
    (add-to-list 'load-path "/tmp/evil")
    (require 'evil)
    (evil-mode 1)


  emacs -Q -l /tmp/test-init.el /tmp/test.txt

Put this in the test.txt buffer an eval it:
(let ((overlay (make-overlay 1 6 nil t nil))) ;; flyspell does this on 
misspelled words
   (overlay-put overlay 'help-echo "a"))

Make sure you are in normal more (press ESC)
Move the mouse above the f at the start of the buffer and hover until 
the "a" shows up.
Click and drag along toward to end of the line. The line numbers 
consistently go away with this recipe for me.

I'll start dissecting evil to see what causes this.

Best,
Romanos

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Cc: 27647@debbugs.gnu.org, jonaswestlund101@gmail.com,
>  npostavs@users.sourceforge.net
> From: Romanos Skiadas <rom.skiad@gmail.com>
> Date: Wed, 11 Oct 2017 21:32:06 +0100
> 
> echo "foo" > /tmp/test.txt
> 
> (cd /tmp && git clone https://github.com/emacs-evil/evil)
> 
> Add this to a file, eg /tmp/test-init.el:
> 
>  (add-hook 'text-mode-hook (lambda () (display-line-numbers-mode)))
>  (add-to-list 'load-path "/tmp/evil")
>  (require 'evil)
>  (evil-mode 1)
> 
>  emacs -Q -l /tmp/test-init.el /tmp/test.txt
> 
> Put this in the test.txt buffer an eval it:
> (let ((overlay (make-overlay 1 6 nil t nil))) ;; flyspell does this on misspelled words
>   (overlay-put overlay 'help-echo "a"))
> 
> Make sure you are in normal more (press ESC)
> Move the mouse above the f at the start of the buffer and hover until the "a" shows up.
> Click and drag along toward to end of the line. The line numbers consistently go away with this recipe for me.

Doesn't happen here with the latest emacs-26 branch.  Are you using
that branch, or are you using some other code base for Emacs?

(I didn't clone the evil Git repository; instead, I downloaded a zip
archive and unpacked it on my system.  I don't think it should
matter.)

Can you tell the details of your build?  If it's a GTK build, does the
problem go away if you tell Emacs to use non-GTK tooltips (by setting
x-gtk-use-system-tooltips to nil), or if you turn off scroll-bar-mode?

> I'll start dissecting evil to see what causes this.

Thanks.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Romanos Skiadas]

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

Hi Eli,

See inline.


On 12/10/17 09:29, Eli Zaretskii wrote:
>> Cc:27647@debbugs.gnu.org,jonaswestlund101@gmail.com,
>>   npostavs@users.sourceforge.net
>> From: Romanos Skiadas<rom.skiad@gmail.com>
>> Date: Wed, 11 Oct 2017 21:32:06 +0100
>>
>> echo "foo" > /tmp/test.txt
>>
>> (cd /tmp && git clonehttps://github.com/emacs-evil/evil)
>>
>> Add this to a file, eg /tmp/test-init.el:
>>
>>   (add-hook 'text-mode-hook (lambda () (display-line-numbers-mode)))
>>   (add-to-list 'load-path "/tmp/evil")
>>   (require 'evil)
>>   (evil-mode 1)
>>
>>   emacs -Q -l /tmp/test-init.el /tmp/test.txt
>>
>> Put this in the test.txt buffer an eval it:
>> (let ((overlay (make-overlay 1 6 nil t nil))) ;; flyspell does this on misspelled words
>>    (overlay-put overlay 'help-echo "a"))
>>
>> Make sure you are in normal more (press ESC)
>> Move the mouse above the f at the start of the buffer and hover until the "a" shows up.
>> Click and drag along toward to end of the line. The line numbers consistently go away with this recipe for me.
> Doesn't happen here with the latest emacs-26 branch.  Are you using
> that branch, or are you using some other code base for Emacs?
I used Emacs26@078fb7f6df4178d5a35243dad164cdd196392e71
> (I didn't clone the evil Git repository; instead, I downloaded a zip
> archive and unpacked it on my system.  I don't think it should
> matter.)
As long at that is the latest evil, which is what I tested with, that 
shouldn't matter
> Can you tell the details of your build?  If it's a GTK build, does the
> problem go away if you tell Emacs to use non-GTK tooltips (by setting
> x-gtk-use-system-tooltips to nil), or if you turn off scroll-bar-mode?
>
It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil 
does indeed make this problem go away. I've set it to nil on my init 
file for now.

The list of configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LCMS2

>> I'll start dissecting evil to see what causes this.
> Thanks.

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Romanos Skiadas <rom.skiad@gmail.com>
> Cc: kaushal.modi@gmail.com, 27647@debbugs.gnu.org,
>  jonaswestlund101@gmail.com, npostavs@users.sourceforge.net
> Date: Thu, 12 Oct 2017 20:30:51 +0100
> 
> Can you tell the details of your build?  If it's a GTK build, does the
> problem go away if you tell Emacs to use non-GTK tooltips (by setting
> x-gtk-use-system-tooltips to nil), or if you turn off scroll-bar-mode?
> 
> It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil does indeed make this problem go away.

What about disabling scroll-bar-mode, while leaving the GTK tooltips
in use -- does that also make the problem go away?

Thanks.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Romanos Skiadas]

On 13/10/17 09:33, Eli Zaretskii wrote:
>> From: Romanos Skiadas <rom.skiad@gmail.com>
>> Cc: kaushal.modi@gmail.com, 27647@debbugs.gnu.org,
>>   jonaswestlund101@gmail.com, npostavs@users.sourceforge.net
>> Date: Thu, 12 Oct 2017 20:30:51 +0100
>>
>> Can you tell the details of your build?  If it's a GTK build, does the
>> problem go away if you tell Emacs to use non-GTK tooltips (by setting
>> x-gtk-use-system-tooltips to nil), or if you turn off scroll-bar-mode?
>>
>> It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil does indeed make this problem go away.
> What about disabling scroll-bar-mode, while leaving the GTK tooltips
> in use -- does that also make the problem go away?
>
> Thanks.
Just checked, still shows up with scroll-bar-mode disabled and the 
tooltips in use.

Best,
Romanos

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Cc: kaushal.modi@gmail.com, 27647@debbugs.gnu.org,
>  jonaswestlund101@gmail.com, npostavs@users.sourceforge.net
> From: Romanos Skiadas <rom.skiad@gmail.com>
> Date: Fri, 13 Oct 2017 19:14:10 +0100
> 
> >> It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil does indeed make this problem go away.
> > What about disabling scroll-bar-mode, while leaving the GTK tooltips
> > in use -- does that also make the problem go away?
> >
> > Thanks.
> Just checked, still shows up with scroll-bar-mode disabled and the 
> tooltips in use.

What if you turn on display-line-numbers globally -- does the problem
persist in that case with your default settings for GTK tooltips?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 >> It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil does indeed make this problem go away.
 >
 > What about disabling scroll-bar-mode, while leaving the GTK tooltips
 > in use -- does that also make the problem go away?

What were your thoughts here?  That clearing the scroll bar area would
erase the line numbers?

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Sat, 14 Oct 2017 10:36:07 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 27647@debbugs.gnu.org, kaushal.modi@gmail.com, 
>  jonaswestlund101@gmail.com, npostavs@users.sourceforge.net
> 
>  >> It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil does indeed make this problem go away.
>  >
>  > What about disabling scroll-bar-mode, while leaving the GTK tooltips
>  > in use -- does that also make the problem go away?
> 
> What were your thoughts here?  That clearing the scroll bar area would
> erase the line numbers?

I was trying to establish what was different from my build that caused
the numbers to disappear.  When there's a GTK scroll bar, redisplay
causes the frame's garbaged flag be set, which is something I could
try emulating here under a debugger.

Not sure what GTK tooltips have to do with this, as AFAICS displaying
a GTK tooltip shouldn't trigger redisplay.

To make line numbers disappear, some code has to trigger redisplay
with display-line-numbers somehow reset to nil.  If you can reproduce
the recipe posted by Romanos, then please try finding the code which
resets that variable, perhaps by making a different buffer current or
something.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > To make line numbers disappear, some code has to trigger redisplay
 > with display-line-numbers somehow reset to nil.

Buffer-locally.  I suppose this will become clear as soon as the OP has
tested your "What if you turn on display-line-numbers globally".

In either case it seems that we do something subtly different when
processing GTK and native tooltips.  Since AFAICT the GTK tooltip
related code does not change the internal (frame-, display-related)
state of Emacs I can only think of the native tooltip code doing
something which prevents the OP's behavior from happening.  But I've
found nothing supporting such a claim in ‘x-show-tip’.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Sun, Oct 15, 2017, 5:39 AM martin rudalics <rudalics@gmx.at> wrote:

>  > To make line numbers disappear, some code has to trigger redisplay
>  > with display-line-numbers somehow reset to nil.
>
> Buffer-locally.  I suppose this will become clear as soon as the OP has
> tested your "What if you turn on display-line-numbers globally".
>

Hello all,

I have yet to try setting display-line-numbers globally.

The issue hasn't repeated in the past few days .. I'd hate if this has to
do with me restarting my machine. (As a side: My machine had an uptime of
about a year, and I restarting it fixed the problem that gdb wasn't able to
access ptrace. The whole reason I wanted that to work was to use gdb to
debug this problem when it occurred next.)

After the machine restart, the gdb issue resolved, and this line
disappearing issue also "seems" to have.. disappeared.

But I cannot say with confidence that this issue wouldn't repeat again, as
I haven't yet figured out what exactly caused that.

So if I now enable the line numbers globally, I won't be able to tell if
that prevented that issue from repeating, or my machine restart already
took care of that.

Let me see if this issue repeats in the next week with my current config.

> --

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Sun, 15 Oct 2017 11:39:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rom.skiad@gmail.com, 27647@debbugs.gnu.org, kaushal.modi@gmail.com, 
>  jonaswestlund101@gmail.com, npostavs@users.sourceforge.net
> 
>  > To make line numbers disappear, some code has to trigger redisplay
>  > with display-line-numbers somehow reset to nil.
> 
> Buffer-locally.

Yes.

> I suppose this will become clear as soon as the OP has
> tested your "What if you turn on display-line-numbers globally".

Yes, that's the reason for that request.

> In either case it seems that we do something subtly different when
> processing GTK and native tooltips.

Indeed, the processing is very different (unsurprisingly).

> Since AFAICT the GTK tooltip related code does not change the
> internal (frame-, display-related) state of Emacs I can only think
> of the native tooltip code doing something which prevents the OP's
> behavior from happening.  But I've found nothing supporting such a
> claim in ‘x-show-tip’.

Neither did I.  In fact, the GTK code is much simpler, and I cannot
for a moment figure out how it could have switched buffers behind our
back (if that's what happens in this scenario).

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Romanos Skiadas]

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



On 14/10/17 08:47, Eli Zaretskii wrote:
>> Cc: kaushal.modi@gmail.com, 27647@debbugs.gnu.org,
>>   jonaswestlund101@gmail.com, npostavs@users.sourceforge.net
>> From: Romanos Skiadas <rom.skiad@gmail.com>
>> Date: Fri, 13 Oct 2017 19:14:10 +0100
>>
>>>> It is indeed a GTK3 build and setting x-gtk-use-system-tooltips to nil does indeed make this problem go away.
>>> What about disabling scroll-bar-mode, while leaving the GTK tooltips
>>> in use -- does that also make the problem go away?
>>>
>>> Thanks.
>> Just checked, still shows up with scroll-bar-mode disabled and the
>> tooltips in use.
> What if you turn on display-line-numbers globally -- does the problem
> persist in that case with your default settings for GTK tooltips?

Nope, still a problem with this init file:
(global-display-line-numbers-mode)
(add-to-list 'load-path "~/Code/evil")
(require 'evil)
(evil-mode 1)
(add-hook 'text-mode-hook 'flyspell-mode) ;; don't have to create the 
overlay manually

$ emacs -Q -l /txt/config.el /tmp/foo.txt

I spent some time looking into evil and tracked the problem in these 
lines of the function that is bound to [mouse-1]:

https://github.com/emacs-evil/evil/blob/89ab1e2ae5e59140bab4f8509b9e4c336ba375ea/evil-commands.el#L4225
https://github.com/emacs-evil/evil/blob/89ab1e2ae5e59140bab4f8509b9e4c336ba375ea/evil-commands.el#L4245

They call this function that moves point and mark:
https://github.com/emacs-evil/evil/blob/89ab1e2ae5e59140bab4f8509b9e4c336ba375ea/evil-commands.el#L4304
which as the comment says is just a copy of 
mouse--drag-set-mark-and-point Is this in any way helpful?

I'm playing with the debugger now so I might have something more useful 
later.

Best,
Romanos

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Sun, Oct 15, 2017 at 9:25 AM Kaushal Modi <kaushal.modi@gmail.com> wrote:

>
> The issue hasn't repeated in the past few days .. I'd hate if this has to
> do with me restarting my machine. (As a side: My machine had an uptime of
> about a year, and I restarting it fixed the problem that gdb wasn't able to
> access ptrace. The whole reason I wanted that to work was to use gdb to
> debug this problem when it occurred next.)
>
> After the machine restart, the gdb issue resolved, and this line
> disappearing issue also "seems" to have.. disappeared.
>

Nope, it is back!

Thanks to Romanos, I tried to see if this issue had anything to do with
tooltips and it almost always happens when hovering mouse over stuff in
modeline, waiting for tooltips to appear.

I have yet to find a recipe from emacs -Q, but below is a GIF recording:

==> https://i.imgur.com/kB6gHDk.gifv <==

- Hovering mouse for tool-tips makes the line nums disappear (only for some
tooltips though)
- Clicking anywhere in the buffer brings the line nums back

I do that a couple of times in that GIF.

@Eli: About setting display-line-numbers globally, that did not help..

I evaluated:

    (setq-default display-line-numbers t)

(So now even fundamental-mode buffers have line numbers.)

But even after, the hover-over-modeline magic trick faithfully reproduces
this issue at least on my config.

Now, I will try to cook an emacs -Q recipe.

=====
Latest emacs version info (Note that I am on RHEL 6.6, GTK2):

Emacs version: GNU Emacs 26.0.90 (build 4, x86_64-pc-linux-gnu, GTK+
Version 2.24.23)
 of 2017-10-16, built using commit 16e85456e70174f1d97fc5a7cd8a199b8f0e7e70.

./configure options:
  --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/emacs-26
'--program-transform-name=s/^ctags$/ctags_emacs/'
'CPPFLAGS=-I/home/kmodi/usr_local/6/include -I/usr/include/freetype2
-I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0'
'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64
-ggdb3'

Features:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK2 X11 MODULES
-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > I have yet to find a recipe from emacs -Q, but below is a GIF recording:
 >
 > ==> https://i.imgur.com/kB6gHDk.gifv <==

Apparently you move the mouse to some strange glyph on your mode line.
Which one is that?  Other mode lines elements do not seem to cause it.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Tue, 17 Oct 2017 10:59:15 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 27647@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, 
>  jonaswestlund101@gmail.com, npostavs@users.sourceforge.net, 
>  rom.skiad@gmail.com
> 
>  > ==> https://i.imgur.com/kB6gHDk.gifv <==
> 
> Apparently you move the mouse to some strange glyph on your mode line.
> Which one is that?  Other mode lines elements do not seem to cause it.

Actually, it looks like the numbers disappear when the mouse is on
parts of the mode line devoid of any glyphs.  Kaushal, did you
actually click on those empty parts, or just having the mouse hover
over them causes the numbers to disappear.

And does the problem go away if you disable GTK tooltips in favor of
the native tooltips?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Tue, Oct 17, 2017 at 10:48 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Actually, it looks like the numbers disappear when the mouse is on
> parts of the mode line devoid of any glyphs.


It happens actually when I move the mouse from one glyph to another. Now it
is not always repeatable to the point that this always happens if I move
the mouse from glyph X to glyph Y. But I can reproduce by doing this:
"frantically keep on moving the mouse across all the minor mode lighters
(which I have modified to be a single unicode char each)".

Kaushal, did you actually click on those empty parts, or just having the
> mouse hover
> over them causes the numbers to disappear.
>

No, just hover. In that GIF, you will see a small ripple appear around the
mouse pointer when I click.. you see that when I click anywhere in the
buffer to restore the line numbers.


> And does the problem go away if you disable GTK tooltips in favor of
> the native tooltips?
>

Yes! I believe the problem goes away if I set x-gtk-use-system-tooltips to
nil.
-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Tue, Oct 17, 2017 at 4:59 AM martin rudalics <rudalics@gmx.at> wrote:

> Apparently you move the mouse to some strange glyph on your mode line.
> Which one is that?  Other mode lines elements do not seem to cause it.
>

Actually just before emailing this, I verified that I can reproduce this
problem by even hover the mouse over "-master" (see the attached image),
then over to the major mode lighter "Emacs-Lisp" and then back to
"-master". The problem does not happen every time. But if I keep on moving
the mouse hover between those 2 things.. may be a dozen times, this problem
surely repeats.

Again, this problem happens only when x-gtk-use-system-tooltips is set to t.

[image: image.png]

-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 1321 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 4234 bytes --]

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 17 Oct 2017 15:13:01 +0000
> Cc: 27647@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, jonaswestlund101@gmail.com, 
> 	npostavs@users.sourceforge.net, rom.skiad@gmail.com
> 
> Again, this problem happens only when x-gtk-use-system-tooltips is set to t.

So somehow, popping up and/or down the GTK tooltip causes a redisplay
cycle with display-line-numbers disabled.  If someone with a GTK build
can catch such a redisplay in a debugger and show a backtrace, that
would probably allow us to move forward.

Thanks.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Alex]

I coincidentally stumbled across an easy recipe for this bug (or at
least a similar bug):

M-: (setq display-line-numbers t)
M-: (setq mouse-drag-and-drop-region t)

Then select a region, click on it (mouse-1), and drag the mouse. The
line numbers will disappear until you release the mouse.

Hopefully you can reproduce this on your end this time, Eli. To be
clear, this is with a GTK build.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Alex]

Alex <agrambot@gmail.com> writes:

> I coincidentally stumbled across an easy recipe for this bug (or at
> least a similar bug):
>
> M-: (setq display-line-numbers t)
> M-: (setq mouse-drag-and-drop-region t)
>
> Then select a region, click on it (mouse-1), and drag the mouse. The
> line numbers will disappear until you release the mouse.
>
> Hopefully you can reproduce this on your end this time, Eli. To be
> clear, this is with a GTK build.

Sorry, I should have also mentioned that this is indeed only the case
when x-gtk-use-system-tooltips is non-nil.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Noam Postavsky]

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

tags 27647 + patch
quit

Alex <agrambot@gmail.com> writes:

> Alex <agrambot@gmail.com> writes:
>
>> I coincidentally stumbled across an easy recipe for this bug (or at
>> least a similar bug):
>>
>> M-: (setq display-line-numbers t)
>> M-: (setq mouse-drag-and-drop-region t)
>>
>> Then select a region, click on it (mouse-1), and drag the mouse. The
>> line numbers will disappear until you release the mouse.
>>
>> Hopefully you can reproduce this on your end this time, Eli. To be
>> clear, this is with a GTK build.
>
> Sorry, I should have also mentioned that this is indeed only the case
> when x-gtk-use-system-tooltips is non-nil.

Aha, the problem is this condition in should_produce_line_number:

    static bool
    should_produce_line_number (struct it *it)
    {
      ...
      /* Don't display line number in tooltip frames.  */
      if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame))
        return false;

Which sounds like it would be correct, except that the meaning of
tip_frame is different for GTK tooltips, as explained in x_hide_tip:

    static Lisp_Object
    x_hide_tip (bool delete)
    {
    ...
    #ifdef USE_GTK
          {
        /* When using system tooltip, tip_frame is the Emacs frame on
           which the tip is shown.  */
        struct frame *f = XFRAME (tip_frame);

Implemented in Fx_show_tip:

    DEFUN ("x-show-tip", Fx_show_tip, Sx_show_tip, 1, 6, 0,
    ...
      f = decode_window_system_frame (frame);
    ...
    #ifdef USE_GTK
      if (x_gtk_use_system_tooltips)
        {
              ...
               /* This is used in Fx_hide_tip.  */
              XSETFRAME (tip_frame, f);

Leading to the following patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 871 bytes --]

From de99bf6af06aba4659740b8f3d892ff5db5bce03 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 8 Nov 2017 21:45:28 -0500
Subject: [PATCH v1] Fix line number display when using gtk tooltips
 (Bug#27647)

* src/xdisp.c (should_produce_line_number): Don't check tip_frame when
using gtk tooltips.
---
 src/xdisp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/xdisp.c b/src/xdisp.c
index 69b74dc629..3b75811cc3 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -21126,7 +21126,8 @@ should_produce_line_number (struct it *it)
 
 #ifdef HAVE_WINDOW_SYSTEM
   /* Don't display line number in tooltip frames.  */
-  if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame))
+  if (!x_gtk_use_system_tooltips
+      && FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame))
     return false;
 #endif
 
-- 
2.11.0

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > Which sounds like it would be correct, except that the meaning of
 > tip_frame is different for GTK tooltips, as explained in x_hide_tip:
 >
 >      static Lisp_Object
 >      x_hide_tip (bool delete)
 >      {
 >      ...
 >      #ifdef USE_GTK
 >            {
 >          /* When using system tooltip, tip_frame is the Emacs frame on
 >             which the tip is shown.  */
 >          struct frame *f = XFRAME (tip_frame);

Good catch!  And yes, we wouldn't have had that problem if we had left
in (parts of) the code Dmitry Antipov installed some time ago where "The
goal was to avoid tricky global variables".

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Kaushal Modi]

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

On Wed, Nov 8, 2017 at 9:49 PM Noam Postavsky <
npostavs@users.sourceforge.net> wrote:

> Leading to the following patch:
>

Thanks for the fix! It works! Woohoo! :D

It was a nasty bug, very visually disorienting, very difficult to reproduce
in the beginning, but ironically got fixed by 1 line.

Thanks for spending time to debug this and come up with that crucial fix.
Did any of the within-emacs debug tactics help you figure this out? Or was
it putting breakpoints and catching them in gdb? Or did you go the final
hard way, and review the code manually?

Also thanks to everyone who helped figure out a recipe, which is equally
important :).
-- 

Kaushal Modi

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

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Thu, 09 Nov 2017 08:28:55 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 27647@debbugs.gnu.org, Kaushal Modi <kaushal.modi@gmail.com>
> 
> And yes, we wouldn't have had that problem if we had left in (parts
> of) the code Dmitry Antipov installed some time ago where "The goal
> was to avoid tricky global variables".

What changes did you allude to here?  Can you point me to them?

In general, using the same variable for two different purposes is
exactly what I was talking about in the discussion of
wait_reading_process_output discussion -- who could possibly keep all
such factoids in memory, and avoid making such subtle mistakes as
result?

I also wonder whether other places which seem to be similarly
vulnerable hide bugs.  For example, what about frame-list:

  DEFUN ("frame-list", Fframe_list, Sframe_list,
	 0, 0, 0,
	 doc: /* Return a list of all live frames.  */)
    (void)
  {
    Lisp_Object frames;
    frames = Fcopy_sequence (Vframe_list);
  #ifdef HAVE_WINDOW_SYSTEM
    if (FRAMEP (tip_frame))
      frames = Fdelq (tip_frame, frames);
  #endif
    return frames;
  }

Does this mean that in a GTK build, at some "opportune moment",
frame-list will omit one frame from the list it returns, because that
frame happens to show a tooltip at that very moment?

Or what about a similar snippet in x-display-monitor-attributes-list?
Is it in trouble as well?

IOW, instead a simple variable with a clear semantics, we now have a
potential trap, whereby for every use of this variable we need to make
non-trivial reasoning whether this issue could or couldn't hit us.

I think we should get rid of this ambiguity on master.  Patches to
that effect are welcome.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  27647@debbugs.gnu.org,  Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 08 Nov 2017 21:49:31 -0500
> 
> Aha, the problem is this condition in should_produce_line_number:
> 
>     static bool
>     should_produce_line_number (struct it *it)
>     {
>       ...
>       /* Don't display line number in tooltip frames.  */
>       if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame))
>         return false;
> 
> Which sounds like it would be correct, except that the meaning of
> tip_frame is different for GTK tooltips, as explained in x_hide_tip:
> 
>     static Lisp_Object
>     x_hide_tip (bool delete)
>     {
>     ...
>     #ifdef USE_GTK
>           {
>         /* When using system tooltip, tip_frame is the Emacs frame on
>            which the tip is shown.  */
>         struct frame *f = XFRAME (tip_frame);

Thanks for the diagnose.  I hate these tricks.

> Leading to the following patch:

Thanks, but this patch won't compile in any non-X build (because
x_gtk_use_system_tooltips is only defined in xfns.c).  Also,
x_gtk_use_system_tooltips is non-zero by default in all X builds, even
those without GTK, so I guess under this patch non-GTK builds will
show line numbers in tooltip frames, is that right?

I propose a slightly different patch below; could you try it?

diff --git a/src/dispextern.h b/src/dispextern.h
index 2f55d8c..430afbf 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -3452,7 +3452,14 @@ void gamma_correct (struct frame *, COLORREF *);
 void x_implicitly_set_name (struct frame *, Lisp_Object, Lisp_Object);
 void x_change_tool_bar_height (struct frame *f, int);
 
+/* The frame used to display a tooltip.
+
+   Note: In a GTK build with non-zero x_gtk_use_system_tooltips, this
+   variable holds the frame that shows the tooltip, not the frame of
+   the tooltip itself, so checking whether a frame is a tooltip frame
+   cannot just compare the frame to what this variable holds.  */
 extern Lisp_Object tip_frame;
+
 extern Window tip_window;
 extern frame_parm_handler x_frame_parm_handlers[];
 
diff --git a/src/xdisp.c b/src/xdisp.c
index 69b74dc..d4a0261 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -21126,7 +21126,13 @@ should_produce_line_number (struct it *it)
 
 #ifdef HAVE_WINDOW_SYSTEM
   /* Don't display line number in tooltip frames.  */
-  if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame))
+  if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame)
+#ifdef USE_GTK
+      /* GTK builds store in tip_frame the frame that shows the tip,
+	 so we need an additional test.  */
+      && !NILP (Fframe_parameter (tip_frame, Qtooltip))
+#endif
+      )
     return false;
 #endif
 

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > What changes did you allude to here?  Can you point me to them?

   commit 20038f8ab75dd1551412a43cd58520c483c22921
   Author: Dmitry Antipov <dmantipov@yandex.ru>
   Date:   Tue Jul 12 09:16:26 2016 +0300

 > In general, using the same variable for two different purposes is
 > exactly what I was talking about in the discussion of
 > wait_reading_process_output discussion -- who could possibly keep all
 > such factoids in memory, and avoid making such subtle mistakes as
 > result?

Luckily we now have Noam on board to detect such mistakes.

 > I also wonder whether other places which seem to be similarly
 > vulnerable hide bugs.  For example, what about frame-list:
[...]
 > Does this mean that in a GTK build, at some "opportune moment",
 > frame-list will omit one frame from the list it returns, because that
 > frame happens to show a tooltip at that very moment?

I think so.  With all sorts of funny implications.

 > Or what about a similar snippet in x-display-monitor-attributes-list?
 > Is it in trouble as well?

If it gets called at the wrong moment, sure.

 > IOW, instead a simple variable with a clear semantics, we now have a
 > potential trap, whereby for every use of this variable we need to make
 > non-trivial reasoning whether this issue could or couldn't hit us.
 >
 > I think we should get rid of this ambiguity on master.  Patches to
 > that effect are welcome.

I'm afraid we have to get rid of all comparisons against tip_frame on
the release branch first and check against the 'tooltip' frame parameter
instead .  I've never run into problems like this because I always have
‘x-gtk-use-system-tooltips’ nil.

Please have a look at Dimitry's commit.  I think most parts of it were
good.  Maybe we should revive them.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Romanos Skiadas]

Work for me, thanks everyone for figuring this out and fixing it.

Best,

Romanos

> I propose a slightly different patch below; could you try it?
>
> diff --git a/src/dispextern.h b/src/dispextern.h
> index 2f55d8c..430afbf 100644
> --- a/src/dispextern.h
> +++ b/src/dispextern.h
> @@ -3452,7 +3452,14 @@ void gamma_correct (struct frame *, COLORREF *);
>   void x_implicitly_set_name (struct frame *, Lisp_Object, Lisp_Object);
>   void x_change_tool_bar_height (struct frame *f, int);
>   
> +/* The frame used to display a tooltip.
> +
> +   Note: In a GTK build with non-zero x_gtk_use_system_tooltips, this
> +   variable holds the frame that shows the tooltip, not the frame of
> +   the tooltip itself, so checking whether a frame is a tooltip frame
> +   cannot just compare the frame to what this variable holds.  */
>   extern Lisp_Object tip_frame;
> +
>   extern Window tip_window;
>   extern frame_parm_handler x_frame_parm_handlers[];
>   
> diff --git a/src/xdisp.c b/src/xdisp.c
> index 69b74dc..d4a0261 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -21126,7 +21126,13 @@ should_produce_line_number (struct it *it)
>   
>   #ifdef HAVE_WINDOW_SYSTEM
>     /* Don't display line number in tooltip frames.  */
> -  if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame))
> +  if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame)
> +#ifdef USE_GTK
> +      /* GTK builds store in tip_frame the frame that shows the tip,
> +	 so we need an additional test.  */
> +      && !NILP (Fframe_parameter (tip_frame, Qtooltip))
> +#endif
> +      )
>       return false;
>   #endif
>   
>
>
>

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Cc: 27647@debbugs.gnu.org, agrambot@gmail.com, kaushal.modi@gmail.com
> From: Romanos Skiadas <rom.skiad@gmail.com>
> Date: Thu, 9 Nov 2017 18:14:30 +0000
> 
> Work for me, thanks everyone for figuring this out and fixing it.

Thanks for testing.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Thu, 09 Nov 2017 19:10:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  > What changes did you allude to here?  Can you point me to them?
> 
>    commit 20038f8ab75dd1551412a43cd58520c483c22921
>    Author: Dmitry Antipov <dmantipov@yandex.ru>
>    Date:   Tue Jul 12 09:16:26 2016 +0300

Thanks.  It's a jumbo changeset, hard to see the forest for the trees.

>  > In general, using the same variable for two different purposes is
>  > exactly what I was talking about in the discussion of
>  > wait_reading_process_output discussion -- who could possibly keep all
>  > such factoids in memory, and avoid making such subtle mistakes as
>  > result?
> 
> Luckily we now have Noam on board to detect such mistakes.

The challenge is not to make such mistakes in the first place.  We
could easily let it slip into Emacs 26.1, if we were less lucky.

>  > Does this mean that in a GTK build, at some "opportune moment",
>  > frame-list will omit one frame from the list it returns, because that
>  > frame happens to show a tooltip at that very moment?
> 
> I think so.  With all sorts of funny implications.
> 
>  > Or what about a similar snippet in x-display-monitor-attributes-list?
>  > Is it in trouble as well?
> 
> If it gets called at the wrong moment, sure.

We should fix those places.

>  > I think we should get rid of this ambiguity on master.  Patches to
>  > that effect are welcome.
> 
> I'm afraid we have to get rid of all comparisons against tip_frame on
> the release branch first and check against the 'tooltip' frame parameter
> instead.

Not if we always either put in that variable either the tooltip frame
or nil, never any other frame.  IOW, if we make it an innocent
variable with simple semantics again, and track the frame GTK needs
"by other means".

> Please have a look at Dimitry's commit.  I think most parts of it were
> good.  Maybe we should revive them.

Maybe I'm missing something, but I don't understand why the changes
for this have to be so complex and invasive.  But I'll review any
specific proposal for fixing this mess.

Thanks.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but this patch won't compile in any non-X build (because
> x_gtk_use_system_tooltips is only defined in xfns.c).  Also,
> x_gtk_use_system_tooltips is non-zero by default in all X builds, even
> those without GTK, so I guess under this patch non-GTK builds will
> show line numbers in tooltip frames, is that right?

Ah yes, you are right.

Romanos Skiadas <rom.skiad@gmail.com> writes:

> Work for me, thanks everyone for figuring this out and fixing it.

Works for me too.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Noam Postavsky]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Thanks for spending time to debug this and come up with that crucial
> fix. Did any of the within-emacs debug tactics help you figure this
> out? Or was it putting breakpoints and catching them in gdb? Or did
> you go the final hard way, and review the code manually?

So glad you asked, now I can relive the glory of the hunt :D

The first thing I tried was the 'watch Vdisplay_line_numbers', but this
gave me no hits except for some spurious stuff related to buffer-local
variables; after changing to (setq-default display-line-numbers t) I got
no hits at all.  So it was fairly clear that the problem lay below the
lisp level.

Then I considered putting a breakpoint into the display code, which is a
bit tricky because I needed to drag the mouse to trigger the problem,
but if a breakpoint is hit before that Emacs is frozen and can't
register the mouse drag.  I tried to reduce the recipe to some lisp code
to be evaluated based on mouse-drag-and-drop-region, but I didn't
manage to come up with something that worked.

Then I looked a bit through the display code to figure if a breakpoint
conditioned on mouse dragging could work, and I noticed the
should_produce_line_number function, so I just put a breakpoint on every
place which returned false.  Bang, success!

Except I then had to check the values of WINDOW_FRAME (it->w) to make
sure I hadn't actually hit the case where the code *correctly* skips
line numbers for tooltips.  A quick grep for tip_frame soon turned up
x_hide_tooltip which had the comment that explained what was going on.

> Also thanks to everyone who helped figure out a recipe, which is
> equally important :). 

Most definitely, I could not have done anything without a simple way to
reproduce the problem.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: 27647@debbugs.gnu.org,  agrambot@gmail.com,  kaushal.modi@gmail.com
> Date: Thu, 09 Nov 2017 19:11:15 -0500
> 
> Romanos Skiadas <rom.skiad@gmail.com> writes:
> 
> > Work for me, thanks everyone for figuring this out and fixing it.
> 
> Works for me too.

Thanks, pushed.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > Thanks.  It's a jumbo changeset, hard to see the forest for the trees.

It worked everywhere but for that Mac case.

 > The challenge is not to make such mistakes in the first place.  We
 > could easily let it slip into Emacs 26.1, if we were less lucky.

We were lucky that you wrote the native line numbers code that revealed
the problem, that Alex mentioned that only ‘x-gtk-use-system-tooltips’
would reveal it and that Noam found the cause.  But we also would have
never known about this particular bug if we had left in Dmitry's code.

 > We should fix those places.

I see you have done that already, thanks.  I can't reasonably do any
work here because regular builds of the release branch still fail.

 > Not if we always either put in that variable either the tooltip frame
 > or nil, never any other frame.  IOW, if we make it an innocent
 > variable with simple semantics again, and track the frame GTK needs
 > "by other means".

If the semantics of tip_frame non-nil is

"The frame of a currently visible tooltip."

and for a GTK build the "currently visible tooltip" has no frame, then
we have no simple semantics.  It means that for GTK we always need an
additional test like that for a 'tooltip' frame parameter.  Don't you
agree?

 >> Please have a look at Dimitry's commit.  I think most parts of it were
 >> good.  Maybe we should revive them.
 >
 > Maybe I'm missing something, but I don't understand why the changes
 > for this have to be so complex and invasive.  But I'll review any
 > specific proposal for fixing this mess.

He didn't want to change only "this".  His was a pretty comprehensive
solution for many problems in this area.  The only thing I disliked was
that 'tooltip-timer' parameter, but maybe there really is no better
solution.  Anyway, replacing the global variable and the frame parameter
stuff by a one-bit per frame slot should be enough for fixing the mess
at hand.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Sun, 12 Nov 2017 11:08:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  > Not if we always either put in that variable either the tooltip frame
>  > or nil, never any other frame.  IOW, if we make it an innocent
>  > variable with simple semantics again, and track the frame GTK needs
>  > "by other means".
> 
> If the semantics of tip_frame non-nil is
> 
> "The frame of a currently visible tooltip."
> 
> and for a GTK build the "currently visible tooltip" has no frame, then
> we have no simple semantics.  It means that for GTK we always need an
> additional test like that for a 'tooltip' frame parameter.  Don't you
> agree?

Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
then tip_frame will get its simple semantics back.  If GTK needs to
stash the original frame, to be used to hide the tooltip, it should
use a separate variable (or a struct frame member), also with simple
semantics.  Two variables with simple semantics are much better than
one with a subtly complex one.  Don't you agree?

>  > Maybe I'm missing something, but I don't understand why the changes
>  > for this have to be so complex and invasive.  But I'll review any
>  > specific proposal for fixing this mess.
> 
> He didn't want to change only "this".  His was a pretty comprehensive
> solution for many problems in this area.  The only thing I disliked was
> that 'tooltip-timer' parameter

That timer was at the base of the proposed solution, AFAIU.  So if you
dislike it, you dislike the idea itself.

> but maybe there really is no better solution.

Sorry, I refuse to believe that.

> Anyway, replacing the global variable and the frame parameter stuff
> by a one-bit per frame slot should be enough for fixing the mess at
> hand.

Exactly.  So why we need the rest of the complexity in that patch?

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
 > then tip_frame will get its simple semantics back.

x_hide_tip uses NILP (tip_frame) to decide whether to hide the tip.

 > If GTK needs to
 > stash the original frame, to be used to hide the tooltip, it should
 > use a separate variable (or a struct frame member), also with simple
 > semantics.  Two variables with simple semantics are much better than
 > one with a subtly complex one.  Don't you agree?

IIUC GTK doesn't need the original frame.  But it sets tooltip_frame to
it so Fx_show_tip and friends can base their decisions on it.  Look at
occurrences of FRAMEP (tip_frame) and FRAME_LIVE_P (XFRAME (tip_frame)).
They pass because for GTK tip_frame is a live frame associated with the
tooltip.  Jan tried hard to leave the native tooltip code untouched.

 > That timer was at the base of the proposed solution, AFAIU.  So if you
 > dislike it, you dislike the idea itself.

I don't dislike the timer.  I dislike the idea to put it on a frame
parameter.

 >> but maybe there really is no better solution.
 >
 > Sorry, I refuse to believe that.

Where would you put it?

 >> Anyway, replacing the global variable and the frame parameter stuff
 >> by a one-bit per frame slot should be enough for fixing the mess at
 >> hand.
 >
 > Exactly.  So why we need the rest of the complexity in that patch?

Simply because I don't know whether the rest is more complex than what's
needed to fix the mess.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Mon, 13 Nov 2017 19:45:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  > Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
>  > then tip_frame will get its simple semantics back.
> 
> x_hide_tip uses NILP (tip_frame) to decide whether to hide the tip.

That's non-GTK code which GTK doesn't need, but left it alone.  The
whole GTK support in x_hide_tip is patched over the non-GTK code, with
dirty tricks like setting tip_frame to nil just to bypass the non-GTK
part of the function.  We will be better off with a separate GTK-only
implementation.

> IIUC GTK doesn't need the original frame.

xg_hide_tooltip needs it, because the GTK tooltip widget is stashed
away in its output->data.x structure.

> But it sets tooltip_frame to it so Fx_show_tip and friends can base
> their decisions on it.  Look at occurrences of FRAMEP (tip_frame)
> and FRAME_LIVE_P (XFRAME (tip_frame)).  They pass because for GTK
> tip_frame is a live frame associated with the tooltip.  Jan tried
> hard to leave the native tooltip code untouched.

Once again, it would be better to have the GTK code completely
separated, IMO.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 >> IIUC GTK doesn't need the original frame.
 >
 > xg_hide_tooltip needs it, because the GTK tooltip widget is stashed
 > away in its output->data.x structure.

Because ‘tooltip-show’ implicitly uses the selected frame to decide
where to show the tooltip and passes it as argument to ‘x-show-tip’.
Nowhere in the documentation of tooltips we mention that dependency.

 > Once again, it would be better to have the GTK code completely
 > separated, IMO.

Still I think we should first eliminate all tooltip related global
variables.  They are an unnecessary confusion - only think of
last_show_tip_args impicitly also referring to a frame selected at some
earlier time - and restriction - Emacs could easily show several native
tooltips simultaneously, at least one for each display.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Tue, 14 Nov 2017 10:52:48 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  >> IIUC GTK doesn't need the original frame.
>  >
>  > xg_hide_tooltip needs it, because the GTK tooltip widget is stashed
>  > away in its output->data.x structure.
> 
> Because ‘tooltip-show’ implicitly uses the selected frame to decide
> where to show the tooltip and passes it as argument to ‘x-show-tip’.

No, it's because x-show-tip _needs_ a frame on which to pop up the
tooltip.  And since tooltip-show doesn't accept a frame parameter, it
uses the selected frame.  But that's not why xg_hide_tooltip needs the
frame, it needs the frame to get at the tooltip widget.

> Nowhere in the documentation of tooltips we mention that dependency.

Feel free to document that, but that's tangential to the issue being
discussed.

>  > Once again, it would be better to have the GTK code completely
>  > separated, IMO.
> 
> Still I think we should first eliminate all tooltip related global
> variables.  They are an unnecessary confusion - only think of
> last_show_tip_args impicitly also referring to a frame selected at some
> earlier time - and restriction - Emacs could easily show several native
> tooltips simultaneously, at least one for each display.

It would be better indeed to away with the global variables.  I'm just
saying that the mess with tip_frame on GTK could be solved even
without getting rid of global variables.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > No, it's because x-show-tip _needs_ a frame on which to pop up the
 > tooltip.

Only to pass a display info to x_create_tip_frame and to do the
last_frame rigmarole.  But I do not anywhere see a dependency that would
trigger the deletion of a tip frame when the frame on which it popped up
gets deleted.  So passing the frame is inherently needed only for the
sake of xg_show_tooltip, xg_hide_tooltip and xg_free_frame_widgets.  Or
am I missing something?

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Tue, 14 Nov 2017 19:29:16 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  > No, it's because x-show-tip _needs_ a frame on which to pop up the
>  > tooltip.
> 
> Only to pass a display info to x_create_tip_frame and to do the
> last_frame rigmarole.

Like with any other frame we create, no?

Besides, GTK needs the frame to stash away the widget.

> But I do not anywhere see a dependency that would trigger the
> deletion of a tip frame when the frame on which it popped up gets
> deleted.

x-show-tip starts a timer that calls x-hide-tip when the timer
expires.  And x-hide-tip deletes the tip frame.

> So passing the frame is inherently needed only for the
> sake of xg_show_tooltip, xg_hide_tooltip and xg_free_frame_widgets.  Or
> am I missing something?

And for the rigmarole.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 >>   > No, it's because x-show-tip _needs_ a frame on which to pop up the
 >>   > tooltip.
 >>
 >> Only to pass a display info to x_create_tip_frame and to do the
 >> last_frame rigmarole.
 >
 > Like with any other frame we create, no?

I once thought of doing away with x_create_tip_frame, putting all
tooltip specific parameters into ‘tooltip-frame-parameters’ and let
people shoot themselves in their feet when overriding them.  Might be
still worth the hassle.

 > Besides, GTK needs the frame to stash away the widget.

That's a vice of GTK.  We should cure that.

 >> But I do not anywhere see a dependency that would trigger the
 >> deletion of a tip frame when the frame on which it popped up gets
 >> deleted.
 >
 > x-show-tip starts a timer that calls x-hide-tip when the timer
 > expires.  And x-hide-tip deletes the tip frame.

I was thinking of a scenario like ...

(let ((tooltip-hide-delay 1000)
       (frame (make-frame)))
   (select-frame frame)
   (tooltip-show ".....")
   (delete-frame frame))

... but try for yourself.  Unless you have a better idea I'll make
x_create_tip_frame call make_frame_without_minibuffer.  Any clues why
the above doesn't crash Emacs <= 24?

 >> So passing the frame is inherently needed only for the
 >> sake of xg_show_tooltip, xg_hide_tooltip and xg_free_frame_widgets.  Or
 >> am I missing something?
 >
 > And for the rigmarole.

I'll try to get rid of that.

martin

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > (let ((tooltip-hide-delay 1000)
 >        (frame (make-frame)))
 >    (select-frame frame)
 >    (tooltip-show ".....")
 >    (delete-frame frame))
 >
 > ... but try for yourself.  Unless you have a better idea I'll make
 > x_create_tip_frame call make_frame_without_minibuffer.

The below seems to fix it and should be used anyway.  Still someone might want
to select a tooltip frame ...

martin


--- a/src/frame.c
+++ b/src/frame.c
@@ -1916,6 +1916,7 @@ of them (the selected terminal frame) is actually displayed.
  	 See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15025.  */
        FOR_EACH_FRAME (tail, frame1)
  	if (!EQ (frame, frame1)
+	    && NILP (Fframe_parameter (frame1, Qtooltip))
  	    && (FRAME_TERMINAL (XFRAME (frame))
  		== FRAME_TERMINAL (XFRAME (frame1)))
  	    && FRAME_VISIBLE_P (XFRAME (frame1)))
@@ -1926,7 +1927,9 @@ of them (the selected terminal frame) is actually displayed.
  	{
  	  FOR_EACH_FRAME (tail, frame1)
  	    {
-	      if (! EQ (frame, frame1) && FRAME_LIVE_P (XFRAME (frame1)))
+	      if (!EQ (frame, frame1)
+		  && FRAME_LIVE_P (XFRAME (frame1))
+		  && NILP (Fframe_parameter (frame1, Qtooltip)))
  		{
  		  /* Do not change a text terminal's top-frame.  */
  		  struct frame *f1 = XFRAME (frame1);

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[Eli Zaretskii]

> Date: Wed, 15 Nov 2017 11:05:13 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 27647@debbugs.gnu.org, npostavs@users.sourceforge.net, 
>  agrambot@gmail.com, kaushal.modi@gmail.com
> 
>  > (let ((tooltip-hide-delay 1000)
>  >        (frame (make-frame)))
>  >    (select-frame frame)
>  >    (tooltip-show ".....")
>  >    (delete-frame frame))
>  >
>  > ... but try for yourself.  Unless you have a better idea I'll make
>  > x_create_tip_frame call make_frame_without_minibuffer.
> 
> The below seems to fix it and should be used anyway.  Still someone might want
> to select a tooltip frame ...

I installed another defense, but your proposed patch looks reasonable
regardless, so I think you should install it.

Thanks.

bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

 > I installed another defense,

... which is stronger indeed ...

 > but your proposed patch looks reasonable
 > regardless, so I think you should install it.

Done.

Thanks, martin