GNU bug report logs - #38497
27.0.50; Frame is not rendered when frame-resize-pixelwise it 't

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38497 in the body.
You can then email your comments to 38497 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 'Ihor Radchenko' <yantar92 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Frame is not rendered when frame-resize-pixelwise it 't
Date: Thu, 05 Dec 2019 15:08:07 +0800

[Message part 1 (text/plain, inline)]

A while ago I noticed that pop-up org-capture frames are not rendered
(no buffer or mode-line text is shown, as in attached image) when the
window manager forces them to be full screen (floating frames are
rendered as usual).

The issue seems to be triggered by the combination of
maximised frame, frame-resize-pixelwise 't, custom-setting a certain
default font, and loading certain colour theme.
The minimum emacs -Q config, which reproduces the issue in my system
(with my set of installed fonts) is the following:

#+begin_src emacs-lisp
(eval-and-compile
  (defvar bootstrap-version)
  (let ((bootstrap-file
	 (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
	(bootstrap-version 5))
    (unless (file-exists-p bootstrap-file)
      (with-current-buffer
	  (url-retrieve-synchronously
	   "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
	   'silent 'inhibit-cookies)
	(goto-char (point-max))
	(eval-print-last-sexp)))
    (load bootstrap-file nil 'nomessage)))

(eval-and-compile (straight-use-package 'use-package))

;; Using this instead of custom-set-faces does not trigger the rendering problem
;; (set-face-attribute 'default nil
;; 			  :foundry "adobe"
;; 			  :family "source code pro")
(custom-set-faces
 '(default ((t (:foundry "adobe" :family "source code pro"))))
)


(setq frame-resize-pixelwise t)

(use-package flatui-theme
  :straight t
  :config
  (load-theme 'flatui t))

;; I once managed to narrow down the issue to setting this font from
;; flatui, but it turned out to be not reproducible. Other time, another
;; font setting caused a maximised frame to be not rendered. The only
;; reliable way I can reproduce the issue on my system is lading the
;; whole flatui theme.
;; (custom-set-faces
;;  '(menu ((t (:foreground "#2c3e50" :background "#dfe4ea"))))
;; )
#+end_src

I am not sure if this is something to deal with my system font
configuration or it is emacs specific.
Can someone try to reproduce?

Regards,
Ihor

[org-capture.jpg (image/jpeg, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2019-12-02 built on yantar92-laptop
Repository revision: 9c0ac88199accb4133d9fbf36d3c4adc3705b22f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Gentoo/Linux

Recent messages:
Saving all Org buffers... done
Saving all Org buffers... done
Clock stopped at [2019-12-05 Thu 14:51] after 0h 1min
File digest doesn’t match, so undo history will be discarded.
Saving file /home/yantar92/.org-clock-in...
Wrote /home/yantar92/.org-clock-in
Clock starts at [2019-12-05 Thu 14:51] - showing today's task time.
When done with this frame, type x c
File digest doesn’t match, so undo history will be discarded.
line-move-1: End of buffer [3 times]

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-silent-rules
 --docdir=/usr/share/doc/emacs-vcs-27.0.9999
 --htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
 --program-suffix=-emacs-27-vcs --includedir=/usr/include/emacs-27-vcs
 --infodir=/usr/share/info/emacs-27-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-dumping=pdumper --with-file-notification=inotify --enable-acl
 --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
 --without-json --without-kerberos --without-kerberos5 --with-lcms2
 --with-xml2 --without-mailutils --without-selinux --with-gnutls
 --without-libsystemd --with-threads --without-wide-int --with-zlib
 --with-sound=alsa --with-x --without-ns --without-gconf
 --without-gsettings --without-toolkit-scroll-bars --with-gif
 --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
 --with-imagemagick --with-xft --with-cairo --without-harfbuzz
 --without-libotf --without-m17n-flt --with-x-toolkit=lucid --with-xaw3d
 'CFLAGS=-march=broadwell -pipe -O2' CPPFLAGS= 'LDFLAGS=-Wl,-O1
 -Wl,--as-needed''

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND GPM DBUS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE ZLIB LUCID X11 XDBE XIM
MODULES THREADS PDUMPER LCMS2 GMP

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

Major mode: Emacs-Lisp

Minor modes in effect:
  flycheck-mode: t
  rainbow-delimiters-mode: t
  highlight-numbers-mode: t
  easy-escape-minor-mode: t
  pretty-symbols-mode: t
  pdf-occur-global-minor-mode: t
  nameless-mode: t
  which-key-mode: t
  global-aggressive-indent-mode: t
  aggressive-indent-mode: t
  treemacs-icons-dired-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: deferred
  treemacs-fringe-indicator-mode: t
  diredfl-global-mode: t
  dired-async-mode: t
  winner-mode: t
  recentf-mode: t
  helm-global-mode: t
  helm-mode: t
  volatile-highlights-mode: t
  global-highlight-parentheses-mode: t
  highlight-parentheses-mode: t
  global-git-gutter+-mode: t
  global-magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  company-mode: t
  persistent-scratch-autosave-mode: t
  savehist-mode: t
  centered-window-mode: t
  boon-mode: t
  boon-local-mode: t
  global-hl-line-mode: t
  spaceline-helm-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  override-global-mode: t
  straight-use-package-mode: t
  straight-package-neutering-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  global-prettify-symbols-mode: t
  prettify-symbols-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  window-divider-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t
  hs-minor-mode: t

Load-path shadows:
/home/yantar92/.emacs.d/straight/build/org/org-macro hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-macro
/home/yantar92/.emacs.d/straight/build/org/org-pcomplete hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-pcomplete
/home/yantar92/.emacs.d/straight/build/org/org-keys hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-keys
/home/yantar92/.emacs.d/straight/build/org/ob-python hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-python
/home/yantar92/.emacs.d/straight/build/org/ob-clojure hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-clojure
/home/yantar92/.emacs.d/straight/build/org/org hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org
/home/yantar92/.emacs.d/straight/build/org/org-datetree hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-datetree
/home/yantar92/.emacs.d/straight/build/org/ob-stan hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-stan
/home/yantar92/.emacs.d/straight/build/org/ox hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox
/home/yantar92/.emacs.d/straight/build/org/ob-makefile hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-makefile
/home/yantar92/.emacs.d/straight/build/org/ob-js hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-js
/home/yantar92/.emacs.d/straight/build/org/ox-publish hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-publish
/home/yantar92/.emacs.d/straight/build/org/ob-awk hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-awk
/home/yantar92/.emacs.d/straight/build/org/ob-calc hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-calc
/home/yantar92/.emacs.d/straight/build/org/ox-latex hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-latex
/home/yantar92/.emacs.d/straight/build/org/ob-shell hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-shell
/home/yantar92/.emacs.d/straight/build/org/org-entities hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-entities
/home/yantar92/.emacs.d/straight/build/org/ob-lilypond hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-lilypond
/home/yantar92/.emacs.d/straight/build/org/org-install hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-install
/home/yantar92/.emacs.d/straight/build/org/ob-shen hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-shen
/home/yantar92/.emacs.d/straight/build/org/org-faces hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-faces
/home/yantar92/.emacs.d/straight/build/org/org-element hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-element
/home/yantar92/.emacs.d/straight/build/org/org-agenda hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-agenda
/home/yantar92/.emacs.d/straight/build/org/ob-exp hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-exp
/home/yantar92/.emacs.d/straight/build/org/ob-matlab hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-matlab
/home/yantar92/.emacs.d/straight/build/org/ob-haskell hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-haskell
/home/yantar92/.emacs.d/straight/build/org/ob-abc hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-abc
/home/yantar92/.emacs.d/straight/build/org/org-macs hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-macs
/home/yantar92/.emacs.d/straight/build/org/ob-fortran hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-fortran
/home/yantar92/.emacs.d/straight/build/org/org-lint hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-lint
/home/yantar92/.emacs.d/straight/build/org/org-goto hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-goto
/home/yantar92/.emacs.d/straight/build/org/ob-ref hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-ref
/home/yantar92/.emacs.d/straight/build/org/ob-lob hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-lob
/home/yantar92/.emacs.d/straight/build/org/org-duration hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-duration
/home/yantar92/.emacs.d/straight/build/org/ol-bbdb hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-bbdb
/home/yantar92/.emacs.d/straight/build/org/ob-sql hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-sql
/home/yantar92/.emacs.d/straight/build/org/ob-mscgen hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-mscgen
/home/yantar92/.emacs.d/straight/build/org/org-tempo hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-tempo
/home/yantar92/.emacs.d/straight/build/org/ol-eshell hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-eshell
/home/yantar92/.emacs.d/straight/build/org/ob-sass hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-sass
/home/yantar92/.emacs.d/straight/build/org/ob-ruby hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-ruby
/home/yantar92/.emacs.d/straight/build/org/ob-java hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-java
/home/yantar92/.emacs.d/straight/build/org/ob-css hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-css
/home/yantar92/.emacs.d/straight/build/org/ob-ocaml hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-ocaml
/home/yantar92/.emacs.d/straight/build/org/ob-screen hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-screen
/home/yantar92/.emacs.d/straight/build/org/ob-sed hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-sed
/home/yantar92/.emacs.d/straight/build/org/ob-lisp hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-lisp
/home/yantar92/.emacs.d/straight/build/org/ox-md hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-md
/home/yantar92/.emacs.d/straight/build/org/org-clock hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-clock
/home/yantar92/.emacs.d/straight/build/org/ob-maxima hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-maxima
/home/yantar92/.emacs.d/straight/build/org/ob-io hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-io
/home/yantar92/.emacs.d/straight/build/org/ob-J hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-J
/home/yantar92/.emacs.d/straight/build/org/ol-rmail hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-rmail
/home/yantar92/.emacs.d/straight/build/org/ox-org hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-org
/home/yantar92/.emacs.d/straight/build/org/ob-table hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-table
/home/yantar92/.emacs.d/straight/build/org/ol hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol
/home/yantar92/.emacs.d/straight/build/org/ob-asymptote hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-asymptote
/home/yantar92/.emacs.d/straight/build/org/ob-sqlite hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-sqlite
/home/yantar92/.emacs.d/straight/build/org/ol-w3m hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-w3m
/home/yantar92/.emacs.d/straight/build/org/ox-beamer hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-beamer
/home/yantar92/.emacs.d/straight/build/org/org-mouse hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-mouse
/home/yantar92/.emacs.d/straight/build/org/org-habit hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-habit
/home/yantar92/.emacs.d/straight/build/org/ob-gnuplot hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-gnuplot
/home/yantar92/.emacs.d/straight/build/org/org-crypt hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-crypt
/home/yantar92/.emacs.d/straight/build/org/ob-ebnf hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-ebnf
/home/yantar92/.emacs.d/straight/build/org/ob-R hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-R
/home/yantar92/.emacs.d/straight/build/org/org-inlinetask hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-inlinetask
/home/yantar92/.emacs.d/straight/build/org/ol-irc hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-irc
/home/yantar92/.emacs.d/straight/build/org/org-archive hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-archive
/home/yantar92/.emacs.d/straight/build/org/ol-docview hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-docview
/home/yantar92/.emacs.d/straight/build/org/ob-plantuml hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-plantuml
/home/yantar92/.emacs.d/straight/build/org/ob-eshell hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-eshell
/home/yantar92/.emacs.d/straight/build/org/ob-eval hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-eval
/home/yantar92/.emacs.d/straight/build/org/ox-texinfo hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-texinfo
/home/yantar92/.emacs.d/straight/build/org/ob-dot hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-dot
/home/yantar92/.emacs.d/straight/build/org/ob hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob
/home/yantar92/.emacs.d/straight/build/org/ob-coq hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-coq
/home/yantar92/.emacs.d/straight/build/org/ol-info hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-info
/home/yantar92/.emacs.d/straight/build/org/org-loaddefs hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-loaddefs
/home/yantar92/.emacs.d/straight/build/org/ob-ditaa hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-ditaa
/home/yantar92/.emacs.d/straight/build/org/org-mobile hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-mobile
/home/yantar92/.emacs.d/straight/build/org/ox-man hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-man
/home/yantar92/.emacs.d/straight/build/org/ob-emacs-lisp hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-emacs-lisp
/home/yantar92/.emacs.d/straight/build/org/ol-gnus hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-gnus
/home/yantar92/.emacs.d/straight/build/org/ob-lua hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-lua
/home/yantar92/.emacs.d/straight/build/org/org-protocol hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-protocol
/home/yantar92/.emacs.d/straight/build/org/org-compat hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-compat
/home/yantar92/.emacs.d/straight/build/org/ob-vala hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-vala
/home/yantar92/.emacs.d/straight/build/org/ob-org hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-org
/home/yantar92/.emacs.d/straight/build/org/ox-html hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-html
/home/yantar92/.emacs.d/straight/build/org/org-list hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-list
/home/yantar92/.emacs.d/straight/build/org/ol-bibtex hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-bibtex
/home/yantar92/.emacs.d/straight/build/org/ob-forth hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-forth
/home/yantar92/.emacs.d/straight/build/org/org-indent hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-indent
/home/yantar92/.emacs.d/straight/build/org/org-footnote hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-footnote
/home/yantar92/.emacs.d/straight/build/org/ob-scheme hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-scheme
/home/yantar92/.emacs.d/straight/build/org/ob-tangle hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-tangle
/home/yantar92/.emacs.d/straight/build/org/ox-icalendar hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-icalendar
/home/yantar92/.emacs.d/straight/build/org/ol-eww hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-eww
/home/yantar92/.emacs.d/straight/build/org/ob-octave hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-octave
/home/yantar92/.emacs.d/straight/build/org/ob-ledger hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-ledger
/home/yantar92/.emacs.d/straight/build/org/org-num hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-num
/home/yantar92/.emacs.d/straight/build/org/ob-picolisp hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-picolisp
/home/yantar92/.emacs.d/straight/build/org/ob-latex hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-latex
/home/yantar92/.emacs.d/straight/build/org/ob-groovy hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-groovy
/home/yantar92/.emacs.d/straight/build/org/org-id hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-id
/home/yantar92/.emacs.d/straight/build/org/ob-core hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-core
/home/yantar92/.emacs.d/straight/build/org/ob-processing hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-processing
/home/yantar92/.emacs.d/straight/build/org/org-capture hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-capture
/home/yantar92/.emacs.d/straight/build/org/ob-C hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-C
/home/yantar92/.emacs.d/straight/build/org/ox-odt hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-odt
/home/yantar92/.emacs.d/straight/build/org/org-attach-git hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-attach-git
/home/yantar92/.emacs.d/straight/build/org/org-feed hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-feed
/home/yantar92/.emacs.d/straight/build/org/org-ctags hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-ctags
/home/yantar92/.emacs.d/straight/build/org/org-src hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-src
/home/yantar92/.emacs.d/straight/build/org/org-colview hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-colview
/home/yantar92/.emacs.d/straight/build/org/ox-ascii hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ox-ascii
/home/yantar92/.emacs.d/straight/build/org/org-plot hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-plot
/home/yantar92/.emacs.d/straight/build/org/ob-comint hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-comint
/home/yantar92/.emacs.d/straight/build/org/org-timer hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-timer
/home/yantar92/.emacs.d/straight/build/org/org-attach hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-attach
/home/yantar92/.emacs.d/straight/build/org/ob-perl hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-perl
/home/yantar92/.emacs.d/straight/build/org/org-table hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/org-table
/home/yantar92/.emacs.d/straight/build/org/ol-mhe hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ol-mhe
/home/yantar92/.emacs.d/straight/build/org/ob-hledger hides /home/yantar92/.emacs.d/straight/build/org-plus-contrib/ob-hledger
/home/yantar92/.emacs.d/straight/build/helpful/helpful hides /home/yantar92/.emacs.d/site-lisp/helpful/helpful
/home/yantar92/.emacs.d/straight/build/fringe-helper/fringe-helper hides /home/yantar92/.emacs.d/site-lisp/fringe-helper.el/fringe-helper
/home/yantar92/.emacs.d/site-lisp/spaceline-all-the-icons.el/spaceline-all-the-icons hides ~/.emacs.d/site-lisp/spaceline-all-the-icons
/home/yantar92/.emacs.d/straight/build/fringe-helper/fringe-helper hides ~/.emacs.d/site-lisp/fringe-helper
/home/yantar92/.emacs.d/straight/build/dash-functional/dash-functional hides /usr/share/emacs/site-lisp/dash/dash-functional
/home/yantar92/.emacs.d/straight/build/dash/dash hides /usr/share/emacs/site-lisp/dash/dash
/home/yantar92/.emacs.d/straight/build/f/f hides /usr/share/emacs/site-lisp/f/f
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-draft hides /usr/share/emacs/site-lisp/notmuch/notmuch-draft
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-tree hides /usr/share/emacs/site-lisp/notmuch/notmuch-tree
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-hello hides /usr/share/emacs/site-lisp/notmuch/notmuch-hello
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-parser hides /usr/share/emacs/site-lisp/notmuch/notmuch-parser
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-query hides /usr/share/emacs/site-lisp/notmuch/notmuch-query
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-crypto hides /usr/share/emacs/site-lisp/notmuch/notmuch-crypto
/home/yantar92/.emacs.d/straight/build/notmuch/coolj hides /usr/share/emacs/site-lisp/notmuch/coolj
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-mua hides /usr/share/emacs/site-lisp/notmuch/notmuch-mua
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-tag hides /usr/share/emacs/site-lisp/notmuch/notmuch-tag
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-wash hides /usr/share/emacs/site-lisp/notmuch/notmuch-wash
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-show hides /usr/share/emacs/site-lisp/notmuch/notmuch-show
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-address hides /usr/share/emacs/site-lisp/notmuch/notmuch-address
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-print hides /usr/share/emacs/site-lisp/notmuch/notmuch-print
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-maildir-fcc hides /usr/share/emacs/site-lisp/notmuch/notmuch-maildir-fcc
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-compat hides /usr/share/emacs/site-lisp/notmuch/notmuch-compat
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-message hides /usr/share/emacs/site-lisp/notmuch/notmuch-message
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-company hides /usr/share/emacs/site-lisp/notmuch/notmuch-company
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch hides /usr/share/emacs/site-lisp/notmuch/notmuch
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-lib hides /usr/share/emacs/site-lisp/notmuch/notmuch-lib
/home/yantar92/.emacs.d/straight/build/notmuch/notmuch-jump hides /usr/share/emacs/site-lisp/notmuch/notmuch-jump
/home/yantar92/.emacs.d/straight/build/s/s hides /usr/share/emacs/site-lisp/s/s
/home/yantar92/.emacs.d/straight/build/with-editor/with-editor hides /usr/share/emacs/site-lisp/with-editor/with-editor
/home/yantar92/.emacs.d/site-lisp/centered-window-mode/custom hides /usr/share/emacs/27.0.50/lisp/custom
/home/yantar92/.emacs.d/straight/build/org/org-macro hides /usr/share/emacs/27.0.50/lisp/org/org-macro
/home/yantar92/.emacs.d/straight/build/org/org-pcomplete hides /usr/share/emacs/27.0.50/lisp/org/org-pcomplete
/home/yantar92/.emacs.d/straight/build/org/ob-python hides /usr/share/emacs/27.0.50/lisp/org/ob-python
/home/yantar92/.emacs.d/straight/build/org/ob-clojure hides /usr/share/emacs/27.0.50/lisp/org/ob-clojure
/home/yantar92/.emacs.d/straight/build/org/org hides /usr/share/emacs/27.0.50/lisp/org/org
/home/yantar92/.emacs.d/straight/build/org/org-datetree hides /usr/share/emacs/27.0.50/lisp/org/org-datetree
/home/yantar92/.emacs.d/straight/build/org/ob-stan hides /usr/share/emacs/27.0.50/lisp/org/ob-stan
/home/yantar92/.emacs.d/straight/build/org/ox hides /usr/share/emacs/27.0.50/lisp/org/ox
/home/yantar92/.emacs.d/straight/build/org/ob-makefile hides /usr/share/emacs/27.0.50/lisp/org/ob-makefile
/home/yantar92/.emacs.d/straight/build/org/ob-js hides /usr/share/emacs/27.0.50/lisp/org/ob-js
/home/yantar92/.emacs.d/straight/build/org/ox-publish hides /usr/share/emacs/27.0.50/lisp/org/ox-publish
/home/yantar92/.emacs.d/straight/build/org/ob-awk hides /usr/share/emacs/27.0.50/lisp/org/ob-awk
/home/yantar92/.emacs.d/straight/build/org/ob-calc hides /usr/share/emacs/27.0.50/lisp/org/ob-calc
/home/yantar92/.emacs.d/straight/build/org/ox-latex hides /usr/share/emacs/27.0.50/lisp/org/ox-latex
/home/yantar92/.emacs.d/straight/build/org/ob-shell hides /usr/share/emacs/27.0.50/lisp/org/ob-shell
/home/yantar92/.emacs.d/straight/build/org/org-entities hides /usr/share/emacs/27.0.50/lisp/org/org-entities
/home/yantar92/.emacs.d/straight/build/org/ob-lilypond hides /usr/share/emacs/27.0.50/lisp/org/ob-lilypond
/home/yantar92/.emacs.d/straight/build/org/org-install hides /usr/share/emacs/27.0.50/lisp/org/org-install
/home/yantar92/.emacs.d/straight/build/org/ob-shen hides /usr/share/emacs/27.0.50/lisp/org/ob-shen
/home/yantar92/.emacs.d/straight/build/org/org-faces hides /usr/share/emacs/27.0.50/lisp/org/org-faces
/home/yantar92/.emacs.d/straight/build/org/org-element hides /usr/share/emacs/27.0.50/lisp/org/org-element
/home/yantar92/.emacs.d/straight/build/org/org-agenda hides /usr/share/emacs/27.0.50/lisp/org/org-agenda
/home/yantar92/.emacs.d/straight/build/org/ob-exp hides /usr/share/emacs/27.0.50/lisp/org/ob-exp
/home/yantar92/.emacs.d/straight/build/org/ob-matlab hides /usr/share/emacs/27.0.50/lisp/org/ob-matlab
/home/yantar92/.emacs.d/straight/build/org/ob-haskell hides /usr/share/emacs/27.0.50/lisp/org/ob-haskell
/home/yantar92/.emacs.d/straight/build/org/ob-abc hides /usr/share/emacs/27.0.50/lisp/org/ob-abc
/home/yantar92/.emacs.d/straight/build/org/org-macs hides /usr/share/emacs/27.0.50/lisp/org/org-macs
/home/yantar92/.emacs.d/straight/build/org/ob-fortran hides /usr/share/emacs/27.0.50/lisp/org/ob-fortran
/home/yantar92/.emacs.d/straight/build/org/org-lint hides /usr/share/emacs/27.0.50/lisp/org/org-lint
/home/yantar92/.emacs.d/straight/build/org/ob-ref hides /usr/share/emacs/27.0.50/lisp/org/ob-ref
/home/yantar92/.emacs.d/straight/build/org/ob-lob hides /usr/share/emacs/27.0.50/lisp/org/ob-lob
/home/yantar92/.emacs.d/straight/build/org/org-duration hides /usr/share/emacs/27.0.50/lisp/org/org-duration
/home/yantar92/.emacs.d/straight/build/org/ob-sql hides /usr/share/emacs/27.0.50/lisp/org/ob-sql
/home/yantar92/.emacs.d/straight/build/org/ob-mscgen hides /usr/share/emacs/27.0.50/lisp/org/ob-mscgen
/home/yantar92/.emacs.d/straight/build/org/ob-sass hides /usr/share/emacs/27.0.50/lisp/org/ob-sass
/home/yantar92/.emacs.d/straight/build/org/ob-ruby hides /usr/share/emacs/27.0.50/lisp/org/ob-ruby
/home/yantar92/.emacs.d/straight/build/org/ob-java hides /usr/share/emacs/27.0.50/lisp/org/ob-java
/home/yantar92/.emacs.d/straight/build/org/ob-css hides /usr/share/emacs/27.0.50/lisp/org/ob-css
/home/yantar92/.emacs.d/straight/build/org/ob-ocaml hides /usr/share/emacs/27.0.50/lisp/org/ob-ocaml
/home/yantar92/.emacs.d/straight/build/org/ob-screen hides /usr/share/emacs/27.0.50/lisp/org/ob-screen
/home/yantar92/.emacs.d/straight/build/org/ob-sed hides /usr/share/emacs/27.0.50/lisp/org/ob-sed
/home/yantar92/.emacs.d/straight/build/org/ob-lisp hides /usr/share/emacs/27.0.50/lisp/org/ob-lisp
/home/yantar92/.emacs.d/straight/build/org/ox-md hides /usr/share/emacs/27.0.50/lisp/org/ox-md
/home/yantar92/.emacs.d/straight/build/org/org-clock hides /usr/share/emacs/27.0.50/lisp/org/org-clock
/home/yantar92/.emacs.d/straight/build/org/ob-maxima hides /usr/share/emacs/27.0.50/lisp/org/ob-maxima
/home/yantar92/.emacs.d/straight/build/org/ob-io hides /usr/share/emacs/27.0.50/lisp/org/ob-io
/home/yantar92/.emacs.d/straight/build/org/ob-J hides /usr/share/emacs/27.0.50/lisp/org/ob-J
/home/yantar92/.emacs.d/straight/build/org/ox-org hides /usr/share/emacs/27.0.50/lisp/org/ox-org
/home/yantar92/.emacs.d/straight/build/org/ob-table hides /usr/share/emacs/27.0.50/lisp/org/ob-table
/home/yantar92/.emacs.d/straight/build/org/ob-asymptote hides /usr/share/emacs/27.0.50/lisp/org/ob-asymptote
/home/yantar92/.emacs.d/straight/build/org/ob-sqlite hides /usr/share/emacs/27.0.50/lisp/org/ob-sqlite
/home/yantar92/.emacs.d/straight/build/org/ox-beamer hides /usr/share/emacs/27.0.50/lisp/org/ox-beamer
/home/yantar92/.emacs.d/straight/build/org/org-mouse hides /usr/share/emacs/27.0.50/lisp/org/org-mouse
/home/yantar92/.emacs.d/straight/build/org/org-habit hides /usr/share/emacs/27.0.50/lisp/org/org-habit
/home/yantar92/.emacs.d/straight/build/org/ob-gnuplot hides /usr/share/emacs/27.0.50/lisp/org/ob-gnuplot
/home/yantar92/.emacs.d/straight/build/org/org-crypt hides /usr/share/emacs/27.0.50/lisp/org/org-crypt
/home/yantar92/.emacs.d/straight/build/org/ob-ebnf hides /usr/share/emacs/27.0.50/lisp/org/ob-ebnf
/home/yantar92/.emacs.d/straight/build/org/ob-R hides /usr/share/emacs/27.0.50/lisp/org/ob-R
/home/yantar92/.emacs.d/straight/build/org/org-inlinetask hides /usr/share/emacs/27.0.50/lisp/org/org-inlinetask
/home/yantar92/.emacs.d/straight/build/org/org-archive hides /usr/share/emacs/27.0.50/lisp/org/org-archive
/home/yantar92/.emacs.d/straight/build/org/ob-plantuml hides /usr/share/emacs/27.0.50/lisp/org/ob-plantuml
/home/yantar92/.emacs.d/straight/build/org/ob-eval hides /usr/share/emacs/27.0.50/lisp/org/ob-eval
/home/yantar92/.emacs.d/straight/build/org/ox-texinfo hides /usr/share/emacs/27.0.50/lisp/org/ox-texinfo
/home/yantar92/.emacs.d/straight/build/org/ob-dot hides /usr/share/emacs/27.0.50/lisp/org/ob-dot
/home/yantar92/.emacs.d/straight/build/org/ob hides /usr/share/emacs/27.0.50/lisp/org/ob
/home/yantar92/.emacs.d/straight/build/org/ob-coq hides /usr/share/emacs/27.0.50/lisp/org/ob-coq
/home/yantar92/.emacs.d/straight/build/org/org-loaddefs hides /usr/share/emacs/27.0.50/lisp/org/org-loaddefs
/home/yantar92/.emacs.d/straight/build/org/ob-ditaa hides /usr/share/emacs/27.0.50/lisp/org/ob-ditaa
/home/yantar92/.emacs.d/straight/build/org/org-mobile hides /usr/share/emacs/27.0.50/lisp/org/org-mobile
/home/yantar92/.emacs.d/straight/build/org/ox-man hides /usr/share/emacs/27.0.50/lisp/org/ox-man
/home/yantar92/.emacs.d/straight/build/org/ob-emacs-lisp hides /usr/share/emacs/27.0.50/lisp/org/ob-emacs-lisp
/home/yantar92/.emacs.d/straight/build/org/ob-lua hides /usr/share/emacs/27.0.50/lisp/org/ob-lua
/home/yantar92/.emacs.d/straight/build/org/org-protocol hides /usr/share/emacs/27.0.50/lisp/org/org-protocol
/home/yantar92/.emacs.d/straight/build/org/org-compat hides /usr/share/emacs/27.0.50/lisp/org/org-compat
/home/yantar92/.emacs.d/straight/build/org/ob-vala hides /usr/share/emacs/27.0.50/lisp/org/ob-vala
/home/yantar92/.emacs.d/straight/build/org/ob-org hides /usr/share/emacs/27.0.50/lisp/org/ob-org
/home/yantar92/.emacs.d/straight/build/org/ox-html hides /usr/share/emacs/27.0.50/lisp/org/ox-html
/home/yantar92/.emacs.d/straight/build/org/org-list hides /usr/share/emacs/27.0.50/lisp/org/org-list
/home/yantar92/.emacs.d/straight/build/org/ob-forth hides /usr/share/emacs/27.0.50/lisp/org/ob-forth
/home/yantar92/.emacs.d/straight/build/org/org-indent hides /usr/share/emacs/27.0.50/lisp/org/org-indent
/home/yantar92/.emacs.d/straight/build/org/org-footnote hides /usr/share/emacs/27.0.50/lisp/org/org-footnote
/home/yantar92/.emacs.d/straight/build/org/ob-scheme hides /usr/share/emacs/27.0.50/lisp/org/ob-scheme
/home/yantar92/.emacs.d/straight/build/org/ob-tangle hides /usr/share/emacs/27.0.50/lisp/org/ob-tangle
/home/yantar92/.emacs.d/straight/build/org/ox-icalendar hides /usr/share/emacs/27.0.50/lisp/org/ox-icalendar
/home/yantar92/.emacs.d/straight/build/org/ob-octave hides /usr/share/emacs/27.0.50/lisp/org/ob-octave
/home/yantar92/.emacs.d/straight/build/org/ob-ledger hides /usr/share/emacs/27.0.50/lisp/org/ob-ledger
/home/yantar92/.emacs.d/straight/build/org/ob-picolisp hides /usr/share/emacs/27.0.50/lisp/org/ob-picolisp
/home/yantar92/.emacs.d/straight/build/org/ob-latex hides /usr/share/emacs/27.0.50/lisp/org/ob-latex
/home/yantar92/.emacs.d/straight/build/org/ob-groovy hides /usr/share/emacs/27.0.50/lisp/org/ob-groovy
/home/yantar92/.emacs.d/straight/build/org/org-id hides /usr/share/emacs/27.0.50/lisp/org/org-id
/home/yantar92/.emacs.d/straight/build/org/ob-core hides /usr/share/emacs/27.0.50/lisp/org/ob-core
/home/yantar92/.emacs.d/straight/build/org/ob-processing hides /usr/share/emacs/27.0.50/lisp/org/ob-processing
/home/yantar92/.emacs.d/straight/build/org/org-capture hides /usr/share/emacs/27.0.50/lisp/org/org-capture
/home/yantar92/.emacs.d/straight/build/org/ob-C hides /usr/share/emacs/27.0.50/lisp/org/ob-C
/home/yantar92/.emacs.d/straight/build/org/ox-odt hides /usr/share/emacs/27.0.50/lisp/org/ox-odt
/home/yantar92/.emacs.d/straight/build/org/org-feed hides /usr/share/emacs/27.0.50/lisp/org/org-feed
/home/yantar92/.emacs.d/straight/build/org/org-ctags hides /usr/share/emacs/27.0.50/lisp/org/org-ctags
/home/yantar92/.emacs.d/straight/build/org/org-src hides /usr/share/emacs/27.0.50/lisp/org/org-src
/home/yantar92/.emacs.d/straight/build/org/org-colview hides /usr/share/emacs/27.0.50/lisp/org/org-colview
/home/yantar92/.emacs.d/straight/build/org/ox-ascii hides /usr/share/emacs/27.0.50/lisp/org/ox-ascii
/home/yantar92/.emacs.d/straight/build/org/org-plot hides /usr/share/emacs/27.0.50/lisp/org/org-plot
/home/yantar92/.emacs.d/straight/build/org/ob-comint hides /usr/share/emacs/27.0.50/lisp/org/ob-comint
/home/yantar92/.emacs.d/straight/build/org/org-timer hides /usr/share/emacs/27.0.50/lisp/org/org-timer
/home/yantar92/.emacs.d/straight/build/org/org-attach hides /usr/share/emacs/27.0.50/lisp/org/org-attach
/home/yantar92/.emacs.d/straight/build/org/ob-perl hides /usr/share/emacs/27.0.50/lisp/org/ob-perl
/home/yantar92/.emacs.d/straight/build/org/org-table hides /usr/share/emacs/27.0.50/lisp/org/org-table
/home/yantar92/.emacs.d/straight/build/org/ob-hledger hides /usr/share/emacs/27.0.50/lisp/org/ob-hledger
/home/yantar92/.emacs.d/straight/build/cl-lib/cl-lib hides /usr/share/emacs/27.0.50/lisp/emacs-lisp/cl-lib
/home/yantar92/.emacs.d/straight/build/let-alist/let-alist hides /usr/share/emacs/27.0.50/lisp/emacs-lisp/let-alist
/home/yantar92/.emacs.d/straight/build/seq/seq hides /usr/share/emacs/27.0.50/lisp/emacs-lisp/seq

Features:
(shadow emacsbug ledger-mode ledger-check ledger-texi ledger-test
ledger-sort ledger-report ledger-reconcile ledger-occur ledger-fonts
ledger-fontify ledger-state ledger-complete ledger-schedule ledger-init
ledger-xact ledger-post ledger-exec ledger-navigate eshell esh-cmd
esh-ext esh-opt esh-proc esh-io esh-module esh-groups ledger-context
ledger-commodities esh-arg esh-util ledger-regex w3m-form w3m w3m-hist
w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon w3m-image w3m-proc
w3m-util sendmail qp org-quick-peek cal-move network-stream url-cache
use-package-ensure two-column eieio-opt speedbar sb-image ezimage dframe
tabify sh-script executable helm-x-files mule-util reftex-parse
elfeed-link mail-extr mm-archive misearch multi-isearch cl-print cal-iso
gnuplot-gui gnuplot hideshow flycheck-tip error-tip
flycheck-tip-autoloads flycheck rainbow-delimiters highlight-numbers
parent-mode easy-escape sort org-duration ffap org-table-sticky-header
ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnir ol-docview doc-view
ol-bbdb ol-w3m dired-du find-dired dired-du-autoloads
dired-hide-dotfiles ol-notmuch org-eldoc
org-table-sticky-header-autoloads pretty-symbols ob-async
ob-async-autoloads ob-mathematica ob-latex ob-dot ob-calc calc-store
calc-trail calc-ext calc calc-loaddefs calc-macs ob-gnuplot ob-ditaa
ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs ob-python ob-perl ob-org ob-shell org-tempo
tempo ov ov-autoloads ox-md ox-extra org-capture-pop-frame
org-capture-pop-frame-autoloads org-protocol pomidor-autoloads org-clock
org-autosort helm-org-contacts org-contacts gnus-art mm-uu mml2015
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus
nnheader org-quick-peek-autoloads quick-peek quick-peek-autoloads
org-gcal org-archive request-deferred deferred alert log4e notifications
dbus gntp org-gcal-autoloads alert-autoloads log4e-autoloads
gntp-autoloads request-deferred-autoloads deferred-autoloads calfw-org
calfw-org-autoloads calfw holidays hol-loaddefs calfw-autoloads
org-web-tools-autoloads esxml-autoloads org-attach helm-recoll
helm-for-files helm-bookmark helm-adaptive helm-external
helm-recoll-autoloads org-ref-url-utils org-ref org-ref-helm-bibtex
org-ref-helm helm-bibtex bibtex-completion biblio biblio-download
biblio-dissemin biblio-ieee biblio-hal biblio-dblp biblio-crossref
biblio-arxiv timezone biblio-doi biblio-core ido helm-net org-ref-core
warnings reftex-cite reftex reftex-loaddefs reftex-vars parsebib ox-odt
rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse
nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table
ox-ascii ox-publish ox org-ref-glossary org-ref-bibtex org-ref-citeproc
org-element key-chord doi-utils org-ref-utils org-ref-pdf ol-bibtex
bibtex htmlize org-ref-autoloads key-chord-autoloads ivy-autoloads
helm-bibtex-autoloads biblio-autoloads biblio-core-autoloads
parsebib-autoloads htmlize-autoloads org-id scimax-inkscape org-pdfview
org-pdfview-autoloads org-capture org-checklist org-habit org-agenda
org-edna org-edna-autoloads org-inlinetask org-autoloads
notmuch-calendar-x helm-notmuch helm-notmuch-autoloads notmuch
notmuch-hello notmuch-tree notmuch-show notmuch-print notmuch-crypto
notmuch-mua notmuch-message notmuch-draft notmuch-maildir-fcc
notmuch-address notmuch-company notmuch-parser notmuch-wash coolj
notmuch-query goto-addr icalendar diary-lib diary-loaddefs notmuch-tag
notmuch-lib notmuch-version notmuch-compat mm-view mml-smime smime dig
notmuch-autoloads elfeed-org elfeed-show elfeed-search shr svg dom
elfeed-csv elfeed elfeed-curl elfeed-log elfeed-db elfeed-lib avl-tree
url-queue xml-query xml elfeed-org-autoloads elfeed-autoloads mingus
libmpdee mingus-autoloads libmpdee-autoloads shell-pop-autoloads
eterm-256color-autoloads xterm-color-autoloads vterm-autoloads
pdf-view-restore pdf-view-restore-autoloads pdf-sync pdf-outline
pdf-links pdf-history pdf-occur ibuf-ext ibuffer ibuffer-loaddefs
pdf-isearch pdf-tools pdf-annot tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw mode-local cedet org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list
org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval
org-table ol org-keys org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs pdf-misc pdf-view treemacs-bookmarks magit-bookmark
bookmark pp jka-compr pdf-cache pdf-info tq pdf-util pdf-tools-autoloads
tablist-autoloads wolfram-mode smie wolfram-mode-autoloads
ledger-mode-autoloads gnuplot-autoloads nameless lisp-mnt
nameless-autoloads eros rsw-elisp quickrun-autoloads eros-autoloads
bug-hunter bug-hunter-autoloads elisp-demos elisp-demos-autoloads
helpful trace info-look dash-functional elisp-refs loop
helpful-autoloads elisp-refs-autoloads loop-autoloads
dash-functional-autoloads tldr request tldr-autoloads request-autoloads
helm-descbinds helm-descbinds-autoloads which-key which-key-autoloads
lorem-ipsum lorem-ipsum-autoloads debug undohist undohist-autoloads
yasnippet yasnippet-autoloads move-text-autoloads aggressive-indent
aggressive-indent-autoloads comment-dwim-2-autoloads
visual-regexp-steroids visual-regexp visual-regexp-steroids-autoloads
visual-regexp-autoloads helm-org-rifle-autoloads treemacs-icons-dired
treemacs treemacs-compatibility treemacs-mode treemacs-interface
treemacs-extensions treemacs-persistence treemacs-mouse-interface
treemacs-tag-follow-mode treemacs-filewatch-mode treemacs-tags
treemacs-follow-mode treemacs-rendering treemacs-async treemacs-faces
treemacs-icons treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator pulse treemacs-themes treemacs-core-utils
pfuture ace-window avy treemacs-macros inline ht treemacs-customization
treemacs-icons-dired-autoloads treemacs-autoloads ht-autoloads
pfuture-autoloads ace-window-autoloads diredfl diredfl-autoloads
dired-filter f dired-hacks-utils dired-filter-autoloads f-autoloads
dired-hacks-utils-autoloads dired-async dired+ image-dired image-mode
exif image-file help-fns+ help-fns radix-tree dired-x dired-aux
dired-hide-dotfiles-autoloads disk-usage disk-usage-autoloads winner
helm-bm compile recentf tree-widget helm-command helm-elisp helm-eval
edebug backtrace helm-info helm-mode helm-files helm-buffers helm-occur
helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help
helm-types helm-config helm-easymenu helm helm-source helm-multi-match
helm-lib helm-bm-autoloads bm bm-autoloads goto-line-preview
goto-line-preview-autoloads cus-edit cus-start cus-load wid-edit
avy-autoloads git-gutter-fringe git-gutter git-gutter-fringe-autoloads
git-gutter-autoloads volatile-highlights volatile-highlights-autoloads
easy-escape-autoloads highlight-numbers-autoloads parent-mode-autoloads
rainbow-delimiters-autoloads highlight-parentheses
highlight-parentheses-autoloads flycheck-autoloads seq-autoloads
pkg-info-autoloads epl-autoloads flyspell ispell hi-lock
git-gutter-fringe+ git-gutter+ tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat ls-lisp fringe-helper
git-gutter-fringe+-autoloads fringe-helper-autoloads
git-gutter+-autoloads forge-list forge-commands forge-semi
forge-bitbucket buck forge-gogs gogs forge-gitea gtea forge-gitlab glab
forge-github ghub-graphql treepy gsexp ghub let-alist gnutls
forge-notify forge-revnote forge-pullreq forge-issue forge-topic
parse-time iso8601 bug-reference forge-post markdown-mode noutline
outline forge-repo forge forge-core forge-db closql emacsql-sqlite
emacsql emacsql-compiler url-http url-auth url-gw nsm url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap forge-autoloads closql-autoloads
emacsql-sqlite-autoloads emacsql-autoloads magithub-autoloads
markdown-mode-autoloads ghub+-autoloads apiwrap-autoloads ghub-autoloads
treepy-autoloads let-alist-autoloads magit-submodule magit-obsolete
magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magit-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge magit-branch
magit-reset magit-files magit-refs magit-status magit package browse-url
url-handlers url-parse auth-source json map url-vars magit-repos
magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode
diff diff-mode magit-core magit-autorevert magit-margin magit-transient
magit-process magit-mode git-commit magit-git magit-section magit-utils
crm log-edit message rmc puny dired dired-loaddefs rfc822 mml mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date 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 with-editor
async-bytecomp async shell pcomplete comint ansi-color transient
format-spec magit-autoloads transient-autoloads git-commit-autoloads
with-editor-autoloads autorevert filenotify disp-table company-oddmuse
company-keywords company-etags etags fileloop generator xref project
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-cmake company-xcode company-clang company-semantic
company-eclim company-template company-bbdb company pcase
persistent-scratch persistent-scratch-autoloads savehist
backup-walker-autoloads company-autoloads helm-autoloads
helm-core-autoloads pyim-basedict pyim pyim-probe xr rx pyim-common
pyim-pymap popup pyim-autoloads pyim-basedict-autoloads xr-autoloads
async-autoloads popup-autoloads avoid reverse-im quail
reverse-im-autoloads boon-qwerty boon-powerline centered-window
centered-window-mode face-remap boon boon-moves find-func
er-basic-expansions expand-region-core expand-region-custom boon-search
boon-keys boon-main boon-arguments multiple-cursors
mc-hide-unmatched-lines-mode mc-separate-operations
rectangular-region-mode mc-mark-pop mc-mark-more thingatpt
mc-cycle-cursors mc-edit-lines multiple-cursors-core rect boon-regs
boon-utils boon-core boon-autoloads multiple-cursors-autoloads
expand-region-autoloads meta-functions hl-line spaceline-config
spaceline-segments s spaceline dash spaceline-autoloads s-autoloads
dash-autoloads smart-mode-line rich-minority smart-mode-line-autoloads
rich-minority-autoloads powerline advice powerline-separators color
powerline-themes powerline-autoloads latex-pretty-symbols
latex-pretty-symbols-autoloads pretty-symbols-autoloads page-break-lines
page-break-lines-autoloads persistent-soft list-utils pcache
eieio-compat eieio-base eieio eieio-core eieio-loaddefs font-utils
unicode-fonts unicode-fonts-autoloads ucs-utils-autoloads
font-utils-autoloads persistent-soft-autoloads list-utils-autoloads cl
pcache-autoloads finder-inf use-package-diminish flatui-theme
flatui-theme-autoloads gcmh-autoloads edmacro kmacro hydra ring lv
hydra-autoloads lv-autoloads cl-lib-autoloads use-package-bind-key
org-plus-contrib-autoloads bind-key easy-mmode diminish
diminish-autoloads cl-seq use-package-core use-package-autoloads
bind-key-autoloads straight-autoloads info cl-extra help-mode easymenu
seq byte-opt straight subr-x cl-macs cl-loaddefs cl-lib bytecomp
byte-compile cconv server gv site-gentoo w3m-load tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
font-render-setting cairo x-toolkit x multi-tty make-network-process
emacs)

Memory information:
((conses 16 2501291 452575)
 (symbols 48 74805 29)
 (strings 32 650442 77004)
 (string-bytes 1 31136989)
 (vectors 16 300390)
 (vector-slots 8 4352820 193870)
 (floats 8 31323 3619)
 (intervals 56 142456 3380)
 (buffers 1000 133))

Message #8 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 'Ihor Radchenko' <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Thu, 5 Dec 2019 10:10:50 +0100

> A while ago I noticed that pop-up org-capture frames are not rendered
> (no buffer or mode-line text is shown, as in attached image) when the
> window manager forces them to be full screen (floating frames are
> rendered as usual).
>
> The issue seems to be triggered by the combination of
> maximised frame, frame-resize-pixelwise 't, custom-setting a certain
> default font, and loading certain colour theme.

Many window managers can only maximize a frame, full screen is
something the application has to provide by herself (via <F11>, for
example).  The missing title bar seems to indicate that your frame is
full screen, is that right?  Does the frame then redraw when you hit
F11 twice?  Does the problem happen with maximized frames too?

> ;; Using this instead of custom-set-faces does not trigger the rendering problem
> ;; (set-face-attribute 'default nil
> ;; 			  :foundry "adobe"
> ;; 			  :family "source code pro")
> (custom-set-faces
>   '(default ((t (:foundry "adobe" :family "source code pro"))))
> )

It would be interesting to look into what the differences between the
two are ;-)

Could you try with a GTK (or Motif) build whether they exhibit the
same behavior?

martin

Message #11 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Thu, 05 Dec 2019 18:21:13 +0800

> Many window managers can only maximize a frame, full screen is
> something the application has to provide by herself (via <F11>, for
> example).  The missing title bar seems to indicate that your frame is
> full screen, is that right?  Does the frame then redraw when you hit
> F11 twice?  Does the problem happen with maximized frames too?

Oh. I meant maximised, not full screen. Initially, I observed the issue
with maximised emacs frames. (My title bar is located at the bottom of
the frame, not on top).

> It would be interesting to look into what the differences between the
> two are ;-)

I also tested the actual full screen (if it matters, I use Awesome WM).
The problem persists. However (!), there is also no rendering when using 
set-face-attribute in full screen.

> Could you try with a GTK (or Motif) build whether they exhibit the
> same behavior?

I have tested using both GTK and Motif. The rendering is all right with
those builds. 

Best,
Ihor


martin rudalics <rudalics <at> gmx.at> writes:

>  > A while ago I noticed that pop-up org-capture frames are not rendered
>  > (no buffer or mode-line text is shown, as in attached image) when the
>  > window manager forces them to be full screen (floating frames are
>  > rendered as usual).
>  >
>  > The issue seems to be triggered by the combination of
>  > maximised frame, frame-resize-pixelwise 't, custom-setting a certain
>  > default font, and loading certain colour theme.
>
> Many window managers can only maximize a frame, full screen is
> something the application has to provide by herself (via <F11>, for
> example).  The missing title bar seems to indicate that your frame is
> full screen, is that right?  Does the frame then redraw when you hit
> F11 twice?  Does the problem happen with maximized frames too?
>
>  > ;; Using this instead of custom-set-faces does not trigger the rendering problem
>  > ;; (set-face-attribute 'default nil
>  > ;; 			  :foundry "adobe"
>  > ;; 			  :family "source code pro")
>  > (custom-set-faces
>  >   '(default ((t (:foundry "adobe" :family "source code pro"))))
>  > )
>
> It would be interesting to look into what the differences between the
> two are ;-)
>
> Could you try with a GTK (or Motif) build whether they exhibit the
> same behavior?
>
> martin

Message #14 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Thu, 5 Dec 2019 14:45:39 +0100

> Oh. I meant maximised, not full screen. Initially, I observed the issue
> with maximised emacs frames. (My title bar is located at the bottom of
> the frame, not on top).

I see it, now.  The following is a bit tedious: Couldy you try in
widget.c and xterm.c to selectively make frame_resize_pixelwise have
no effect, so we could possibly locate the direct source of the
problem?  There are four instances of this, three in widget.c and one
in xterm.c.  For example, for the latter, you would have to change the
two lines

  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);

in x_wm_set_size_hint in xterm.c to

  size_hints.width_inc = FRAME_COLUMN_WIDTH (f);
  size_hints.height_inc = FRAME_LINE_HEIGHT (f);

Thanks, martin

Message #17 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 08 Dec 2019 00:58:32 +0800

> Is it a good idea to build with xft _and_ cairo?  And what's bad
> about libotf?

xft+cairo is just an artefact from my past experiments with build
options.
libotf is disabled by default in gentoo (as a dependence of m17lib
support, which is also disabled).

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  > The attached patch is the minimal patch making the rendering issue
>  > disappear.
>
> Thank you.
>
>  > Also, I cannot reproduce the issue when I try to configure
>  > emacs just with ./configure --with-x-toolkit=lucid. The options I used
>  > to compile emacs in my OS (I am using gentoo) are
>  >
>  > ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>  > --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
>  > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
>  > --localstatedir=/var/lib --disable-silent-rules
>  > --docdir=/usr/share/doc/emacs-vcs-27.0.9999
>  > --htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
>  > --program-suffix=-emacs-27-vcs --includedir=/usr/include/emacs-27-vcs
>  > --infodir=/usr/share/info/emacs-27-vcs --localstatedir=/var
>  > --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
>  > --without-compress-install --without-hesiod --without-pop
>  > --with-dumping=pdumper --with-file-notification=inotify --enable-acl
>  > --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
>  > --without-json --without-kerberos --without-kerberos5 --with-lcms2
>  > --with-xml2 --without-mailutils --without-selinux --with-gnutls
>  > --without-libsystemd --with-threads --without-wide-int --with-zlib
>  > --with-sound=alsa --with-x --without-ns --without-gconf
>  > --without-gsettings --without-toolkit-scroll-bars --with-gif --with-jpeg
>  > --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick
>  > --with-xft --with-cairo --without-harfbuzz --without-libotf
>
> Is it a good idea to build with xft _and_ cairo?  And what's bad
> about libotf?
>
>  > --without-m17n-flt --with-x-toolkit=lucid --with-xaw3d
>
> -  ew->core.width = (frame_resize_pixelwise
> -		    ? FRAME_PIXEL_WIDTH (f)
> -		    : pixel_width);
> -  ew->core.height = (frame_resize_pixelwise
> -		     ? FRAME_PIXEL_HEIGHT (f)
> -		     : pixel_height);
> +  ew->core.width = (pixel_width);
> +  ew->core.height = (pixel_height);
>
> Maybe a conversion problem.  Does
>
>    ew->core.width = (frame_resize_pixelwise
> 		    ? (Dimension) FRAME_PIXEL_WIDTH (f)
> 		    : pixel_width);
>    ew->core.height = (frame_resize_pixelwise
> 		     ? (Dimension) FRAME_PIXEL_HEIGHT (f)
> 		     : pixel_height);
>
> yield better results?  If not, can you tell me the four values here
> when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
> FRAME_PIXEL_HEIGHT (f) and pixel_height.
>
> This one
>
> -		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
> -		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
> +		 XtNwidthInc, (XtArgVal) (cw),
> +		 XtNheightInc, (XtArgVal) (ch),
>
> is more mysterious.  Why should 1 fail here?  What happens when you do
>
>    cw = frame_resize_pixelwise ? 1 : cw;
>    ch = frame_resize_pixelwise ? 1 : ch;
>    XtVaSetValues (wmshell,
> 		 XtNbaseWidth, (XtArgVal) base_width,
> 		 XtNbaseHeight, (XtArgVal) base_height,
> 		 XtNwidthInc, (XtArgVal) cw,
> 		 XtNheightInc, (XtArgVal) ch,
> 		 XtNminWidth, (XtArgVal) base_width,
> 		 XtNminHeight, (XtArgVal) base_height,
> 		 NULL);
>
> instead?
>
> martin

Message #20 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 07 Dec 2019 21:35:19 +0800

[Message part 1 (text/plain, inline)]

> ... Couldy you try in
> widget.c and xterm.c to selectively make frame_resize_pixelwise have
> no effect, so we could possibly locate the direct source of the
> problem?  

The attached patch is the minimal patch making the rendering issue
disappear. Also, I cannot reproduce the issue when I try to configure
emacs just with ./configure --with-x-toolkit=lucid. The options I used
to compile emacs in my OS (I am using gentoo) are

./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable-silent-rules
--docdir=/usr/share/doc/emacs-vcs-27.0.9999
--htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
--program-suffix=-emacs-27-vcs --includedir=/usr/include/emacs-27-vcs
--infodir=/usr/share/info/emacs-27-vcs --localstatedir=/var
--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
--without-compress-install --without-hesiod --without-pop
--with-dumping=pdumper --with-file-notification=inotify --enable-acl
--with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
--without-json --without-kerberos --without-kerberos5 --with-lcms2
--with-xml2 --without-mailutils --without-selinux --with-gnutls
--without-libsystemd --with-threads --without-wide-int --with-zlib
--with-sound=alsa --with-x --without-ns --without-gconf
--without-gsettings --without-toolkit-scroll-bars --with-gif --with-jpeg
--with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick
--with-xft --with-cairo --without-harfbuzz --without-libotf
--without-m17n-flt --with-x-toolkit=lucid --with-xaw3d 

Regards,
Ihor

[widget-ignore-pixelwise-3.patch (text/x-diff, inline)]

diff --git a/src/widget.c b/src/widget.c
index e8eaf0fadf..f92baa2cef 100644
--- a/src/widget.c
+++ b/src/widget.c
@@ -268,12 +268,8 @@ set_frame_size (EmacsFrame ew)
   if (! XtIsSubclass (wmshell, shellWidgetClass)) emacs_abort ();
 
   char_to_pixel_size (ew, w, h, &pixel_width, &pixel_height);
-  ew->core.width = (frame_resize_pixelwise
-		    ? FRAME_PIXEL_WIDTH (f)
-		    : pixel_width);
-  ew->core.height = (frame_resize_pixelwise
-		     ? FRAME_PIXEL_HEIGHT (f)
-		     : pixel_height);
+  ew->core.width = (pixel_width);
+  ew->core.height = (pixel_height);
 
   frame_size_history_add
     (f, Qset_frame_size, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
@@ -315,8 +311,8 @@ update_wm_hints (EmacsFrame ew)
   XtVaSetValues (wmshell,
 		 XtNbaseWidth, (XtArgVal) base_width,
 		 XtNbaseHeight, (XtArgVal) base_height,
-		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
-		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
+		 XtNwidthInc, (XtArgVal) (cw),
+		 XtNheightInc, (XtArgVal) (ch),
 		 XtNminWidth, (XtArgVal) base_width,
 		 XtNminHeight, (XtArgVal) base_height,
 		 NULL);

[Message part 3 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>  > Oh. I meant maximised, not full screen. Initially, I observed the issue
>  > with maximised emacs frames. (My title bar is located at the bottom of
>  > the frame, not on top).
>
> I see it, now.  The following is a bit tedious: Couldy you try in
> widget.c and xterm.c to selectively make frame_resize_pixelwise have
> no effect, so we could possibly locate the direct source of the
> problem?  There are four instances of this, three in widget.c and one
> in xterm.c.  For example, for the latter, you would have to change the
> two lines
>
>    size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
>    size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
>
> in x_wm_set_size_hint in xterm.c to
>
>    size_hints.width_inc = FRAME_COLUMN_WIDTH (f);
>    size_hints.height_inc = FRAME_LINE_HEIGHT (f);
>
> Thanks, martin

Message #23 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 08 Dec 2019 12:41:21 +0800

[Message part 1 (text/plain, inline)]

> Maybe a conversion problem.  Does
>
>    ew->core.width = (frame_resize_pixelwise
> 		    ? (Dimension) FRAME_PIXEL_WIDTH (f)
> 		    : pixel_width);
>    ew->core.height = (frame_resize_pixelwise
> 		     ? (Dimension) FRAME_PIXEL_HEIGHT (f)
> 		     : pixel_height);
>
> yield better results?

It makes no difference.

> ... If not, can you tell me the four values here
> when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
> FRAME_PIXEL_HEIGHT (f) and pixel_height.

Not sure how to get those.
Anyway, the problem does not seem to be related to the code above.

> This one
>
> -		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
> -		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
> +		 XtNwidthInc, (XtArgVal) (cw),
> +		 XtNheightInc, (XtArgVal) (ch),
>
> is more mysterious.  Why should 1 fail here?  What happens when you do
>
>    cw = frame_resize_pixelwise ? 1 : cw;
>    ch = frame_resize_pixelwise ? 1 : ch;
>    XtVaSetValues (wmshell,
> 		 XtNbaseWidth, (XtArgVal) base_width,
> 		 XtNbaseHeight, (XtArgVal) base_height,
> 		 XtNwidthInc, (XtArgVal) cw,
> 		 XtNheightInc, (XtArgVal) ch,
> 		 XtNminWidth, (XtArgVal) base_width,
> 		 XtNminHeight, (XtArgVal) base_height,
> 		 NULL);
>
> instead?

Actually, this piece of code seems to be a more specific reason
triggering the bug (see the relevant patch attached - that patch makes
the bug disappear). 

I tried your suggestion (no idea how it is different from original code
though). It makes no difference.

A possible hint to why this code fails to resize the frame is that my
WM resizes the frame as soon as it is created. It is not a gradual
resizing with mouse, but rather instant resize to pre-calculated size
(according to layout). I can sometimes even see the frame being created
with much smaller size for a split second followed by resizing it to
target size.

Best,
Ihor

[widget-ignore-pixelwise-6.patch (text/x-diff, inline)]

diff --git a/src/widget.c b/src/widget.c
index e8eaf0fadf..4c00e35333 100644
--- a/src/widget.c
+++ b/src/widget.c
@@ -315,8 +315,8 @@ update_wm_hints (EmacsFrame ew)
   XtVaSetValues (wmshell,
 		 XtNbaseWidth, (XtArgVal) base_width,
 		 XtNbaseHeight, (XtArgVal) base_height,
-		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
-		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
+		 XtNwidthInc, (XtArgVal) (cw),
+		 XtNheightInc, (XtArgVal) (ch),
 		 XtNminWidth, (XtArgVal) base_width,
 		 XtNminHeight, (XtArgVal) base_height,
 		 NULL);

[Message part 3 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>  > The attached patch is the minimal patch making the rendering issue
>  > disappear.
>
> Thank you.
>
>  > Also, I cannot reproduce the issue when I try to configure
>  > emacs just with ./configure --with-x-toolkit=lucid. The options I used
>  > to compile emacs in my OS (I am using gentoo) are
>  >
>  > ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>  > --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
>  > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
>  > --localstatedir=/var/lib --disable-silent-rules
>  > --docdir=/usr/share/doc/emacs-vcs-27.0.9999
>  > --htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
>  > --program-suffix=-emacs-27-vcs --includedir=/usr/include/emacs-27-vcs
>  > --infodir=/usr/share/info/emacs-27-vcs --localstatedir=/var
>  > --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
>  > --without-compress-install --without-hesiod --without-pop
>  > --with-dumping=pdumper --with-file-notification=inotify --enable-acl
>  > --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
>  > --without-json --without-kerberos --without-kerberos5 --with-lcms2
>  > --with-xml2 --without-mailutils --without-selinux --with-gnutls
>  > --without-libsystemd --with-threads --without-wide-int --with-zlib
>  > --with-sound=alsa --with-x --without-ns --without-gconf
>  > --without-gsettings --without-toolkit-scroll-bars --with-gif --with-jpeg
>  > --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick
>  > --with-xft --with-cairo --without-harfbuzz --without-libotf
>
> Is it a good idea to build with xft _and_ cairo?  And what's bad
> about libotf?
>
>  > --without-m17n-flt --with-x-toolkit=lucid --with-xaw3d
>
> -  ew->core.width = (frame_resize_pixelwise
> -		    ? FRAME_PIXEL_WIDTH (f)
> -		    : pixel_width);
> -  ew->core.height = (frame_resize_pixelwise
> -		     ? FRAME_PIXEL_HEIGHT (f)
> -		     : pixel_height);
> +  ew->core.width = (pixel_width);
> +  ew->core.height = (pixel_height);
>
> Maybe a conversion problem.  Does
>
>    ew->core.width = (frame_resize_pixelwise
> 		    ? (Dimension) FRAME_PIXEL_WIDTH (f)
> 		    : pixel_width);
>    ew->core.height = (frame_resize_pixelwise
> 		     ? (Dimension) FRAME_PIXEL_HEIGHT (f)
> 		     : pixel_height);
>
> yield better results?  If not, can you tell me the four values here
> when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
> FRAME_PIXEL_HEIGHT (f) and pixel_height.
>
> This one
>
> -		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
> -		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
> +		 XtNwidthInc, (XtArgVal) (cw),
> +		 XtNheightInc, (XtArgVal) (ch),
>
> is more mysterious.  Why should 1 fail here?  What happens when you do
>
>    cw = frame_resize_pixelwise ? 1 : cw;
>    ch = frame_resize_pixelwise ? 1 : ch;
>    XtVaSetValues (wmshell,
> 		 XtNbaseWidth, (XtArgVal) base_width,
> 		 XtNbaseHeight, (XtArgVal) base_height,
> 		 XtNwidthInc, (XtArgVal) cw,
> 		 XtNheightInc, (XtArgVal) ch,
> 		 XtNminWidth, (XtArgVal) base_width,
> 		 XtNminHeight, (XtArgVal) base_height,
> 		 NULL);
>
> instead?
>
> martin

Message #26 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 7 Dec 2019 17:29:57 +0100

> The attached patch is the minimal patch making the rendering issue
> disappear.

Thank you.

> Also, I cannot reproduce the issue when I try to configure
> emacs just with ./configure --with-x-toolkit=lucid. The options I used
> to compile emacs in my OS (I am using gentoo) are
>
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
> --localstatedir=/var/lib --disable-silent-rules
> --docdir=/usr/share/doc/emacs-vcs-27.0.9999
> --htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
> --program-suffix=-emacs-27-vcs --includedir=/usr/include/emacs-27-vcs
> --infodir=/usr/share/info/emacs-27-vcs --localstatedir=/var
> --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
> --without-compress-install --without-hesiod --without-pop
> --with-dumping=pdumper --with-file-notification=inotify --enable-acl
> --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
> --without-json --without-kerberos --without-kerberos5 --with-lcms2
> --with-xml2 --without-mailutils --without-selinux --with-gnutls
> --without-libsystemd --with-threads --without-wide-int --with-zlib
> --with-sound=alsa --with-x --without-ns --without-gconf
> --without-gsettings --without-toolkit-scroll-bars --with-gif --with-jpeg
> --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick
> --with-xft --with-cairo --without-harfbuzz --without-libotf

Is it a good idea to build with xft _and_ cairo?  And what's bad
about libotf?

> --without-m17n-flt --with-x-toolkit=lucid --with-xaw3d

-  ew->core.width = (frame_resize_pixelwise
-		    ? FRAME_PIXEL_WIDTH (f)
-		    : pixel_width);
-  ew->core.height = (frame_resize_pixelwise
-		     ? FRAME_PIXEL_HEIGHT (f)
-		     : pixel_height);
+  ew->core.width = (pixel_width);
+  ew->core.height = (pixel_height);

Maybe a conversion problem.  Does

  ew->core.width = (frame_resize_pixelwise
		    ? (Dimension) FRAME_PIXEL_WIDTH (f)
		    : pixel_width);
  ew->core.height = (frame_resize_pixelwise
		     ? (Dimension) FRAME_PIXEL_HEIGHT (f)
		     : pixel_height);

yield better results?  If not, can you tell me the four values here
when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
FRAME_PIXEL_HEIGHT (f) and pixel_height.

This one

-		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
-		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
+		 XtNwidthInc, (XtArgVal) (cw),
+		 XtNheightInc, (XtArgVal) (ch),

is more mysterious.  Why should 1 fail here?  What happens when you do

  cw = frame_resize_pixelwise ? 1 : cw;
  ch = frame_resize_pixelwise ? 1 : ch;
  XtVaSetValues (wmshell,
		 XtNbaseWidth, (XtArgVal) base_width,
		 XtNbaseHeight, (XtArgVal) base_height,
		 XtNwidthInc, (XtArgVal) cw,
		 XtNheightInc, (XtArgVal) ch,
		 XtNminWidth, (XtArgVal) base_width,
		 XtNminHeight, (XtArgVal) base_height,
		 NULL);

instead?

martin

Message #29 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 8 Dec 2019 09:57:01 +0100

>> Is it a good idea to build with xft _and_ cairo?  And what's bad
>> about libotf?
>
> xft+cairo is just an artefact from my past experiments with build
> options.
> libotf is disabled by default in gentoo (as a dependence of m17lib
> support, which is also disabled).

Then could you please try to bisect your build options so we can find out
which one is responsible?

martin

Message #32 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 8 Dec 2019 09:57:51 +0100

>> ... If not, can you tell me the four values here
>> when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
>> FRAME_PIXEL_HEIGHT (f) and pixel_height.
>
> Not sure how to get those.

By running Emacs under the debugger and putting a breakpoint at that
position.  But let's put that aside for the moment since, as you say,
this part is not the real cause of the problem anyway.

> Actually, this piece of code seems to be a more specific reason
> triggering the bug (see the relevant patch attached - that patch makes
> the bug disappear).

Unfortunately, that patch breaks pixelwise resizing.  The frame could
then be resized only in character size increments, defeating the entire
original purpose of 'frame-resize-pixelwise'.

> I tried your suggestion (no idea how it is different from original code
> though). It makes no difference.

I would have been surprised if it did.

> A possible hint to why this code fails to resize the frame is that my
> WM resizes the frame as soon as it is created. It is not a gradual
> resizing with mouse, but rather instant resize to pre-calculated size
> (according to layout). I can sometimes even see the frame being created
> with much smaller size for a split second followed by resizing it to
> target size.

How do you create such a frame in the first place?

martin

Message #35 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 08 Dec 2019 17:21:22 +0800

> How do you create such a frame in the first place?

Originally, I observed the issue with my org-capture frame (I am using
org-capture-pop-frame package) when it was called in a tile window
layout. In my machine Meta-c is simply bound to

bash -c 'emacsclient -e "(org-capture)"'

The default emacs frame is just around a quarter of screen size (as it
appears in floating window layout) and I can sometimes see it appearing 
for a split second in a tile layout before being resized.

Also, as I showed in emacs -Q recipe, failure to redraw the frame
can also be triggered in a maximised or a full screen emacs frame. The
frame is also being resized there, though it is much less noticeable
(just closing small gap below the maximised frame). 

> Unfortunately, that patch breaks pixelwise resizing.  The frame could
> then be resized only in character size increments, defeating the entire
> original purpose of 'frame-resize-pixelwise'.

Sure. Just wanted to document the minimal change required to make the
bug disappear. 

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  >> ... If not, can you tell me the four values here
>  >> when it fails to redraw - that of FRAME_PIXEL_WIDTH (f), pixel_width,
>  >> FRAME_PIXEL_HEIGHT (f) and pixel_height.
>  >
>  > Not sure how to get those.
>
> By running Emacs under the debugger and putting a breakpoint at that
> position.  But let's put that aside for the moment since, as you say,
> this part is not the real cause of the problem anyway.
>
>  > Actually, this piece of code seems to be a more specific reason
>  > triggering the bug (see the relevant patch attached - that patch makes
>  > the bug disappear).
>
> Unfortunately, that patch breaks pixelwise resizing.  The frame could
> then be resized only in character size increments, defeating the entire
> original purpose of 'frame-resize-pixelwise'.
>
>  > I tried your suggestion (no idea how it is different from original code
>  > though). It makes no difference.
>
> I would have been surprised if it did.
>
>  > A possible hint to why this code fails to resize the frame is that my
>  > WM resizes the frame as soon as it is created. It is not a gradual
>  > resizing with mouse, but rather instant resize to pre-calculated size
>  > (according to layout). I can sometimes even see the frame being created
>  > with much smaller size for a split second followed by resizing it to
>  > target size.
>
> How do you create such a frame in the first place?
>
> martin

Message #38 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 08 Dec 2019 17:24:15 +0800

> Then could you please try to bisect your build options so we can find out
> which one is responsible?

Will try to do that. Though it will take a while since I use the Gentoo
package manager to tweak the build options for now (which means that
every compilation is being done from scratch).

I will send an update once I finish.

Regards,
Ihor


martin rudalics <rudalics <at> gmx.at> writes:

>  >> Is it a good idea to build with xft _and_ cairo?  And what's bad
>  >> about libotf?
>  >
>  > xft+cairo is just an artefact from my past experiments with build
>  > options.
>  > libotf is disabled by default in gentoo (as a dependence of m17lib
>  > support, which is also disabled).
>
> Then could you please try to bisect your build options so we can find out
> which one is responsible?
>
> martin

Message #41 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 9 Dec 2019 10:19:49 +0100

> The default emacs frame is just around a quarter of screen size (as it
> appears in floating window layout) and I can sometimes see it appearing
> for a split second in a tile layout before being resized.

Having a tiled layout, do you need to set 'frame-resize-pixelwise' to
t at all?  I thought a tiling WM would ignore size hints anyway.

> Also, as I showed in emacs -Q recipe, failure to redraw the frame
> can also be triggered in a maximised or a full screen emacs frame. The
> frame is also being resized there, though it is much less noticeable
> (just closing small gap below the maximised frame).

This seems typical of applying a frame character size based
maximization first and a pixelwise maximization afterwards.  Does it
fully maximize immediately when you build Emacs with the default
configuration or do you see such an intermediate frame size too?

martin

Message #44 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 9 Dec 2019 10:20:05 +0100

> Will try to do that. Though it will take a while since I use the Gentoo
> package manager to tweak the build options for now (which means that
> every compilation is being done from scratch).

Can't you build Emacs from Git master in some separate directory?
Compiling the Lisp files anew takes half an hour here, compiling C
requires a few minutes.

> I will send an update once I finish.

Thanks, martin

Message #47 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 09 Dec 2019 17:55:16 +0800

> Having a tiled layout, do you need to set 'frame-resize-pixelwise' to
> t at all?  I thought a tiling WM would ignore size hints anyway.

In my WM (Awesome WM), I always see a small gap below the maximised emacs
frame. The gap disappears when I set 'frame-resize-pixelwise' to 't.

> This seems typical of applying a frame character size based
> maximization first and a pixelwise maximization afterwards.  Does it
> fully maximize immediately when you build Emacs with the default
> configuration or do you see such an intermediate frame size too?

The intermediate frame size seems to be the way Awesome WM handles newly
created windows. First, the window is being created without respecting
the tiling layout. Then, the window seems to be resized according to
layout.

Best,
Ihor


martin rudalics <rudalics <at> gmx.at> writes:

>  > The default emacs frame is just around a quarter of screen size (as it
>  > appears in floating window layout) and I can sometimes see it appearing
>  > for a split second in a tile layout before being resized.
>
> Having a tiled layout, do you need to set 'frame-resize-pixelwise' to
> t at all?  I thought a tiling WM would ignore size hints anyway.
>
>  > Also, as I showed in emacs -Q recipe, failure to redraw the frame
>  > can also be triggered in a maximised or a full screen emacs frame. The
>  > frame is also being resized there, though it is much less noticeable
>  > (just closing small gap below the maximised frame).
>
> This seems typical of applying a frame character size based
> maximization first and a pixelwise maximization afterwards.  Does it
> fully maximize immediately when you build Emacs with the default
> configuration or do you see such an intermediate frame size too?
>
> martin

Message #50 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 9 Dec 2019 16:59:23 +0100

> In my WM (Awesome WM), I always see a small gap below the maximised emacs
> frame. The gap disappears when I set 'frame-resize-pixelwise' to 't.

Yes.  That was one of the major reasons for implementing pixelwise
frame resizing.

> The intermediate frame size seems to be the way Awesome WM handles newly
> created windows. First, the window is being created without respecting
> the tiling layout. Then, the window seems to be resized according to
> layout.

Does this also apply to other applications' windows?

martin

Message #53 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 15:03:20 +0800

Done.
The redrawing bug disappears once I disable --with-xft.
I also tried to change the font to "Adobe sans", "Fira Sans", and "Fira
Code". The bug still persists. 

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  >> Is it a good idea to build with xft _and_ cairo?  And what's bad
>  >> about libotf?
>  >
>  > xft+cairo is just an artefact from my past experiments with build
>  > options.
>  > libotf is disabled by default in gentoo (as a dependence of m17lib
>  > support, which is also disabled).
>
> Then could you please try to bisect your build options so we can find out
> which one is responsible?
>
> martin

Message #56 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 15:18:18 +0800

> Can't you build Emacs from Git master in some separate directory?
> Compiling the Lisp files anew takes half an hour here, compiling C
> requires a few minutes.

I cannot compile emacs with ./configure && make locally when I try
enabling the same compile options as for the system compilation. It
seems that there is some problem with library dirs. 

martin rudalics <rudalics <at> gmx.at> writes:

>  > Will try to do that. Though it will take a while since I use the Gentoo
>  > package manager to tweak the build options for now (which means that
>  > every compilation is being done from scratch).
>
> Can't you build Emacs from Git master in some separate directory?
> Compiling the Lisp files anew takes half an hour here, compiling C
> requires a few minutes.
>
>  > I will send an update once I finish.
>
> Thanks, martin

Message #59 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 15:18:36 +0800

> Can't you build Emacs from Git master in some separate directory?
> Compiling the Lisp files anew takes half an hour here, compiling C
> requires a few minutes.

I cannot compile emacs with ./configure && make locally when I try
enabling the same compile options as for the system compilation. It
seems that there is some problem with library path settings. 

martin rudalics <rudalics <at> gmx.at> writes:

>  > Will try to do that. Though it will take a while since I use the Gentoo
>  > package manager to tweak the build options for now (which means that
>  > every compilation is being done from scratch).
>
> Can't you build Emacs from Git master in some separate directory?
> Compiling the Lisp files anew takes half an hour here, compiling C
> requires a few minutes.
>
>  > I will send an update once I finish.
>
> Thanks, martin

Message #62 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 15:19:19 +0800

> Does this also apply to other applications' windows?

Yes, as much as I can tell.

martin rudalics <rudalics <at> gmx.at> writes:

>  > In my WM (Awesome WM), I always see a small gap below the maximised emacs
>  > frame. The gap disappears when I set 'frame-resize-pixelwise' to 't.
>
> Yes.  That was one of the major reasons for implementing pixelwise
> frame resizing.
>
>  > The intermediate frame size seems to be the way Awesome WM handles newly
>  > created windows. First, the window is being created without respecting
>  > the tiling layout. Then, the window seems to be resized according to
>  > layout.
>
> Does this also apply to other applications' windows?
>
> martin

Message #65 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 10:35:48 +0100

> The redrawing bug disappears once I disable --with-xft.
> I also tried to change the font to "Adobe sans", "Fira Sans", and "Fira
> Code". The bug still persists.

Does the bug appear when you build with xft and _without_ cairo?
Alternatively, what is a minimal recipe to make it appear with Lucid
and xft?

Something cheaper to test: Does the bug also appear when you disable
tool bars, menu bars or scroll bars?  Silly shots in the dark when we
have an apparently font related bug.  But I have absolutely no clue
why Lucid builds should behave so differently in this regard.

martin

Message #68 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 19:42:01 +0800

> Does the bug appear when you build with xft and _without_ cairo?

The bug disappears then.

Though Gentoo default build turns on cairo if xft is enabled and cairo
is not explicitly disabled.
A comment from ebuild:
USE flag \"cairo\" has no effect if \"xft\" is not set.


> Alternatively, what is a minimal recipe to make it appear with Lucid
> and xft?

The minimal recipe is what I posted in the first email. (Actually, can
be even smaller. See below)

> Something cheaper to test: Does the bug also appear when you disable
> tool bars, menu bars or scroll bars?

No. It disappears. Specifically, it disappears when I disable menu-bar.
Actually, there is no redrawing when I simply do
1. emacs -Q
2. maximise frame
3. M-x menu-bar-mode

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  > The redrawing bug disappears once I disable --with-xft.
>  > I also tried to change the font to "Adobe sans", "Fira Sans", and "Fira
>  > Code". The bug still persists.
>
> Does the bug appear when you build with xft and _without_ cairo?
> Alternatively, what is a minimal recipe to make it appear with Lucid
> and xft?
>
> Something cheaper to test: Does the bug also appear when you disable
> tool bars, menu bars or scroll bars?  Silly shots in the dark when we
> have an apparently font related bug.  But I have absolutely no clue
> why Lucid builds should behave so differently in this regard.
>
> martin

Message #71 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Fri, 13 Dec 2019 16:57:21 +0100

>> Something cheaper to test: Does the bug also appear when you disable
>> tool bars, menu bars or scroll bars?
>
> No. It disappears. Specifically, it disappears when I disable menu-bar.
> Actually, there is no redrawing when I simply do
> 1. emacs -Q
> 2. maximise frame
> 3. M-x menu-bar-mode

I'm confused.  What does "there is no redrawing" mean?  That the rest
of the frame is orderly redrawn or that the rest of the frame is not
redrawn?

If drawing the Lucid menu bar _is_ responsible for the problem, could
you try setting its font separately?  See appendix

D.3 Lucid Menu And Dialog X Resources

of the Emacs manual for what can be specified (you can use the -xrm
option to put these into effect when invoking Emacs).

martin

Message #74 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 00:46:38 +0800

[Message part 1 (text/plain, inline)]

> I'm confused.  What does "there is no redrawing" mean?  That the rest
> of the frame is orderly redrawn or that the rest of the frame is not
> redrawn?

I mean literally. Emacs frame does not redraw properly. I tried make
several window splits after M-x menu-bar-mode. See the attached
screenshot.

I don't even need to change fonts or load emacs theme to trigger this.

> If drawing the Lucid menu bar _is_ responsible for the problem, could
> you try setting its font separately?  See appendix

I tried to run emacs with

emacs -Q -xrm 1.txt

with 1.txt:
Emacs.pane.menubar.font: Courier-12

The result is same.

Best,
Ihor

[noredraw.jpg (image/jpeg, attachment)]

[Message part 3 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>  >> Something cheaper to test: Does the bug also appear when you disable
>  >> tool bars, menu bars or scroll bars?
>  >
>  > No. It disappears. Specifically, it disappears when I disable menu-bar.
>  > Actually, there is no redrawing when I simply do
>  > 1. emacs -Q
>  > 2. maximise frame
>  > 3. M-x menu-bar-mode
>
> I'm confused.  What does "there is no redrawing" mean?  That the rest
> of the frame is orderly redrawn or that the rest of the frame is not
> redrawn?
>
> If drawing the Lucid menu bar _is_ responsible for the problem, could
> you try setting its font separately?  See appendix
>
> D.3 Lucid Menu And Dialog X Resources
>
> of the Emacs manual for what can be specified (you can use the -xrm
> option to put these into effect when invoking Emacs).
>
> martin

Message #77 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 10:06:14 +0100

> I mean literally. Emacs frame does not redraw properly. I tried make
> several window splits after M-x menu-bar-mode. See the attached
> screenshot.
>
> I don't even need to change fonts or load emacs theme to trigger this.

OK.  So we have a simpler scenario now.  From the screenshot I cannot
understand where redrawing hangs.  Is input still functional in such a
mangled frame?  Does evaluating (redisplay t) change anything?

Two additional things you could try: What happens when you use 0
instead of 1 in the XtNwidthInc and XtNheightInc assignments like

		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),

And what happens when you skip these two assignments entirely when
frame_resize_pixelwise is non-nil?

martin

Message #80 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 17:38:38 +0800

> OK.  So we have a simpler scenario now.  From the screenshot I cannot
> understand where redrawing hangs.  Is input still functional in such a
> mangled frame?  Does evaluating (redisplay t) change anything?

The input is functional. I can split windows with C-x 2/3. The frame is
partially redrawn (just the scroll bars, as in the screenshot).
Blindly running (redisplay t) does nothing.

> Two additional things you could try: What happens when you use 0
> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>
> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>
> And what happens when you skip these two assignments entirely when
> frame_resize_pixelwise is non-nil?

Let me try and report back once I finish.

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  > I mean literally. Emacs frame does not redraw properly. I tried make
>  > several window splits after M-x menu-bar-mode. See the attached
>  > screenshot.
>  >
>  > I don't even need to change fonts or load emacs theme to trigger this.
>
> OK.  So we have a simpler scenario now.  From the screenshot I cannot
> understand where redrawing hangs.  Is input still functional in such a
> mangled frame?  Does evaluating (redisplay t) change anything?
>
> Two additional things you could try: What happens when you use 0
> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>
> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>
> And what happens when you skip these two assignments entirely when
> frame_resize_pixelwise is non-nil?
>
> martin

Message #83 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 17:39:35 +0800

> OK.  So we have a simpler scenario now.  From the screenshot I cannot
> understand where redrawing hangs.  Is input still functional in such a
> mangled frame?  Does evaluating (redisplay t) change anything?

The input is functional. I can split windows with C-x 2/3. The frame is
partially redrawn (just the scroll bars, as in the screenshot).
Blindly running (redisplay t) does nothing.

> Two additional things you could try: What happens when you use 0
> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>
> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>
> And what happens when you skip these two assignments entirely when
> frame_resize_pixelwise is non-nil?

Let me try and report back once I finish.

Best,
Ihor

martin rudalics <rudalics <at> gmx.at> writes:

>  > I mean literally. Emacs frame does not redraw properly. I tried make
>  > several window splits after M-x menu-bar-mode. See the attached
>  > screenshot.
>  >
>  > I don't even need to change fonts or load emacs theme to trigger this.
>
> OK.  So we have a simpler scenario now.  From the screenshot I cannot
> understand where redrawing hangs.  Is input still functional in such a
> mangled frame?  Does evaluating (redisplay t) change anything?
>
> Two additional things you could try: What happens when you use 0
> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>
> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>
> And what happens when you skip these two assignments entirely when
> frame_resize_pixelwise is non-nil?
>
> martin

Message #86 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 18:16:28 +0800

>> Two additional things you could try: What happens when you use 0
>> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>>
>> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
>> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>>
>> And what happens when you skip these two assignments entirely when
>> frame_resize_pixelwise is non-nil?
>
> Let me try and report back once I finish.

I tried both. I do not see any difference. Still no redrawing.

Best,
Ihor


Ihor Radchenko <yantar92 <at> gmail.com> writes:

>> OK.  So we have a simpler scenario now.  From the screenshot I cannot
>> understand where redrawing hangs.  Is input still functional in such a
>> mangled frame?  Does evaluating (redisplay t) change anything?
>
> The input is functional. I can split windows with C-x 2/3. The frame is
> partially redrawn (just the scroll bars, as in the screenshot).
> Blindly running (redisplay t) does nothing.
>
>> Two additional things you could try: What happens when you use 0
>> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>>
>> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
>> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>>
>> And what happens when you skip these two assignments entirely when
>> frame_resize_pixelwise is non-nil?
>
> Let me try and report back once I finish.
>
> Best,
> Ihor
>
> martin rudalics <rudalics <at> gmx.at> writes:
>
>>  > I mean literally. Emacs frame does not redraw properly. I tried make
>>  > several window splits after M-x menu-bar-mode. See the attached
>>  > screenshot.
>>  >
>>  > I don't even need to change fonts or load emacs theme to trigger this.
>>
>> OK.  So we have a simpler scenario now.  From the screenshot I cannot
>> understand where redrawing hangs.  Is input still functional in such a
>> mangled frame?  Does evaluating (redisplay t) change anything?
>>
>> Two additional things you could try: What happens when you use 0
>> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>>
>> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
>> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>>
>> And what happens when you skip these two assignments entirely when
>> frame_resize_pixelwise is non-nil?
>>
>> martin
>

Message #89 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50;
 Frame is not rendered when frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 13:40:14 +0200

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Date: Sat, 14 Dec 2019 17:38:38 +0800
> 
> > OK.  So we have a simpler scenario now.  From the screenshot I cannot
> > understand where redrawing hangs.  Is input still functional in such a
> > mangled frame?  Does evaluating (redisplay t) change anything?
> 
> The input is functional. I can split windows with C-x 2/3. The frame is
> partially redrawn (just the scroll bars, as in the screenshot).
> Blindly running (redisplay t) does nothing.

How about "M-x redraw-display RET" -- does that redraw the frame?

Message #92 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 20:22:11 +0800

> How about "M-x redraw-display RET" -- does that redraw the frame?

Nope.

I only managed to trigger the real redraw (not just the scroll bars) by
toggling the maximised state of the frame. Once I unmaximise the frame
the frame text and cursor are redrawn. Re-maximised is redrawn normally
even if I try to toggle menu-bar-mode multiple times again.


Best,
Ihor


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Date: Sat, 14 Dec 2019 17:38:38 +0800
>> 
>> > OK.  So we have a simpler scenario now.  From the screenshot I cannot
>> > understand where redrawing hangs.  Is input still functional in such a
>> > mangled frame?  Does evaluating (redisplay t) change anything?
>> 
>> The input is functional. I can split windows with C-x 2/3. The frame is
>> partially redrawn (just the scroll bars, as in the screenshot).
>> Blindly running (redisplay t) does nothing.
>
> How about "M-x redraw-display RET" -- does that redraw the frame?

Message #95 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 14:24:16 +0100

>>> Two additional things you could try: What happens when you use 0
>>> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>>>
>>> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
>>> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>>>
>>> And what happens when you skip these two assignments entirely when
>>> frame_resize_pixelwise is non-nil?
>>
>> Let me try and report back once I finish.
>
> I tried both. I do not see any difference. Still no redrawing.

We are probably missing something all too obvious (for example, why
scroll bars are apparently redrawn orderly).

You say yours is a tiling window manager: What happens when you manage
to remove all windows but the Emacs window from display?  This should
implicitly maximise the frame.  Does it redraw then?

And what happens when you remove the entire

  XtVaSetValues (wmshell,
		 XtNbaseWidth, (XtArgVal) base_width,
		 XtNbaseHeight, (XtArgVal) base_height,
		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
		 XtNminWidth, (XtArgVal) base_width,
		 XtNminHeight, (XtArgVal) base_height,
		 NULL);

call?

martin

Message #98 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sat, 14 Dec 2019 15:36:43 +0200

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
> Date: Sat, 14 Dec 2019 20:22:11 +0800
> 
> > How about "M-x redraw-display RET" -- does that redraw the frame?
> 
> Nope.

That's unheard of.  Does redraw-display at least blank the entire
frame?

Message #101 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 15 Dec 2019 21:43:34 +0800

> That's unheard of.  Does redraw-display at least blank the entire
> frame?

Nope. I don't see anything changing. 


Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
>> Date: Sat, 14 Dec 2019 20:22:11 +0800
>> 
>> > How about "M-x redraw-display RET" -- does that redraw the frame?
>> 
>> Nope.
>
> That's unheard of.  Does redraw-display at least blank the entire
> frame?

Message #104 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 15 Dec 2019 21:57:24 +0800

[Message part 1 (text/plain, inline)]

> You say yours is a tiling window manager: What happens when you manage
> to remove all windows but the Emacs window from display?  This should
> implicitly maximise the frame.  Does it redraw then?

If I do this, there is a gap below the emacs frame.
Invoking M-x menu-bar-mode resizes the frame to actual maximised state
without the gap and the redrawing works. However, the very bottom part
of the frame (that's where by title bar is located) is not being
redrawn. It's like all the frame canvas before resizing is shifted up as
much as the height of the menu-bar was without redrawing whatever was
below that size (see the attached).

> And what happens when you remove the entire
>
>    XtVaSetValues (wmshell,
> 		 XtNbaseWidth, (XtArgVal) base_width,
> 		 XtNbaseHeight, (XtArgVal) base_height,
> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
> 		 XtNminWidth, (XtArgVal) base_width,
> 		 XtNminHeight, (XtArgVal) base_height,
> 		 NULL);
>
> call?

When I remove the call, there is still no redrawing. Moreover, without
maximising the frame, when emacs frame is a single frame in a tile
layout, the frame occupies all the space as if frame-resize-pixelwise
was nil and M-x menu-bar-mode results in no redrawing.

Best,
Ihor

[shift.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>  >>> Two additional things you could try: What happens when you use 0
>  >>> instead of 1 in the XtNwidthInc and XtNheightInc assignments like
>  >>>
>  >>> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 0 : cw),
>  >>> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 0 : ch),
>  >>>
>  >>> And what happens when you skip these two assignments entirely when
>  >>> frame_resize_pixelwise is non-nil?
>  >>
>  >> Let me try and report back once I finish.
>  >
>  > I tried both. I do not see any difference. Still no redrawing.
>
> We are probably missing something all too obvious (for example, why
> scroll bars are apparently redrawn orderly).
>
> You say yours is a tiling window manager: What happens when you manage
> to remove all windows but the Emacs window from display?  This should
> implicitly maximise the frame.  Does it redraw then?
>
> And what happens when you remove the entire
>
>    XtVaSetValues (wmshell,
> 		 XtNbaseWidth, (XtArgVal) base_width,
> 		 XtNbaseHeight, (XtArgVal) base_height,
> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
> 		 XtNminWidth, (XtArgVal) base_width,
> 		 XtNminHeight, (XtArgVal) base_height,
> 		 NULL);
>
> call?
>
> martin

Message #107 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 15 Dec 2019 17:21:41 +0200

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
> Date: Sun, 15 Dec 2019 21:43:34 +0800
> 
> > That's unheard of.  Does redraw-display at least blank the entire
> > frame?
> 
> Nope. I don't see anything changing. 

That's impossible.  When you invoke redraw-display, Emacs on X calls
the function x_clear_frame, which calls x_clear_window, which calls
XClearWindow.  Do you see this sequence of calls if you step through
the code with a derbugger?

One possible reason for not clearing the frame is that you have
double-buffering enabled.  Can you disable it and try again?  (If you
don't know how, search for "double buffering" in etc/NEWS.26.)

Failing that, the only way I can explain this is that you have some
"optimization" feature in your video hardware and/or driver, and that
is the cause of all the problems you report in this thread.  Please
review the settings of your video driver software, and turn off any
"optimization" or "advanced" feature you find there.  If that doesn't
help, maybe upgrading to a newer version of the video driver will
help.

Message #110 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Sun, 15 Dec 2019 18:42:39 +0100

>> You say yours is a tiling window manager: What happens when you manage
>> to remove all windows but the Emacs window from display?  This should
>> implicitly maximise the frame.  Does it redraw then?
>
> If I do this, there is a gap below the emacs frame.

With 'frame-resize-pixelwise' non-nil?

> Invoking M-x menu-bar-mode resizes the frame to actual maximised state
> without the gap and the redrawing works.

Why should removing the menu bar maximize the frame?  If anything, I'd
expect the opposite.

> However, the very bottom part
> of the frame (that's where by title bar is located) is not being
> redrawn. It's like all the frame canvas before resizing is shifted up as
> much as the height of the menu-bar was without redrawing whatever was
> below that size (see the attached).

The title bar there looks normal to me, not doubled.  And how would
you know in the first place that the title bar was not redrawn?

>> And what happens when you remove the entire
>>
>>     XtVaSetValues (wmshell,
>> 		 XtNbaseWidth, (XtArgVal) base_width,
>> 		 XtNbaseHeight, (XtArgVal) base_height,
>> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
>> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
>> 		 XtNminWidth, (XtArgVal) base_width,
>> 		 XtNminHeight, (XtArgVal) base_height,
>> 		 NULL);
>>
>> call?
>
> When I remove the call, there is still no redrawing. Moreover, without
> maximising the frame, when emacs frame is a single frame in a tile
> layout, the frame occupies all the space as if frame-resize-pixelwise
> was nil

This must be a misunderstanding.  Among others, it's one purpose of
'frame-resize-pixelwise' _non-nil_ to make the frame occupy all the
space.

> and M-x menu-bar-mode results in no redrawing.

martin

Message #113 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 10:29:56 +0800

[Message part 1 (text/plain, inline)]

> With 'frame-resize-pixelwise' non-nil?

No, frame-resize-pixelwise had its default value (nil).

To avoid confusion, let me recall what I did to reproduce the redrawing issue:

1. Compile emacs with xft cairo and lucid
2. emacs -Q (frame-resize-pixelwise is nil by default)
3. Maximise emacs frame (without this, there is an artefact in the title
   bar, but emacs frame itself is redrawing)
4. M-x menu-bar-mode

> Why should removing the menu bar maximize the frame?  If anything, I'd
> expect the opposite.

I tested several more times. It's not really maximising, but the frame
size definitely changes (sometimes increases, sometimes decreases).
See the attached illustration.

> The title bar there looks normal to me, not doubled.  And how would
> you know in the first place that the title bar was not redrawn?

See the illustration.

>  >> And what happens when you remove the entire
>  >>
>  >>     XtVaSetValues (wmshell,
>  >> 		 XtNbaseWidth, (XtArgVal) base_width,
>  >> 		 XtNbaseHeight, (XtArgVal) base_height,
>  >> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
>  >> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
>  >> 		 XtNminWidth, (XtArgVal) base_width,
>  >> 		 XtNminHeight, (XtArgVal) base_height,
>  >> 		 NULL);
>  >>
>  >> call?
>  >
>  > When I remove the call, there is still no redrawing. Moreover, without
>  > maximising the frame, when emacs frame is a single frame in a tile
>  > layout, the frame occupies all the space as if frame-resize-pixelwise
>  > was nil
> This must be a misunderstanding.  Among others, it's one purpose of
> 'frame-resize-pixelwise' _non-nil_ to make the frame occupy all the
> space.

Note that in all the tests in that message I had frame-resize-pixelwise
nil. The frame occupied all the space in that scenario because I removed
the code responsible for setting the calculated frame size. 

Best,
Ihor

[redrawing.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>  >> You say yours is a tiling window manager: What happens when you manage
>  >> to remove all windows but the Emacs window from display?  This should
>  >> implicitly maximise the frame.  Does it redraw then?
>  >
>  > If I do this, there is a gap below the emacs frame.
>
> With 'frame-resize-pixelwise' non-nil?
>
>  > Invoking M-x menu-bar-mode resizes the frame to actual maximised state
>  > without the gap and the redrawing works.
>
> Why should removing the menu bar maximize the frame?  If anything, I'd
> expect the opposite.
>
>  > However, the very bottom part
>  > of the frame (that's where by title bar is located) is not being
>  > redrawn. It's like all the frame canvas before resizing is shifted up as
>  > much as the height of the menu-bar was without redrawing whatever was
>  > below that size (see the attached).
>
> The title bar there looks normal to me, not doubled.  And how would
> you know in the first place that the title bar was not redrawn?
>
>  >> And what happens when you remove the entire
>  >>
>  >>     XtVaSetValues (wmshell,
>  >> 		 XtNbaseWidth, (XtArgVal) base_width,
>  >> 		 XtNbaseHeight, (XtArgVal) base_height,
>  >> 		 XtNwidthInc, (XtArgVal) (frame_resize_pixelwise ? 1 : cw),
>  >> 		 XtNheightInc, (XtArgVal) (frame_resize_pixelwise ? 1 : ch),
>  >> 		 XtNminWidth, (XtArgVal) base_width,
>  >> 		 XtNminHeight, (XtArgVal) base_height,
>  >> 		 NULL);
>  >>
>  >> call?
>  >
>  > When I remove the call, there is still no redrawing. Moreover, without
>  > maximising the frame, when emacs frame is a single frame in a tile
>  > layout, the frame occupies all the space as if frame-resize-pixelwise
>  > was nil
>
> This must be a misunderstanding.  Among others, it's one purpose of
> 'frame-resize-pixelwise' _non-nil_ to make the frame occupy all the
> space.
>
>  > and M-x menu-bar-mode results in no redrawing.
>
> martin

Message #116 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 11:10:41 +0800

> One possible reason for not clearing the frame is that you have
> double-buffering enabled.  Can you disable it and try again?  (If you
> don't know how, search for "double buffering" in etc/NEWS.26.)

I tried to disable double buffering.
Running emacs -Q --eval "(add-to-list 'default-frame-alist
'(inhibit-double-buffering . t))", the redrawing works without any
issues.

Now, I am wondering if the issue I reported is just specific to my
system or others can also reproduce it with emacs compiled with xft,
cairo, and lucid enabled. If so, would it make sense to disable double
buffering by default for this combination of build options?

Best,
Ihor

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> gmail.com>
>> Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
>> Date: Sun, 15 Dec 2019 21:43:34 +0800
>> 
>> > That's unheard of.  Does redraw-display at least blank the entire
>> > frame?
>> 
>> Nope. I don't see anything changing. 
>
> That's impossible.  When you invoke redraw-display, Emacs on X calls
> the function x_clear_frame, which calls x_clear_window, which calls
> XClearWindow.  Do you see this sequence of calls if you step through
> the code with a derbugger?
>
> One possible reason for not clearing the frame is that you have
> double-buffering enabled.  Can you disable it and try again?  (If you
> don't know how, search for "double buffering" in etc/NEWS.26.)
>
> Failing that, the only way I can explain this is that you have some
> "optimization" feature in your video hardware and/or driver, and that
> is the cause of all the problems you report in this thread.  Please
> review the settings of your video driver software, and turn off any
> "optimization" or "advanced" feature you find there.  If that doesn't
> help, maybe upgrading to a newer version of the video driver will
> help.

Message #119 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 05:33:40 +0200

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: rudalics <at> gmx.at, 38497 <at> debbugs.gnu.org
> Date: Mon, 16 Dec 2019 11:10:41 +0800
> 
> > One possible reason for not clearing the frame is that you have
> > double-buffering enabled.  Can you disable it and try again?  (If you
> > don't know how, search for "double buffering" in etc/NEWS.26.)
> 
> I tried to disable double buffering.
> Running emacs -Q --eval "(add-to-list 'default-frame-alist
> '(inhibit-double-buffering . t))", the redrawing works without any
> issues.

Thanks, that probably explains everything discussed in this bug
report.

> Now, I am wondering if the issue I reported is just specific to my
> system or others can also reproduce it with emacs compiled with xft,
> cairo, and lucid enabled. If so, would it make sense to disable double
> buffering by default for this combination of build options?

I don't know.  There are a few open bugs regarding double buffering
which await debugging.

Can someone please try reproducing Ihor's problem by building Emacs
with the same options?  TIA.

Message #122 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ihor Radchenko <yantar92 <at> gmail.com>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 10:14:46 +0100

> I tested several more times. It's not really maximising, but the frame
> size definitely changes (sometimes increases, sometimes decreases).
> See the attached illustration.
>
>> The title bar there looks normal to me, not doubled.  And how would
>> you know in the first place that the title bar was not redrawn?
>
> See the illustration.

These caps are much better, many thanks.  Maybe they can serve to
identify future problems with the double buffering issue (which IIUC
is at the core of the problems you describe).

>>   > When I remove the call, there is still no redrawing. Moreover, without
>>   > maximising the frame, when emacs frame is a single frame in a tile
>>   > layout, the frame occupies all the space as if frame-resize-pixelwise
>>   > was nil
>>
>> This must be a misunderstanding.  Among others, it's one purpose of
>> 'frame-resize-pixelwise' _non-nil_ to make the frame occupy all the
>> space.
>
> Note that in all the tests in that message I had frame-resize-pixelwise
> nil. The frame occupied all the space in that scenario because I removed
> the code responsible for setting the calculated frame size.

I was only bothered by "the frame occupies all the space as if
frame-resize-pixelwise was nil" which is misleading because
`frame-resize-pixelwise' nil implies the frame need not occupy all
space when the workarea size is not a multiple of the base character
size.

martin

Message #125 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: mituharu <at> math.s.chiba-u.ac.jp
To: "Ihor Radchenko" <yantar92 <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 19:53:37 +0900

>> With 'frame-resize-pixelwise' non-nil?
>
> No, frame-resize-pixelwise had its default value (nil).
>
> To avoid confusion, let me recall what I did to reproduce the redrawing
> issue:
>
> 1. Compile emacs with xft cairo and lucid
> 2. emacs -Q (frame-resize-pixelwise is nil by default)
> 3. Maximise emacs frame (without this, there is an artefact in the title
>    bar, but emacs frame itself is redrawing)
> 4. M-x menu-bar-mode

Could you try the patch below?

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/xterm.c b/src/xterm.c
index 55e5cb76f2..3d6f59c48c 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8931,8 +8931,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
         font_drop_xrender_surfaces (f);
       unblock_input ();
 #if defined USE_CAIRO && !defined USE_GTK
-      if (f)
-	x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width,
+      if (any && configureEvent.xconfigure.window == FRAME_X_WINDOW (any))
+	x_cr_update_surface_desired_size (any,
+					  configureEvent.xconfigure.width,
 					  configureEvent.xconfigure.height);
 #endif
 #ifdef USE_GTK

Message #128 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: mituharu <at> math.s.chiba-u.ac.jp
Cc: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 21:04:15 +0800

> Could you try the patch below?

Redrawing started working with this patch. Thank you!

Best regards,
Ihor


mituharu <at> math.s.chiba-u.ac.jp writes:

>>> With 'frame-resize-pixelwise' non-nil?
>>
>> No, frame-resize-pixelwise had its default value (nil).
>>
>> To avoid confusion, let me recall what I did to reproduce the redrawing
>> issue:
>>
>> 1. Compile emacs with xft cairo and lucid
>> 2. emacs -Q (frame-resize-pixelwise is nil by default)
>> 3. Maximise emacs frame (without this, there is an artefact in the title
>>    bar, but emacs frame itself is redrawing)
>> 4. M-x menu-bar-mode
>
> Could you try the patch below?
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 55e5cb76f2..3d6f59c48c 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -8931,8 +8931,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>          font_drop_xrender_surfaces (f);
>        unblock_input ();
>  #if defined USE_CAIRO && !defined USE_GTK
> -      if (f)
> -	x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width,
> +      if (any && configureEvent.xconfigure.window == FRAME_X_WINDOW (any))
> +	x_cr_update_surface_desired_size (any,
> +					  configureEvent.xconfigure.width,
>  					  configureEvent.xconfigure.height);
>  #endif
>  #ifdef USE_GTK
>
>

Message #131 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38497 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#38497: 27.0.50;
 Frame is not rendered when frame-resize-pixelwise it 't
Date: Mon, 16 Dec 2019 17:36:23 +0200

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Date: Mon, 16 Dec 2019 21:04:15 +0800
> Cc: 38497 <at> debbugs.gnu.org
> 
> > Could you try the patch below?
> 
> Redrawing started working with this patch. Thank you!

It would be interesting to see whether this change also fixes some of
the other bugs which reportedly disappear when double-buffering is
disabled.

Message #134 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: mituharu <at> math.s.chiba-u.ac.jp
Cc: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Tue, 17 Dec 2019 08:39:28 +0800

>> Could you try the patch below?

Even though redrawing started working with the patch following my
previous recipe, I observe another redrawing issue with this patch. I
haven't tracked the exact recipe yet, but it seems to occur when emacs
frame is created in floating layout (maybe because it is not resized
after creation in this case, unlike tiling layout).

Ihor Radchenko <yantar92 <at> gmail.com> writes:

>> Could you try the patch below?
>
> Redrawing started working with this patch. Thank you!
>
> Best regards,
> Ihor
>
>
> mituharu <at> math.s.chiba-u.ac.jp writes:
>
>>>> With 'frame-resize-pixelwise' non-nil?
>>>
>>> No, frame-resize-pixelwise had its default value (nil).
>>>
>>> To avoid confusion, let me recall what I did to reproduce the redrawing
>>> issue:
>>>
>>> 1. Compile emacs with xft cairo and lucid
>>> 2. emacs -Q (frame-resize-pixelwise is nil by default)
>>> 3. Maximise emacs frame (without this, there is an artefact in the title
>>>    bar, but emacs frame itself is redrawing)
>>> 4. M-x menu-bar-mode
>>
>> Could you try the patch below?
>>
>> 				     YAMAMOTO Mitsuharu
>> 				mituharu <at> math.s.chiba-u.ac.jp
>>
>> diff --git a/src/xterm.c b/src/xterm.c
>> index 55e5cb76f2..3d6f59c48c 100644
>> --- a/src/xterm.c
>> +++ b/src/xterm.c
>> @@ -8931,8 +8931,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>>          font_drop_xrender_surfaces (f);
>>        unblock_input ();
>>  #if defined USE_CAIRO && !defined USE_GTK
>> -      if (f)
>> -	x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width,
>> +      if (any && configureEvent.xconfigure.window == FRAME_X_WINDOW (any))
>> +	x_cr_update_surface_desired_size (any,
>> +					  configureEvent.xconfigure.width,
>>  					  configureEvent.xconfigure.height);
>>  #endif
>>  #ifdef USE_GTK
>>
>>
>

Message #137 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50;
 Frame is not rendered when frame-resize-pixelwise it 't
Date: Tue, 17 Dec 2019 15:50:37 +0900

On Tue, 17 Dec 2019 09:39:28 +0900,
Ihor Radchenko wrote:
> 
> >> Could you try the patch below?
> 
> Even though redrawing started working with the patch following my
> previous recipe, I observe another redrawing issue with this patch. I
> haven't tracked the exact recipe yet, but it seems to occur when emacs
> frame is created in floating layout (maybe because it is not resized
> after creation in this case, unlike tiling layout).

Does the patch below work?  (I'm no X11 expert, so just shooting at random.)

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/xterm.c b/src/xterm.c
index 55e5cb76f2..590b4bda97 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8934,6 +8934,10 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       if (f)
 	x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width,
 					  configureEvent.xconfigure.height);
+      else if (any && configureEvent.xconfigure.window == FRAME_X_WINDOW (any))
+	x_cr_update_surface_desired_size (any,
+					  configureEvent.xconfigure.width,
+					  configureEvent.xconfigure.height);
 #endif
 #ifdef USE_GTK
       if (!f

Message #140 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: martin rudalics <rudalics <at> gmx.at>, 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Tue, 17 Dec 2019 18:37:52 +0800

> Does the patch below work?  (I'm no X11 expert, so just shooting at random.)

It seems to work. Though I was not able to reproduce this new problem with
emacs -Q. Will keep testing with my config for a while more to make sure
that the problem is gone. 

Best,
Ihor

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

> On Tue, 17 Dec 2019 09:39:28 +0900,
> Ihor Radchenko wrote:
>> 
>> >> Could you try the patch below?
>> 
>> Even though redrawing started working with the patch following my
>> previous recipe, I observe another redrawing issue with this patch. I
>> haven't tracked the exact recipe yet, but it seems to occur when emacs
>> frame is created in floating layout (maybe because it is not resized
>> after creation in this case, unlike tiling layout).
>
> Does the patch below work?  (I'm no X11 expert, so just shooting at random.)
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 55e5cb76f2..590b4bda97 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -8934,6 +8934,10 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>        if (f)
>  	x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width,
>  					  configureEvent.xconfigure.height);
> +      else if (any && configureEvent.xconfigure.window == FRAME_X_WINDOW (any))
> +	x_cr_update_surface_desired_size (any,
> +					  configureEvent.xconfigure.width,
> +					  configureEvent.xconfigure.height);
>  #endif
>  #ifdef USE_GTK
>        if (!f

Message #143 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50;
 Frame is not rendered when frame-resize-pixelwise it 't
Date: Mon, 06 Jan 2020 18:19:22 +0900

On Tue, 17 Dec 2019 19:37:52 +0900,
Ihor Radchenko wrote:
> 
> > Does the patch below work?  (I'm no X11 expert, so just shooting at random.)
> 
> It seems to work. Though I was not able to reproduce this new problem with
> emacs -Q. Will keep testing with my config for a while more to make sure
> that the problem is gone. 

If you've not found any regressions with my latest patch so far, I'll
install it to the emacs-27 branch.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #146 received at 38497 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 38497 <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50; Frame is not rendered when
 frame-resize-pixelwise it 't
Date: Mon, 06 Jan 2020 18:57:40 +0800

> If you've not found any regressions with my latest patch so far, I'll
> install it to the emacs-27 branch.

I haven't seen any obvious regression with your patch. 

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

> On Tue, 17 Dec 2019 19:37:52 +0900,
> Ihor Radchenko wrote:
>> 
>> > Does the patch below work?  (I'm no X11 expert, so just shooting at random.)
>> 
>> It seems to work. Though I was not able to reproduce this new problem with
>> emacs -Q. Will keep testing with my config for a while more to make sure
>> that the problem is gone. 
>
> If you've not found any regressions with my latest patch so far, I'll
> install it to the emacs-27 branch.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92 <at> gmail.com, ihor_radchenko <at> alumni.sutd.edu.sg

Message #151 received at 38497-done <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 38497-done <at> debbugs.gnu.org
Subject: Re: bug#38497: 27.0.50;
 Frame is not rendered when frame-resize-pixelwise it 't
Date: Tue, 07 Jan 2020 12:52:55 +0900

On Mon, 06 Jan 2020 19:57:40 +0900,
Ihor Radchenko wrote:
> 
> > If you've not found any regressions with my latest patch so far, I'll
> > install it to the emacs-27 branch.
> 
> I haven't seen any obvious regression with your patch. 

Thanks.  I've installed the patch to the emacs-27 branch.
Closing the bug.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.