* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus @ 2017-07-10 20:52 Kaushal Modi 2017-07-11 2:38 ` Eli Zaretskii 2017-07-21 17:49 ` bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, " jonas 0 siblings, 2 replies; 63+ messages in thread From: Kaushal Modi @ 2017-07-10 20:52 UTC (permalink / raw) To: 27647 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-10 20:52 bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus Kaushal Modi @ 2017-07-11 2:38 ` Eli Zaretskii 2017-07-11 3:43 ` Kaushal Modi 2017-11-08 20:08 ` Alex 2017-07-21 17:49 ` bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, " jonas 1 sibling, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-07-11 2:38 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647 > 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-11 2:38 ` Eli Zaretskii @ 2017-07-11 3:43 ` Kaushal Modi 2017-07-11 14:31 ` Eli Zaretskii 2017-11-08 20:08 ` Alex 1 sibling, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-07-11 3:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-11 3:43 ` Kaushal Modi @ 2017-07-11 14:31 ` Eli Zaretskii 2017-07-11 14:38 ` Kaushal Modi 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-07-11 14:31 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647 > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-11 14:31 ` Eli Zaretskii @ 2017-07-11 14:38 ` Kaushal Modi 2017-07-11 20:08 ` Kaushal Modi 0 siblings, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-07-11 14:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-11 14:38 ` Kaushal Modi @ 2017-07-11 20:08 ` Kaushal Modi 2017-07-12 14:44 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-07-11 20:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-11 20:08 ` Kaushal Modi @ 2017-07-12 14:44 ` Eli Zaretskii 2017-07-19 15:13 ` Kaushal Modi 2017-07-19 17:52 ` Noam Postavsky 0 siblings, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-07-12 14:44 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647 > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-12 14:44 ` Eli Zaretskii @ 2017-07-19 15:13 ` Kaushal Modi 2017-07-19 17:34 ` Eli Zaretskii 2017-07-19 17:52 ` Noam Postavsky 1 sibling, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-07-19 15:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-19 15:13 ` Kaushal Modi @ 2017-07-19 17:34 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-07-19 17:34 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647 > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-12 14:44 ` Eli Zaretskii 2017-07-19 15:13 ` Kaushal Modi @ 2017-07-19 17:52 ` Noam Postavsky 2017-07-19 18:09 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: Noam Postavsky @ 2017-07-19 17:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, Kaushal Modi 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-19 17:52 ` Noam Postavsky @ 2017-07-19 18:09 ` Eli Zaretskii 2017-10-05 12:40 ` Kaushal Modi 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-07-19 18:09 UTC (permalink / raw) To: Noam Postavsky; +Cc: 27647, kaushal.modi > 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-19 18:09 ` Eli Zaretskii @ 2017-10-05 12:40 ` Kaushal Modi 2017-10-05 13:03 ` jonas 2017-10-05 13:10 ` Eli Zaretskii 0 siblings, 2 replies; 63+ messages in thread From: Kaushal Modi @ 2017-10-05 12:40 UTC (permalink / raw) To: Eli Zaretskii, Noam Postavsky; +Cc: 27647, jonaswestlund101 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-05 12:40 ` Kaushal Modi @ 2017-10-05 13:03 ` jonas 2017-10-05 13:10 ` Eli Zaretskii 1 sibling, 0 replies; 63+ messages in thread From: jonas @ 2017-10-05 13:03 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647 [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-05 12:40 ` Kaushal Modi 2017-10-05 13:03 ` jonas @ 2017-10-05 13:10 ` Eli Zaretskii 2017-10-05 13:39 ` Eli Zaretskii 2017-10-11 20:32 ` Romanos Skiadas 1 sibling, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-10-05 13:10 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647, jonaswestlund101, npostavs > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-05 13:10 ` Eli Zaretskii @ 2017-10-05 13:39 ` Eli Zaretskii 2017-10-05 22:17 ` Romanos Skiadas 2017-10-11 20:32 ` Romanos Skiadas 1 sibling, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-10-05 13:39 UTC (permalink / raw) To: kaushal.modi; +Cc: 27647, jonaswestlund101, npostavs > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-05 13:39 ` Eli Zaretskii @ 2017-10-05 22:17 ` Romanos Skiadas 2017-10-06 8:57 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: Romanos Skiadas @ 2017-10-05 22:17 UTC (permalink / raw) To: Eli Zaretskii, kaushal.modi; +Cc: 27647, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-05 22:17 ` Romanos Skiadas @ 2017-10-06 8:57 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-10-06 8:57 UTC (permalink / raw) To: Romanos Skiadas; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs > 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-05 13:10 ` Eli Zaretskii 2017-10-05 13:39 ` Eli Zaretskii @ 2017-10-11 20:32 ` Romanos Skiadas 2017-10-12 8:29 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: Romanos Skiadas @ 2017-10-11 20:32 UTC (permalink / raw) To: Eli Zaretskii, Kaushal Modi; +Cc: 27647, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-11 20:32 ` Romanos Skiadas @ 2017-10-12 8:29 ` Eli Zaretskii 2017-10-12 19:30 ` Romanos Skiadas 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-10-12 8:29 UTC (permalink / raw) To: Romanos Skiadas; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-12 8:29 ` Eli Zaretskii @ 2017-10-12 19:30 ` Romanos Skiadas 2017-10-13 8:33 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: Romanos Skiadas @ 2017-10-12 19:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-12 19:30 ` Romanos Skiadas @ 2017-10-13 8:33 ` Eli Zaretskii 2017-10-13 18:14 ` Romanos Skiadas 2017-10-14 8:36 ` martin rudalics 0 siblings, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-10-13 8:33 UTC (permalink / raw) To: Romanos Skiadas; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-13 8:33 ` Eli Zaretskii @ 2017-10-13 18:14 ` Romanos Skiadas 2017-10-14 7:47 ` Eli Zaretskii 2017-10-14 8:36 ` martin rudalics 1 sibling, 1 reply; 63+ messages in thread From: Romanos Skiadas @ 2017-10-13 18:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-13 18:14 ` Romanos Skiadas @ 2017-10-14 7:47 ` Eli Zaretskii 2017-10-15 15:05 ` Romanos Skiadas 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-10-14 7:47 UTC (permalink / raw) To: Romanos Skiadas; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs > 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-14 7:47 ` Eli Zaretskii @ 2017-10-15 15:05 ` Romanos Skiadas 0 siblings, 0 replies; 63+ messages in thread From: Romanos Skiadas @ 2017-10-15 15:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, kaushal.modi, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-13 8:33 ` Eli Zaretskii 2017-10-13 18:14 ` Romanos Skiadas @ 2017-10-14 8:36 ` martin rudalics 2017-10-14 10:12 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-10-14 8:36 UTC (permalink / raw) To: Eli Zaretskii, Romanos Skiadas Cc: 27647, kaushal.modi, jonaswestlund101, npostavs >> 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-14 8:36 ` martin rudalics @ 2017-10-14 10:12 ` Eli Zaretskii 2017-10-15 9:39 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-10-14 10:12 UTC (permalink / raw) To: martin rudalics Cc: rom.skiad, 27647, kaushal.modi, jonaswestlund101, npostavs > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-14 10:12 ` Eli Zaretskii @ 2017-10-15 9:39 ` martin rudalics 2017-10-15 13:25 ` Kaushal Modi 2017-10-15 14:29 ` Eli Zaretskii 0 siblings, 2 replies; 63+ messages in thread From: martin rudalics @ 2017-10-15 9:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rom.skiad, 27647, kaushal.modi, jonaswestlund101, npostavs > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-15 9:39 ` martin rudalics @ 2017-10-15 13:25 ` Kaushal Modi 2017-10-16 21:46 ` Kaushal Modi 2017-10-15 14:29 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-10-15 13:25 UTC (permalink / raw) To: martin rudalics; +Cc: rom.skiad, 27647, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-15 13:25 ` Kaushal Modi @ 2017-10-16 21:46 ` Kaushal Modi 2017-10-17 8:59 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-10-16 21:46 UTC (permalink / raw) To: martin rudalics; +Cc: rom.skiad, 27647, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-16 21:46 ` Kaushal Modi @ 2017-10-17 8:59 ` martin rudalics 2017-10-17 14:47 ` Eli Zaretskii 2017-10-17 15:13 ` Kaushal Modi 0 siblings, 2 replies; 63+ messages in thread From: martin rudalics @ 2017-10-17 8:59 UTC (permalink / raw) To: Kaushal Modi; +Cc: rom.skiad, 27647, jonaswestlund101, npostavs > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-17 8:59 ` martin rudalics @ 2017-10-17 14:47 ` Eli Zaretskii 2017-10-17 15:07 ` Kaushal Modi 2017-10-17 15:13 ` Kaushal Modi 1 sibling, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-10-17 14:47 UTC (permalink / raw) To: martin rudalics Cc: rom.skiad, 27647, kaushal.modi, jonaswestlund101, npostavs > 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-17 14:47 ` Eli Zaretskii @ 2017-10-17 15:07 ` Kaushal Modi 0 siblings, 0 replies; 63+ messages in thread From: Kaushal Modi @ 2017-10-17 15:07 UTC (permalink / raw) To: Eli Zaretskii, martin rudalics Cc: rom.skiad, 27647, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-17 8:59 ` martin rudalics 2017-10-17 14:47 ` Eli Zaretskii @ 2017-10-17 15:13 ` Kaushal Modi 2017-10-17 16:48 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-10-17 15:13 UTC (permalink / raw) To: martin rudalics; +Cc: rom.skiad, 27647, jonaswestlund101, npostavs [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-17 15:13 ` Kaushal Modi @ 2017-10-17 16:48 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-10-17 16:48 UTC (permalink / raw) To: Kaushal Modi; +Cc: rom.skiad, jonaswestlund101, 27647, npostavs > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-10-15 9:39 ` martin rudalics 2017-10-15 13:25 ` Kaushal Modi @ 2017-10-15 14:29 ` Eli Zaretskii 1 sibling, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-10-15 14:29 UTC (permalink / raw) To: martin rudalics Cc: rom.skiad, 27647, kaushal.modi, jonaswestlund101, npostavs > 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). ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-07-11 2:38 ` Eli Zaretskii 2017-07-11 3:43 ` Kaushal Modi @ 2017-11-08 20:08 ` Alex 2017-11-08 20:14 ` Alex 1 sibling, 1 reply; 63+ messages in thread From: Alex @ 2017-11-08 20:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, Kaushal Modi 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-08 20:08 ` Alex @ 2017-11-08 20:14 ` Alex 2017-11-09 2:49 ` Noam Postavsky 0 siblings, 1 reply; 63+ messages in thread From: Alex @ 2017-11-08 20:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, Kaushal Modi 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-08 20:14 ` Alex @ 2017-11-09 2:49 ` Noam Postavsky 2017-11-09 7:28 ` martin rudalics ` (2 more replies) 0 siblings, 3 replies; 63+ messages in thread From: Noam Postavsky @ 2017-11-09 2:49 UTC (permalink / raw) To: Alex; +Cc: 27647, Kaushal Modi [-- 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 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 2:49 ` Noam Postavsky @ 2017-11-09 7:28 ` martin rudalics 2017-11-09 15:57 ` Eli Zaretskii 2017-11-09 13:34 ` Kaushal Modi 2017-11-09 16:12 ` Eli Zaretskii 2 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-09 7:28 UTC (permalink / raw) To: Noam Postavsky, Alex; +Cc: 27647, Kaushal Modi > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 7:28 ` martin rudalics @ 2017-11-09 15:57 ` Eli Zaretskii 2017-11-09 18:10 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-09 15:57 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 15:57 ` Eli Zaretskii @ 2017-11-09 18:10 ` martin rudalics 2017-11-09 20:53 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-09 18:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 18:10 ` martin rudalics @ 2017-11-09 20:53 ` Eli Zaretskii 2017-11-12 10:08 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-09 20:53 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 20:53 ` Eli Zaretskii @ 2017-11-12 10:08 ` martin rudalics 2017-11-12 11:36 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-12 10:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-12 10:08 ` martin rudalics @ 2017-11-12 11:36 ` Eli Zaretskii 2017-11-13 18:45 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-12 11:36 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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? ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-12 11:36 ` Eli Zaretskii @ 2017-11-13 18:45 ` martin rudalics 2017-11-13 19:12 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-13 18:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-13 18:45 ` martin rudalics @ 2017-11-13 19:12 ` Eli Zaretskii 2017-11-14 9:52 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-13 19:12 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-13 19:12 ` Eli Zaretskii @ 2017-11-14 9:52 ` martin rudalics 2017-11-14 15:47 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-14 9:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi >> 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-14 9:52 ` martin rudalics @ 2017-11-14 15:47 ` Eli Zaretskii 2017-11-14 18:29 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-14 15:47 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-14 15:47 ` Eli Zaretskii @ 2017-11-14 18:29 ` martin rudalics 2017-11-14 19:02 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-14 18:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-14 18:29 ` martin rudalics @ 2017-11-14 19:02 ` Eli Zaretskii 2017-11-15 9:22 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-14 19:02 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-14 19:02 ` Eli Zaretskii @ 2017-11-15 9:22 ` martin rudalics 2017-11-15 10:05 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-15 9:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi >> > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-15 9:22 ` martin rudalics @ 2017-11-15 10:05 ` martin rudalics 2017-11-18 11:42 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: martin rudalics @ 2017-11-15 10:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi > (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); ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-15 10:05 ` martin rudalics @ 2017-11-18 11:42 ` Eli Zaretskii 2017-11-18 18:25 ` martin rudalics 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2017-11-18 11:42 UTC (permalink / raw) To: martin rudalics; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-18 11:42 ` Eli Zaretskii @ 2017-11-18 18:25 ` martin rudalics 0 siblings, 0 replies; 63+ messages in thread From: martin rudalics @ 2017-11-18 18:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 2:49 ` Noam Postavsky 2017-11-09 7:28 ` martin rudalics @ 2017-11-09 13:34 ` Kaushal Modi 2017-11-10 0:38 ` Noam Postavsky 2017-11-09 16:12 ` Eli Zaretskii 2 siblings, 1 reply; 63+ messages in thread From: Kaushal Modi @ 2017-11-09 13:34 UTC (permalink / raw) To: Noam Postavsky; +Cc: 27647, Alex [-- 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 --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 13:34 ` Kaushal Modi @ 2017-11-10 0:38 ` Noam Postavsky 0 siblings, 0 replies; 63+ messages in thread From: Noam Postavsky @ 2017-11-10 0:38 UTC (permalink / raw) To: Kaushal Modi; +Cc: 27647, Alex 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 2:49 ` Noam Postavsky 2017-11-09 7:28 ` martin rudalics 2017-11-09 13:34 ` Kaushal Modi @ 2017-11-09 16:12 ` Eli Zaretskii 2017-11-09 18:14 ` Romanos Skiadas 2017-11-10 0:11 ` Noam Postavsky 2 siblings, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-11-09 16:12 UTC (permalink / raw) To: Noam Postavsky; +Cc: 27647, agrambot, kaushal.modi > 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 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 16:12 ` Eli Zaretskii @ 2017-11-09 18:14 ` Romanos Skiadas 2017-11-09 20:27 ` Eli Zaretskii 2017-11-10 0:11 ` Noam Postavsky 1 sibling, 1 reply; 63+ messages in thread From: Romanos Skiadas @ 2017-11-09 18:14 UTC (permalink / raw) To: Eli Zaretskii, Noam Postavsky; +Cc: 27647, agrambot, kaushal.modi 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 > > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 18:14 ` Romanos Skiadas @ 2017-11-09 20:27 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-11-09 20:27 UTC (permalink / raw) To: Romanos Skiadas; +Cc: 27647, npostavs, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-09 16:12 ` Eli Zaretskii 2017-11-09 18:14 ` Romanos Skiadas @ 2017-11-10 0:11 ` Noam Postavsky 2017-11-10 8:37 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: Noam Postavsky @ 2017-11-10 0:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27647, agrambot, kaushal.modi 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus 2017-11-10 0:11 ` Noam Postavsky @ 2017-11-10 8:37 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-11-10 8:37 UTC (permalink / raw) To: Noam Postavsky; +Cc: 27647-done, agrambot, kaushal.modi > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, frame out of focus 2017-07-10 20:52 bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus Kaushal Modi 2017-07-11 2:38 ` Eli Zaretskii @ 2017-07-21 17:49 ` jonas 2017-07-21 18:57 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: jonas @ 2017-07-21 17:49 UTC (permalink / raw) To: 27647 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, frame out of focus 2017-07-21 17:49 ` bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, " jonas @ 2017-07-21 18:57 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2017-07-21 18:57 UTC (permalink / raw) To: jonas; +Cc: 27647 > 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2017-11-18 18:25 UTC | newest] Thread overview: 63+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-07-10 20:52 bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus Kaushal Modi 2017-07-11 2:38 ` Eli Zaretskii 2017-07-11 3:43 ` Kaushal Modi 2017-07-11 14:31 ` Eli Zaretskii 2017-07-11 14:38 ` Kaushal Modi 2017-07-11 20:08 ` Kaushal Modi 2017-07-12 14:44 ` Eli Zaretskii 2017-07-19 15:13 ` Kaushal Modi 2017-07-19 17:34 ` Eli Zaretskii 2017-07-19 17:52 ` Noam Postavsky 2017-07-19 18:09 ` Eli Zaretskii 2017-10-05 12:40 ` Kaushal Modi 2017-10-05 13:03 ` jonas 2017-10-05 13:10 ` Eli Zaretskii 2017-10-05 13:39 ` Eli Zaretskii 2017-10-05 22:17 ` Romanos Skiadas 2017-10-06 8:57 ` Eli Zaretskii 2017-10-11 20:32 ` Romanos Skiadas 2017-10-12 8:29 ` Eli Zaretskii 2017-10-12 19:30 ` Romanos Skiadas 2017-10-13 8:33 ` Eli Zaretskii 2017-10-13 18:14 ` Romanos Skiadas 2017-10-14 7:47 ` Eli Zaretskii 2017-10-15 15:05 ` Romanos Skiadas 2017-10-14 8:36 ` martin rudalics 2017-10-14 10:12 ` Eli Zaretskii 2017-10-15 9:39 ` martin rudalics 2017-10-15 13:25 ` Kaushal Modi 2017-10-16 21:46 ` Kaushal Modi 2017-10-17 8:59 ` martin rudalics 2017-10-17 14:47 ` Eli Zaretskii 2017-10-17 15:07 ` Kaushal Modi 2017-10-17 15:13 ` Kaushal Modi 2017-10-17 16:48 ` Eli Zaretskii 2017-10-15 14:29 ` Eli Zaretskii 2017-11-08 20:08 ` Alex 2017-11-08 20:14 ` Alex 2017-11-09 2:49 ` Noam Postavsky 2017-11-09 7:28 ` martin rudalics 2017-11-09 15:57 ` Eli Zaretskii 2017-11-09 18:10 ` martin rudalics 2017-11-09 20:53 ` Eli Zaretskii 2017-11-12 10:08 ` martin rudalics 2017-11-12 11:36 ` Eli Zaretskii 2017-11-13 18:45 ` martin rudalics 2017-11-13 19:12 ` Eli Zaretskii 2017-11-14 9:52 ` martin rudalics 2017-11-14 15:47 ` Eli Zaretskii 2017-11-14 18:29 ` martin rudalics 2017-11-14 19:02 ` Eli Zaretskii 2017-11-15 9:22 ` martin rudalics 2017-11-15 10:05 ` martin rudalics 2017-11-18 11:42 ` Eli Zaretskii 2017-11-18 18:25 ` martin rudalics 2017-11-09 13:34 ` Kaushal Modi 2017-11-10 0:38 ` Noam Postavsky 2017-11-09 16:12 ` Eli Zaretskii 2017-11-09 18:14 ` Romanos Skiadas 2017-11-09 20:27 ` Eli Zaretskii 2017-11-10 0:11 ` Noam Postavsky 2017-11-10 8:37 ` Eli Zaretskii 2017-07-21 17:49 ` bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when, " jonas 2017-07-21 18:57 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).