Package: emacs;
Reported by: Bjoern Bidar <bjorn.bidar <at> thaodan.de>
Date: Thu, 4 Aug 2022 07:38:01 UTC
Severity: normal
Found in version 29.0.50
To reply to this bug, email your comments to 56967 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Thu, 04 Aug 2022 07:38:02 GMT) Full text and rfc822 format available.Bjoern Bidar <bjorn.bidar <at> thaodan.de>:bug-gnu-emacs <at> gnu.org.
(Thu, 04 Aug 2022 07:38:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: bug-gnu-emacs <at> gnu.org Subject: 29.0.50; Frequent crashes under Wayland Date: Thu, 04 Aug 2022 10:36:50 +0300
To trigger the bug there needs to be some usage so I'm not sure how to trigger the bug with ~emacs -Q~. However Emacs just stops usually, sometimes emacs freezes for a few sec before. I start emacs as a systemd --user service, systemd reports that emacs stops like this: emacs.service: Main process exited, code=exited, status=1/FAILURE No other output or crashdump is there. It happens after a time, sometimes it fails after hours sometimes it fails after 10 minues. In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-08-03 built on 224768 Repository revision: 21afc26d4df6bae35ba032d4b6b03fb7fb2bf1b3 Repository branch: master System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-modules --with-libotf --without-gconf --with-libsystemd --enable-link-time-optimization --with-native-compilation --with-xinput2 --with-pgtk --without-xaw3d --with-sound=alsa --without-gpm '--program-transform-name=s/\([ec]tags\)/\1.emacs/' 'CFLAGS=-march=x86-64 -mtune=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto' 'CXXFLAGS=-march=x86-64 -mtune=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -flto=auto'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM GTK3 ZLIB Important settings: value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8-unix Major mode: Circe Server Minor modes in effect: guess-language-mode: t cursor-intangible-mode: t which-key-mode: t beacon-mode: t savehist-mode: t global-git-commit-mode: t magit-auto-revert-mode: t tracking-mode: t flyspell-mode: t global-edit-server-edit-mode: t desktop-save-mode: t global-so-long-mode: t change-cursor-mode: t recentf-mode: t helm-mode: t helm-minibuffer-history-mode: t helm-autoresize-mode: t helm--remap-mouse-mode: t async-bytecomp-package-mode: t mode-icons-mode: t global-emojify-mode: t emojify-mode: t electric-pair-mode: t editorconfig-mode: t projectile-mode: t shell-dirtrack-mode: t flycheck-color-mode-line-mode: t global-flycheck-mode: t flycheck-mode: t override-global-mode: t global-company-mode: t company-mode: t save-place-mode: t gcmh-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete hides / home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete /home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete-pkg hides /home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete-pkg /home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete-config hides /home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete- config /home/bidar/.emacs.d/elpa/auto-complete-20211231.1808/auto-complete-autoloads hides /home/bidar/.emacs.d/elpa/auto-complete-20220105.439/auto-complete- autoloads /home/bidar/.emacs.d/elpa/avy-20201226.1734/avy hides /home/bidar/.emacs.d/ elpa/avy-20220102.805/avy /home/bidar/.emacs.d/elpa/avy-20201226.1734/avy-pkg hides /home/ bidar/.emacs.d/elpa/avy-20220102.805/avy-pkg /home/bidar/.emacs.d/elpa/avy-20201226.1734/avy-autoloads hides /home/ bidar/.emacs.d/elpa/avy-20220102.805/avy-autoloads /home/bidar/.emacs.d/elpa/cfrs-20211013.1802/cfrs hides /home/bidar/.emacs.d/ elpa/cfrs-20220129.1149/cfrs /home/bidar/.emacs.d/elpa/cfrs-20211013.1802/cfrs-pkg hides /home/ bidar/.emacs.d/elpa/cfrs-20220129.1149/cfrs-pkg /home/bidar/.emacs.d/elpa/cfrs-20211013.1802/cfrs-autoloads hides /home/ bidar/.emacs.d/elpa/cfrs-20220129.1149/cfrs-autoloads /home/bidar/.emacs.d/elpa/cmake-font-lock-20210103.1558/cmake-font-lock hides /home/bidar/.emacs.d/elpa/cmake-font-lock-20211224.2006/cmake-font-lock /home/bidar/.emacs.d/elpa/cmake-font-lock-20210103.1558/cmake-font-lock-pkg hides /home/bidar/.emacs.d/elpa/cmake-font-lock-20211224.2006/cmake-font-lock- pkg /home/bidar/.emacs.d/elpa/cmake-font-lock-20210103.1558/cmake-font-lock- autoloads hides /home/bidar/.emacs.d/elpa/cmake-font-lock-20211224.2006/cmake- font-lock-autoloads /home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra hides /home/ bidar/.emacs.d/elpa/hydra-20220102.803/hydra /home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-pkg hides /home/ bidar/.emacs.d/elpa/hydra-20220102.803/hydra-pkg /home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-ox hides /home/ bidar/.emacs.d/elpa/hydra-20220102.803/hydra-ox /home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-examples hides /home/ bidar/.emacs.d/elpa/hydra-20220102.803/hydra-examples /home/bidar/.emacs.d/elpa/hydra-20201115.1055/hydra-autoloads hides /home/ bidar/.emacs.d/elpa/hydra-20220102.803/hydra-autoloads /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-snippet hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-snippet /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-pkg hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-pkg /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-iotask hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-iotask /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-diagnostics hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-diagnostics /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-completion hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-completion /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-libclang hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb-libclang /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-json hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb-json /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-clang-complete hides / home/bidar/.emacs.d/elpa/irony-20220110.849/irony-cdb-clang-complete /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-autoloads hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/irony-autoloads ~/.emacs.d/lisp/ox-koma-letter hides /home/bidar/.emacs.d/elpa/org-9.5.4/ox- koma-letter ~/.emacs.d/lisp/ox-groff hides /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox- groff /home/bidar/.emacs.d/elpa/org-9.5.4/ox hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ox /home/bidar/.emacs.d/elpa/org-9.5.4/ox-texinfo hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ox-texinfo /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-taskjuggler hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-taskjuggler /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-s5 hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ox-s5 /home/bidar/.emacs.d/elpa/org-9.5.4/ox-publish hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ox-publish /home/bidar/.emacs.d/elpa/org-9.5.4/ox-org hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-org /home/bidar/.emacs.d/elpa/org-9.5.4/ox-odt hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-odt /home/bidar/.emacs.d/elpa/org-9.5.4/ox-md hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ox-md /home/bidar/.emacs.d/elpa/org-9.5.4/ox-man hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-man /home/bidar/.emacs.d/elpa/org-9.5.4/ox-latex hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-latex ~/.emacs.d/lisp/ox-koma-letter hides /home/bidar/.emacs.d/elpa/org-plus- contrib-20210929/ox-koma-letter /home/bidar/.emacs.d/elpa/org-9.5.4/ox-icalendar hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ox-icalendar /home/bidar/.emacs.d/elpa/org-9.5.4/ox-html hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-html ~/.emacs.d/lisp/ox-groff hides /home/bidar/.emacs.d/elpa/org-plus- contrib-20210929/ox-groff /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-freemind hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-freemind /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-extra hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ox-extra /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-deck hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ox-deck /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-confluence hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-confluence /home/bidar/.emacs.d/elpa/org-contrib-0.4/ox-bibtex hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ox-bibtex /home/bidar/.emacs.d/elpa/org-9.5.4/ox-beamer hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-beamer /home/bidar/.emacs.d/elpa/org-9.5.4/ox-ascii hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ox-ascii /home/bidar/.emacs.d/elpa/org-contrib-0.4/orgtbl-sqlinsert hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/orgtbl-sqlinsert /home/bidar/.emacs.d/elpa/org-9.5.4/org hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/org /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-wikinodes hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-wikinodes /home/bidar/.emacs.d/elpa/org-9.5.4/org-version hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-version /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-track hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-track /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-toc hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-toc /home/bidar/.emacs.d/elpa/org-9.5.4/org-timer hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-timer /home/bidar/.emacs.d/elpa/org-9.5.4/org-tempo hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-tempo /home/bidar/.emacs.d/elpa/org-9.5.4/org-table hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-table /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-sudoku hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-sudoku /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-static-mathjax hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-static-mathjax /home/bidar/.emacs.d/elpa/org-9.5.4/org-src hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-src /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-secretary hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-secretary /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-screenshot hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-screenshot /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-screen hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-screen /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-registry hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-registry /home/bidar/.emacs.d/elpa/org-9.5.4/org-refile hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-refile /home/bidar/.emacs.d/elpa/org-9.5.4/org-protocol hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-protocol /home/bidar/.emacs.d/elpa/org-9.5.4/org-plot hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-plot /home/bidar/.emacs.d/elpa/org-9.5.4/org-pcomplete hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-pcomplete /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-panel hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-panel /home/bidar/.emacs.d/elpa/org-9.5.4/org-num hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-num /home/bidar/.emacs.d/elpa/org-9.5.4/org-mouse hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-mouse /home/bidar/.emacs.d/elpa/org-9.5.4/org-mobile hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-mobile /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-mairix hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-mairix /home/bidar/.emacs.d/elpa/org-9.5.4/org-macs hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-macs /home/bidar/.emacs.d/elpa/org-9.5.4/org-macro hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-macro /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-mac-iCal hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-mac-iCal /home/bidar/.emacs.d/elpa/org-9.5.4/org-loaddefs hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-loaddefs /home/bidar/.emacs.d/elpa/org-9.5.4/org-list hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-list /home/bidar/.emacs.d/elpa/org-9.5.4/org-lint hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-lint /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-license hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-license /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-learn hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-learn /home/bidar/.emacs.d/elpa/org-9.5.4/org-keys hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-keys /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-invoice hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-invoice /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-interactive-query hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-interactive-query /home/bidar/.emacs.d/elpa/org-9.5.4/org-inlinetask hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-inlinetask /home/bidar/.emacs.d/elpa/org-9.5.4/org-indent hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-indent /home/bidar/.emacs.d/elpa/org-9.5.4/org-id hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-id /home/bidar/.emacs.d/elpa/org-9.5.4/org-habit hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-habit /home/bidar/.emacs.d/elpa/org-9.5.4/org-goto hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-goto /home/bidar/.emacs.d/elpa/org-9.5.4/org-footnote hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-footnote /home/bidar/.emacs.d/elpa/org-9.5.4/org-feed hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-feed /home/bidar/.emacs.d/elpa/org-9.5.4/org-faces hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-faces /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-expiry hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-expiry /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-eval hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-eval /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-eval-light hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-eval-light /home/bidar/.emacs.d/elpa/org-9.5.4/org-entities hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-entities /home/bidar/.emacs.d/elpa/org-9.5.4/org-element hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-element /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-eldoc hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-eldoc /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-effectiveness hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-effectiveness /home/bidar/.emacs.d/elpa/org-9.5.4/org-duration hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-duration /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-depend hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-depend /home/bidar/.emacs.d/elpa/org-9.5.4/org-datetree hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-datetree /home/bidar/.emacs.d/elpa/org-9.5.4/org-ctags hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-ctags /home/bidar/.emacs.d/elpa/org-9.5.4/org-crypt hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-crypt /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-contribdir hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-contribdir /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-contrib hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-contrib /home/bidar/.emacs.d/elpa/org-9.5.4/org-compat hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-compat /home/bidar/.emacs.d/elpa/org-9.5.4/org-colview hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-colview /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-collector hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-collector /home/bidar/.emacs.d/elpa/org-9.5.4/org-clock hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/org-clock /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-choose hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-choose /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-checklist hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-checklist /home/bidar/.emacs.d/elpa/org-9.5.4/org-capture hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-capture /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-bibtex-extras hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-bibtex-extras /home/bidar/.emacs.d/elpa/org-9.5.4/org-attach hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-attach /home/bidar/.emacs.d/elpa/org-9.5.4/org-attach-git hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-attach-git /home/bidar/.emacs.d/elpa/org-9.5.4/org-archive hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-archive /home/bidar/.emacs.d/elpa/org-contrib-0.4/org-annotate-file hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-annotate-file /home/bidar/.emacs.d/elpa/org-9.5.4/org-agenda hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/org-agenda /home/bidar/.emacs.d/elpa/org-9.5.4/ol hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ol /home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-wl hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ol-wl /home/bidar/.emacs.d/elpa/org-9.5.4/ol-w3m hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-w3m /home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-vm hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ol-vm /home/bidar/.emacs.d/elpa/org-9.5.4/ol-rmail hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-rmail /home/bidar/.emacs.d/elpa/org-9.5.4/ol-mhe hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-mhe /home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-mew hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ol-mew /home/bidar/.emacs.d/elpa/org-9.5.4/ol-man hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-man /home/bidar/.emacs.d/elpa/org-9.5.4/ol-irc hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-irc /home/bidar/.emacs.d/elpa/org-9.5.4/ol-info hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-info /home/bidar/.emacs.d/elpa/org-9.5.4/ol-gnus hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-gnus /home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-git-link hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ol-git-link /home/bidar/.emacs.d/elpa/org-9.5.4/ol-eww hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-eww /home/bidar/.emacs.d/elpa/org-9.5.4/ol-eshell hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-eshell /home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-elisp-symbol hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ol-elisp-symbol /home/bidar/.emacs.d/elpa/org-9.5.4/ol-doi hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-doi /home/bidar/.emacs.d/elpa/org-9.5.4/ol-docview hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ol-docview /home/bidar/.emacs.d/elpa/org-contrib-0.4/ol-bookmark hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ol-bookmark /home/bidar/.emacs.d/elpa/org-9.5.4/ol-bibtex hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-bibtex /home/bidar/.emacs.d/elpa/org-9.5.4/ol-bbdb hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ol-bbdb /home/bidar/.emacs.d/elpa/org-9.5.4/oc hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/oc /home/bidar/.emacs.d/elpa/org-9.5.4/oc-natbib hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/oc-natbib /home/bidar/.emacs.d/elpa/org-9.5.4/oc-csl hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/oc-csl /home/bidar/.emacs.d/elpa/org-9.5.4/oc-biblatex hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/oc-biblatex /home/bidar/.emacs.d/elpa/org-9.5.4/oc-basic hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/oc-basic /home/bidar/.emacs.d/elpa/org-9.5.4/ob hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ob /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-vbnet hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-vbnet /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-vala hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-vala /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-tcl hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-tcl /home/bidar/.emacs.d/elpa/org-9.5.4/ob-tangle hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-tangle /home/bidar/.emacs.d/elpa/org-9.5.4/ob-table hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-table /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-stata hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-stata /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sqlite hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-sqlite /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sql hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-sql /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-spice hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-spice /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-shen hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-shen /home/bidar/.emacs.d/elpa/org-9.5.4/ob-shell hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-shell /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sed hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-sed /home/bidar/.emacs.d/elpa/org-9.5.4/ob-screen hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-screen /home/bidar/.emacs.d/elpa/org-9.5.4/ob-scheme hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-scheme /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sass hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-sass /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ruby hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-ruby /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ref hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-ref /home/bidar/.emacs.d/elpa/org-9.5.4/ob-python hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-python /home/bidar/.emacs.d/elpa/org-9.5.4/ob-processing hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-processing /home/bidar/.emacs.d/elpa/org-9.5.4/ob-plantuml hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-plantuml /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-picolisp hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-picolisp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-perl hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-perl /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-oz hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-oz /home/bidar/.emacs.d/elpa/org-9.5.4/ob-org hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-org /home/bidar/.emacs.d/elpa/org-9.5.4/ob-octave hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-octave /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ocaml hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-ocaml /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-mscgen hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-mscgen /home/bidar/.emacs.d/elpa/org-9.5.4/ob-maxima hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-maxima /home/bidar/.emacs.d/elpa/org-9.5.4/ob-matlab hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-matlab /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-mathomatic hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-mathomatic /home/bidar/.emacs.d/elpa/org-9.5.4/ob-makefile hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-makefile /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lua hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-lua /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lob hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-lob /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lisp hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-lisp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lilypond hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-lilypond /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-ledger hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-ledger /home/bidar/.emacs.d/elpa/org-9.5.4/ob-latex hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-latex /home/bidar/.emacs.d/elpa/org-9.5.4/ob-julia hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-julia /home/bidar/.emacs.d/elpa/org-9.5.4/ob-js hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ob-js /home/bidar/.emacs.d/elpa/org-9.5.4/ob-java hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-java /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-io hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-io /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-hledger hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-hledger /home/bidar/.emacs.d/elpa/org-9.5.4/ob-haskell hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-haskell /home/bidar/.emacs.d/elpa/org-9.5.4/ob-groovy hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-groovy /home/bidar/.emacs.d/elpa/org-9.5.4/ob-gnuplot hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-gnuplot /home/bidar/.emacs.d/elpa/org-9.5.4/ob-fortran hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-fortran /home/bidar/.emacs.d/elpa/org-9.5.4/ob-forth hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-forth /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-fomus hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-fomus /home/bidar/.emacs.d/elpa/org-9.5.4/ob-exp hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-exp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-eval hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-eval /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-eukleides hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-eukleides /home/bidar/.emacs.d/elpa/org-9.5.4/ob-eshell hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-eshell /home/bidar/.emacs.d/elpa/org-9.5.4/ob-emacs-lisp hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-emacs-lisp /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-ebnf hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-ebnf /home/bidar/.emacs.d/elpa/org-9.5.4/ob-dot hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-dot /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ditaa hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-ditaa /home/bidar/.emacs.d/elpa/org-9.5.4/ob-css hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-css /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-csharp hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-csharp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-core hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-core /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-coq hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-coq /home/bidar/.emacs.d/elpa/org-9.5.4/ob-comint hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-comint /home/bidar/.emacs.d/elpa/org-9.5.4/ob-clojure hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-clojure /home/bidar/.emacs.d/elpa/org-9.5.4/ob-calc hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-calc /home/bidar/.emacs.d/elpa/org-9.5.4/ob-awk hides /home/bidar/.emacs.d/elpa/ org-plus-contrib-20210929/ob-awk /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-asymptote hides /home/ bidar/.emacs.d/elpa/org-plus-contrib-20210929/ob-asymptote /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-abc hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-abc /home/bidar/.emacs.d/elpa/org-9.5.4/ob-R hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ob-R /home/bidar/.emacs.d/elpa/org-contrib-0.4/ob-J hides /home/bidar/.emacs.d/ elpa/org-plus-contrib-20210929/ob-J /home/bidar/.emacs.d/elpa/org-9.5.4/ob-C hides /home/bidar/.emacs.d/elpa/org- plus-contrib-20210929/ob-C /home/bidar/.emacs.d/elpa/org-tree-slide-20211213.1254/org-tree-slide hides / home/bidar/.emacs.d/elpa/org-tree-slide-20220112.142/org-tree-slide /home/bidar/.emacs.d/elpa/org-tree-slide-20211213.1254/org-tree-slide-pkg hides /home/bidar/.emacs.d/elpa/org-tree-slide-20220112.142/org-tree-slide-pkg /home/bidar/.emacs.d/elpa/org-tree-slide-20211213.1254/org-tree-slide- autoloads hides /home/bidar/.emacs.d/elpa/org-tree-slide-20220112.142/org- tree-slide-autoloads /home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture hides /home/ bidar/.emacs.d/elpa/pfuture-20211229.1513/pfuture /home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-pkg hides /home/ bidar/.emacs.d/elpa/pfuture-20211229.1513/pfuture-pkg /home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-autoloads hides /home/ bidar/.emacs.d/elpa/pfuture-20211229.1513/pfuture-autoloads /home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture hides /home/ bidar/.emacs.d/elpa/pfuture-20220425.1242/pfuture /home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-pkg hides /home/ bidar/.emacs.d/elpa/pfuture-20220425.1242/pfuture-pkg /home/bidar/.emacs.d/elpa/pfuture-20200425.1357/pfuture-autoloads hides /home/ bidar/.emacs.d/elpa/pfuture-20220425.1242/pfuture-autoloads /home/bidar/.emacs.d/elpa/popup-20210317.138/popup hides /home/bidar/.emacs.d/ elpa/popup-20210625.400/popup /home/bidar/.emacs.d/elpa/popup-20210317.138/popup-pkg hides /home/ bidar/.emacs.d/elpa/popup-20210625.400/popup-pkg /home/bidar/.emacs.d/elpa/popup-20210317.138/popup-autoloads hides /home/ bidar/.emacs.d/elpa/popup-20210625.400/popup-autoloads /home/bidar/.emacs.d/elpa/popup-20210317.138/popup hides /home/bidar/.emacs.d/ elpa/popup-20211231.1823/popup /home/bidar/.emacs.d/elpa/popup-20210317.138/popup-pkg hides /home/ bidar/.emacs.d/elpa/popup-20211231.1823/popup-pkg /home/bidar/.emacs.d/elpa/popup-20210317.138/popup-autoloads hides /home/ bidar/.emacs.d/elpa/popup-20211231.1823/popup-autoloads /home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline hides /home/ bidar/.emacs.d/elpa/powerline-20220122.1904/powerline /home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-themes hides /home/ bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-themes /home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-separators hides / home/bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-separators /home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-pkg hides /home/ bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-pkg /home/bidar/.emacs.d/elpa/powerline-20211022.655/powerline-autoloads hides / home/bidar/.emacs.d/elpa/powerline-20220122.1904/powerline-autoloads /home/bidar/.emacs.d/elpa/s-20210603.736/s hides /home/bidar/.emacs.d/elpa/ s-20210616.619/s /home/bidar/.emacs.d/elpa/s-20210603.736/s-pkg hides /home/bidar/.emacs.d/ elpa/s-20210616.619/s-pkg /home/bidar/.emacs.d/elpa/s-20210603.736/s-autoloads hides /home/ bidar/.emacs.d/elpa/s-20210616.619/s-autoloads /home/bidar/.emacs.d/elpa/spinner-1.7.3/spinner hides /home/bidar/.emacs.d/ elpa/spinner-1.7.4/spinner /home/bidar/.emacs.d/elpa/spinner-1.7.3/spinner-pkg hides /home/ bidar/.emacs.d/elpa/spinner-1.7.4/spinner-pkg /home/bidar/.emacs.d/elpa/spinner-1.7.3/spinner-autoloads hides /home/ bidar/.emacs.d/elpa/spinner-1.7.4/spinner-autoloads /home/bidar/.emacs.d/elpa/circe-20220526.1206/tracking hides /home/ bidar/.emacs.d/elpa/tracking-20210713.1609/tracking /home/bidar/.emacs.d/elpa/circe-20220526.1206/shorten hides /home/ bidar/.emacs.d/elpa/tracking-20210713.1609/shorten /home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm hides /home/bidar/.emacs.d/elpa/ xpm-1.0.5/xpm /home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm-pkg hides /home/bidar/.emacs.d/elpa/ xpm-1.0.5/xpm-pkg /home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm-m2z hides /home/bidar/.emacs.d/elpa/ xpm-1.0.5/xpm-m2z /home/bidar/.emacs.d/elpa/xpm-1.0.4/xpm-autoloads hides /home/bidar/.emacs.d/ elpa/xpm-1.0.5/xpm-autoloads /home/bidar/.emacs.d/elpa/yaml-mode-20211230.1126/yaml-mode hides /home/ bidar/.emacs.d/elpa/yaml-mode-20220104.1503/yaml-mode /home/bidar/.emacs.d/elpa/yaml-mode-20211230.1126/yaml-mode-pkg hides /home/ bidar/.emacs.d/elpa/yaml-mode-20220104.1503/yaml-mode-pkg /home/bidar/.emacs.d/elpa/yaml-mode-20211230.1126/yaml-mode-autoloads hides / home/bidar/.emacs.d/elpa/yaml-mode-20220104.1503/yaml-mode-autoloads /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony hides /home/ bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/irony /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-iotask hides /home/ bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/irony-iotask /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-json hides /home/ bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/irony-cdb-json /home/bidar/.emacs.d/elpa/irony-20210605.1018/server/test/elisp/test-config hides /home/bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/test- config /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/irony /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-iotask hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-iotask /home/bidar/.emacs.d/elpa/irony-20210605.1018/irony-cdb-json hides /home/ bidar/.emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-cdb-json /home/bidar/.emacs.d/elpa/cmake-mode-20220617.1532/cmake-mode hides /usr/ share/emacs/site-lisp/cmake-mode /home/bidar/.emacs.d/elpa/libgit-20220620.1118/libgit hides /usr/share/emacs/ site-lisp/libgit /home/bidar/.emacs.d/elpa/dash-20220608.1931/dash hides /usr/share/emacs/site- lisp/dash/dash /home/bidar/.emacs.d/elpa/dash-functional-20210210.1449/dash-functional hides /usr/share/emacs/site-lisp/dash/dash-functional /home/bidar/.emacs.d/elpa/transient-20220717.1713/transient hides /usr/share/ emacs/29.0.50/lisp/transient /home/bidar/.emacs.d/elpa/org-9.5.4/ox hides /usr/share/emacs/29.0.50/lisp/ org/ox /home/bidar/.emacs.d/elpa/org-9.5.4/ox-texinfo hides /usr/share/emacs/29.0.50/ lisp/org/ox-texinfo /home/bidar/.emacs.d/elpa/org-9.5.4/ox-publish hides /usr/share/emacs/29.0.50/ lisp/org/ox-publish /home/bidar/.emacs.d/elpa/org-9.5.4/ox-org hides /usr/share/emacs/29.0.50/ lisp/org/ox-org /home/bidar/.emacs.d/elpa/org-9.5.4/ox-odt hides /usr/share/emacs/29.0.50/ lisp/org/ox-odt /home/bidar/.emacs.d/elpa/org-9.5.4/ox-md hides /usr/share/emacs/29.0.50/lisp/ org/ox-md /home/bidar/.emacs.d/elpa/org-9.5.4/ox-man hides /usr/share/emacs/29.0.50/ lisp/org/ox-man /home/bidar/.emacs.d/elpa/org-9.5.4/ox-latex hides /usr/share/emacs/29.0.50/ lisp/org/ox-latex ~/.emacs.d/lisp/ox-koma-letter hides /usr/share/emacs/29.0.50/lisp/org/ox- koma-letter /home/bidar/.emacs.d/elpa/org-9.5.4/ox-icalendar hides /usr/share/emacs/ 29.0.50/lisp/org/ox-icalendar /home/bidar/.emacs.d/elpa/org-9.5.4/ox-html hides /usr/share/emacs/29.0.50/ lisp/org/ox-html /home/bidar/.emacs.d/elpa/org-9.5.4/ox-beamer hides /usr/share/emacs/29.0.50/ lisp/org/ox-beamer /home/bidar/.emacs.d/elpa/org-9.5.4/ox-ascii hides /usr/share/emacs/29.0.50/ lisp/org/ox-ascii /home/bidar/.emacs.d/elpa/org-9.5.4/org hides /usr/share/emacs/29.0.50/lisp/ org/org /home/bidar/.emacs.d/elpa/org-9.5.4/org-version hides /usr/share/emacs/ 29.0.50/lisp/org/org-version /home/bidar/.emacs.d/elpa/org-9.5.4/org-timer hides /usr/share/emacs/29.0.50/ lisp/org/org-timer /home/bidar/.emacs.d/elpa/org-9.5.4/org-tempo hides /usr/share/emacs/29.0.50/ lisp/org/org-tempo /home/bidar/.emacs.d/elpa/org-9.5.4/org-table hides /usr/share/emacs/29.0.50/ lisp/org/org-table /home/bidar/.emacs.d/elpa/org-9.5.4/org-src hides /usr/share/emacs/29.0.50/ lisp/org/org-src /home/bidar/.emacs.d/elpa/org-9.5.4/org-refile hides /usr/share/emacs/29.0.50/ lisp/org/org-refile /home/bidar/.emacs.d/elpa/org-9.5.4/org-protocol hides /usr/share/emacs/ 29.0.50/lisp/org/org-protocol /home/bidar/.emacs.d/elpa/org-9.5.4/org-plot hides /usr/share/emacs/29.0.50/ lisp/org/org-plot /home/bidar/.emacs.d/elpa/org-9.5.4/org-pcomplete hides /usr/share/emacs/ 29.0.50/lisp/org/org-pcomplete /home/bidar/.emacs.d/elpa/org-9.5.4/org-num hides /usr/share/emacs/29.0.50/ lisp/org/org-num /home/bidar/.emacs.d/elpa/org-9.5.4/org-mouse hides /usr/share/emacs/29.0.50/ lisp/org/org-mouse /home/bidar/.emacs.d/elpa/org-9.5.4/org-mobile hides /usr/share/emacs/29.0.50/ lisp/org/org-mobile /home/bidar/.emacs.d/elpa/org-9.5.4/org-macs hides /usr/share/emacs/29.0.50/ lisp/org/org-macs /home/bidar/.emacs.d/elpa/org-9.5.4/org-macro hides /usr/share/emacs/29.0.50/ lisp/org/org-macro /home/bidar/.emacs.d/elpa/org-9.5.4/org-loaddefs hides /usr/share/emacs/ 29.0.50/lisp/org/org-loaddefs /home/bidar/.emacs.d/elpa/org-9.5.4/org-list hides /usr/share/emacs/29.0.50/ lisp/org/org-list /home/bidar/.emacs.d/elpa/org-9.5.4/org-lint hides /usr/share/emacs/29.0.50/ lisp/org/org-lint /home/bidar/.emacs.d/elpa/org-9.5.4/org-keys hides /usr/share/emacs/29.0.50/ lisp/org/org-keys /home/bidar/.emacs.d/elpa/org-plus-contrib-20210929/org-install hides /usr/ share/emacs/29.0.50/lisp/org/org-install /home/bidar/.emacs.d/elpa/org-9.5.4/org-inlinetask hides /usr/share/emacs/ 29.0.50/lisp/org/org-inlinetask /home/bidar/.emacs.d/elpa/org-9.5.4/org-indent hides /usr/share/emacs/29.0.50/ lisp/org/org-indent /home/bidar/.emacs.d/elpa/org-9.5.4/org-id hides /usr/share/emacs/29.0.50/ lisp/org/org-id /home/bidar/.emacs.d/elpa/org-9.5.4/org-habit hides /usr/share/emacs/29.0.50/ lisp/org/org-habit /home/bidar/.emacs.d/elpa/org-9.5.4/org-goto hides /usr/share/emacs/29.0.50/ lisp/org/org-goto /home/bidar/.emacs.d/elpa/org-9.5.4/org-footnote hides /usr/share/emacs/ 29.0.50/lisp/org/org-footnote /home/bidar/.emacs.d/elpa/org-9.5.4/org-feed hides /usr/share/emacs/29.0.50/ lisp/org/org-feed /home/bidar/.emacs.d/elpa/org-9.5.4/org-faces hides /usr/share/emacs/29.0.50/ lisp/org/org-faces /home/bidar/.emacs.d/elpa/org-9.5.4/org-entities hides /usr/share/emacs/ 29.0.50/lisp/org/org-entities /home/bidar/.emacs.d/elpa/org-9.5.4/org-element hides /usr/share/emacs/ 29.0.50/lisp/org/org-element /home/bidar/.emacs.d/elpa/org-9.5.4/org-duration hides /usr/share/emacs/ 29.0.50/lisp/org/org-duration /home/bidar/.emacs.d/elpa/org-9.5.4/org-datetree hides /usr/share/emacs/ 29.0.50/lisp/org/org-datetree /home/bidar/.emacs.d/elpa/org-9.5.4/org-ctags hides /usr/share/emacs/29.0.50/ lisp/org/org-ctags /home/bidar/.emacs.d/elpa/org-9.5.4/org-crypt hides /usr/share/emacs/29.0.50/ lisp/org/org-crypt /home/bidar/.emacs.d/elpa/org-9.5.4/org-compat hides /usr/share/emacs/29.0.50/ lisp/org/org-compat /home/bidar/.emacs.d/elpa/org-9.5.4/org-colview hides /usr/share/emacs/ 29.0.50/lisp/org/org-colview /home/bidar/.emacs.d/elpa/org-9.5.4/org-clock hides /usr/share/emacs/29.0.50/ lisp/org/org-clock /home/bidar/.emacs.d/elpa/org-9.5.4/org-capture hides /usr/share/emacs/ 29.0.50/lisp/org/org-capture /home/bidar/.emacs.d/elpa/org-9.5.4/org-attach hides /usr/share/emacs/29.0.50/ lisp/org/org-attach /home/bidar/.emacs.d/elpa/org-9.5.4/org-attach-git hides /usr/share/emacs/ 29.0.50/lisp/org/org-attach-git /home/bidar/.emacs.d/elpa/org-9.5.4/org-archive hides /usr/share/emacs/ 29.0.50/lisp/org/org-archive /home/bidar/.emacs.d/elpa/org-9.5.4/org-agenda hides /usr/share/emacs/29.0.50/ lisp/org/org-agenda /home/bidar/.emacs.d/elpa/org-9.5.4/ol hides /usr/share/emacs/29.0.50/lisp/ org/ol /home/bidar/.emacs.d/elpa/org-9.5.4/ol-w3m hides /usr/share/emacs/29.0.50/ lisp/org/ol-w3m /home/bidar/.emacs.d/elpa/org-9.5.4/ol-rmail hides /usr/share/emacs/29.0.50/ lisp/org/ol-rmail /home/bidar/.emacs.d/elpa/org-9.5.4/ol-mhe hides /usr/share/emacs/29.0.50/ lisp/org/ol-mhe /home/bidar/.emacs.d/elpa/org-9.5.4/ol-man hides /usr/share/emacs/29.0.50/ lisp/org/ol-man /home/bidar/.emacs.d/elpa/org-9.5.4/ol-irc hides /usr/share/emacs/29.0.50/ lisp/org/ol-irc /home/bidar/.emacs.d/elpa/org-9.5.4/ol-info hides /usr/share/emacs/29.0.50/ lisp/org/ol-info /home/bidar/.emacs.d/elpa/org-9.5.4/ol-gnus hides /usr/share/emacs/29.0.50/ lisp/org/ol-gnus /home/bidar/.emacs.d/elpa/org-9.5.4/ol-eww hides /usr/share/emacs/29.0.50/ lisp/org/ol-eww /home/bidar/.emacs.d/elpa/org-9.5.4/ol-eshell hides /usr/share/emacs/29.0.50/ lisp/org/ol-eshell /home/bidar/.emacs.d/elpa/org-9.5.4/ol-doi hides /usr/share/emacs/29.0.50/ lisp/org/ol-doi /home/bidar/.emacs.d/elpa/org-9.5.4/ol-docview hides /usr/share/emacs/29.0.50/ lisp/org/ol-docview /home/bidar/.emacs.d/elpa/org-9.5.4/ol-bibtex hides /usr/share/emacs/29.0.50/ lisp/org/ol-bibtex /home/bidar/.emacs.d/elpa/org-9.5.4/ol-bbdb hides /usr/share/emacs/29.0.50/ lisp/org/ol-bbdb /home/bidar/.emacs.d/elpa/org-9.5.4/oc hides /usr/share/emacs/29.0.50/lisp/ org/oc /home/bidar/.emacs.d/elpa/org-9.5.4/oc-natbib hides /usr/share/emacs/29.0.50/ lisp/org/oc-natbib /home/bidar/.emacs.d/elpa/org-9.5.4/oc-csl hides /usr/share/emacs/29.0.50/ lisp/org/oc-csl /home/bidar/.emacs.d/elpa/org-9.5.4/oc-biblatex hides /usr/share/emacs/ 29.0.50/lisp/org/oc-biblatex /home/bidar/.emacs.d/elpa/org-9.5.4/oc-basic hides /usr/share/emacs/29.0.50/ lisp/org/oc-basic /home/bidar/.emacs.d/elpa/org-9.5.4/ob hides /usr/share/emacs/29.0.50/lisp/ org/ob /home/bidar/.emacs.d/elpa/org-9.5.4/ob-tangle hides /usr/share/emacs/29.0.50/ lisp/org/ob-tangle /home/bidar/.emacs.d/elpa/org-9.5.4/ob-table hides /usr/share/emacs/29.0.50/ lisp/org/ob-table /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sqlite hides /usr/share/emacs/29.0.50/ lisp/org/ob-sqlite /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sql hides /usr/share/emacs/29.0.50/ lisp/org/ob-sql /home/bidar/.emacs.d/elpa/org-9.5.4/ob-shell hides /usr/share/emacs/29.0.50/ lisp/org/ob-shell /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sed hides /usr/share/emacs/29.0.50/ lisp/org/ob-sed /home/bidar/.emacs.d/elpa/org-9.5.4/ob-screen hides /usr/share/emacs/29.0.50/ lisp/org/ob-screen /home/bidar/.emacs.d/elpa/org-9.5.4/ob-scheme hides /usr/share/emacs/29.0.50/ lisp/org/ob-scheme /home/bidar/.emacs.d/elpa/org-9.5.4/ob-sass hides /usr/share/emacs/29.0.50/ lisp/org/ob-sass /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ruby hides /usr/share/emacs/29.0.50/ lisp/org/ob-ruby /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ref hides /usr/share/emacs/29.0.50/ lisp/org/ob-ref /home/bidar/.emacs.d/elpa/org-9.5.4/ob-python hides /usr/share/emacs/29.0.50/ lisp/org/ob-python /home/bidar/.emacs.d/elpa/org-9.5.4/ob-processing hides /usr/share/emacs/ 29.0.50/lisp/org/ob-processing /home/bidar/.emacs.d/elpa/org-9.5.4/ob-plantuml hides /usr/share/emacs/ 29.0.50/lisp/org/ob-plantuml /home/bidar/.emacs.d/elpa/org-9.5.4/ob-perl hides /usr/share/emacs/29.0.50/ lisp/org/ob-perl /home/bidar/.emacs.d/elpa/org-9.5.4/ob-org hides /usr/share/emacs/29.0.50/ lisp/org/ob-org /home/bidar/.emacs.d/elpa/org-9.5.4/ob-octave hides /usr/share/emacs/29.0.50/ lisp/org/ob-octave /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ocaml hides /usr/share/emacs/29.0.50/ lisp/org/ob-ocaml /home/bidar/.emacs.d/elpa/org-9.5.4/ob-maxima hides /usr/share/emacs/29.0.50/ lisp/org/ob-maxima /home/bidar/.emacs.d/elpa/org-9.5.4/ob-matlab hides /usr/share/emacs/29.0.50/ lisp/org/ob-matlab /home/bidar/.emacs.d/elpa/org-9.5.4/ob-makefile hides /usr/share/emacs/ 29.0.50/lisp/org/ob-makefile /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lua hides /usr/share/emacs/29.0.50/ lisp/org/ob-lua /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lob hides /usr/share/emacs/29.0.50/ lisp/org/ob-lob /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lisp hides /usr/share/emacs/29.0.50/ lisp/org/ob-lisp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-lilypond hides /usr/share/emacs/ 29.0.50/lisp/org/ob-lilypond /home/bidar/.emacs.d/elpa/org-9.5.4/ob-latex hides /usr/share/emacs/29.0.50/ lisp/org/ob-latex /home/bidar/.emacs.d/elpa/org-9.5.4/ob-julia hides /usr/share/emacs/29.0.50/ lisp/org/ob-julia /home/bidar/.emacs.d/elpa/org-9.5.4/ob-js hides /usr/share/emacs/29.0.50/lisp/ org/ob-js /home/bidar/.emacs.d/elpa/org-9.5.4/ob-java hides /usr/share/emacs/29.0.50/ lisp/org/ob-java /home/bidar/.emacs.d/elpa/org-9.5.4/ob-haskell hides /usr/share/emacs/29.0.50/ lisp/org/ob-haskell /home/bidar/.emacs.d/elpa/org-9.5.4/ob-groovy hides /usr/share/emacs/29.0.50/ lisp/org/ob-groovy /home/bidar/.emacs.d/elpa/org-9.5.4/ob-gnuplot hides /usr/share/emacs/29.0.50/ lisp/org/ob-gnuplot /home/bidar/.emacs.d/elpa/org-9.5.4/ob-fortran hides /usr/share/emacs/29.0.50/ lisp/org/ob-fortran /home/bidar/.emacs.d/elpa/org-9.5.4/ob-forth hides /usr/share/emacs/29.0.50/ lisp/org/ob-forth /home/bidar/.emacs.d/elpa/org-9.5.4/ob-exp hides /usr/share/emacs/29.0.50/ lisp/org/ob-exp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-eval hides /usr/share/emacs/29.0.50/ lisp/org/ob-eval /home/bidar/.emacs.d/elpa/org-9.5.4/ob-eshell hides /usr/share/emacs/29.0.50/ lisp/org/ob-eshell /home/bidar/.emacs.d/elpa/org-9.5.4/ob-emacs-lisp hides /usr/share/emacs/ 29.0.50/lisp/org/ob-emacs-lisp /home/bidar/.emacs.d/elpa/org-9.5.4/ob-dot hides /usr/share/emacs/29.0.50/ lisp/org/ob-dot /home/bidar/.emacs.d/elpa/org-9.5.4/ob-ditaa hides /usr/share/emacs/29.0.50/ lisp/org/ob-ditaa /home/bidar/.emacs.d/elpa/org-9.5.4/ob-css hides /usr/share/emacs/29.0.50/ lisp/org/ob-css /home/bidar/.emacs.d/elpa/org-9.5.4/ob-core hides /usr/share/emacs/29.0.50/ lisp/org/ob-core /home/bidar/.emacs.d/elpa/org-9.5.4/ob-comint hides /usr/share/emacs/29.0.50/ lisp/org/ob-comint /home/bidar/.emacs.d/elpa/org-9.5.4/ob-clojure hides /usr/share/emacs/29.0.50/ lisp/org/ob-clojure /home/bidar/.emacs.d/elpa/org-9.5.4/ob-calc hides /usr/share/emacs/29.0.50/ lisp/org/ob-calc /home/bidar/.emacs.d/elpa/org-9.5.4/ob-awk hides /usr/share/emacs/29.0.50/ lisp/org/ob-awk /home/bidar/.emacs.d/elpa/org-9.5.4/ob-R hides /usr/share/emacs/29.0.50/lisp/ org/ob-R /home/bidar/.emacs.d/elpa/org-9.5.4/ob-C hides /usr/share/emacs/29.0.50/lisp/ org/ob-C Features: (shadow sort mail-extr emacsbug view epa-file guess-language cursor-sensor winner tramp-archive tramp-gvfs helm-command helm-elisp helm-eval edebug debug backtrace generic-x which-key beacon savehist csharp-mode csharp-compilation cc-langs make-mode tramp-cache time-stamp tramp-sh yaml-mode 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 forge-notify forge-revnote forge-pullreq forge-issue forge-topic yaml forge-post forge-repo forge forge-core forge-db closql emacsql-sqlite emacsql emacsql-compiler magit-bookmark 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 magit-repos magit-apply magit-wip magit-log which-func magit-diff git-commit log-edit add-log magit-core magit-autorevert magit-margin magit-transient magit-process magit-mode transient markdown-mode edit-indirect mule-util whitespace rainbow-delimiters rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid nxml-mode nxml-outln nxml-rap sgml-mode org-eldoc cdlatex reftex reftex-loaddefs reftex-vars texmathp ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message sendmail yank-media rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range ol-docview doc-view jka-compr ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi bat-mode smerge-mode diff highlight-indent-guides dired-aux vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view pcvs-util conf-mode vc bug-reference autorevert company-oddmuse company-keywords company-etags company-gtags company-dabbrev-code company-files company-clang company-cmake company-semantic company-bbdb company-qml qmltypes-parser qml-mode js imenu company-capf company-anaconda anaconda-mode pythonic f f-shortdoc shortdoc python vc-git vc-dispatcher symbol-overlay ws-butler editorconfig-core editorconfig-core-handle editorconfig-fnmatch smart-mode-line-powerline-theme lui-track-bar lui-track company-emoji company-emoji-list company-dabbrev helm-circe circe-notifications alert log4e notifications dbus gntp circe-display-images circe-color-nicks circe lui-irc-colors irc gnutls lcs lui-logging lui-format lui tracking shorten flyspell ispell circe-compat helm-pass password-store with-editor server auth-source-pass vterm term ehelp vterm-module term/xterm xterm conf_edit-server edit-server conf_printing printing ps-print ps-print-loaddefs lpr conf_clippboard conf_flyspell desktop frameset so-long cursor-chg recentf tree-widget helm-bookmark helm-net helm-adaptive helm-info helm-mode helm-misc helm-files image-dired xdg image-mode dired dired-loaddefs exif filenotify helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help helm-types helm helm-global-bindings helm-easymenu helm-core async-bytecomp helm-source helm-multi-match helm-lib async helm-config smart-mode-line-respectful-theme smart-mode-line rich-minority mode-icons emojify apropos tar-mode arc-mode archive-mode ht yasnippet elec-pair vim-modeline diff-mode lua-mode magit-git magit-base magit-section crm compat-27 compat-26 compat editorconfig projectile lisp-mnt grep ibuf-ext ibuffer ibuffer-loaddefs ggtags etags fileloop xref project ewoc nginx-mode flycheck-rtags cmake-ide s find-file web-mode disp-table conf_pkgbuild pkgbuild-mode sh-script smie executable org-caldav icalendar diary-lib diary-loaddefs org-id url-dav url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny xml ox-extra org-tree-slide org-timer org-clock outshine outshine-org-cmds outorg ox-koma-letter 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 org-agenda org-refile ox-html table ox-ascii ox-publish ox org-element avl-tree generator ob-latex ob-dot ob-plantuml 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 noutline outline org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs htmlize cl conf-perl company-rtags company-template rtags popup repeat thingatpt compile tramp tramp-loaddefs trampver tramp-integration cus-edit cus-load wid-edit files-x tramp-compat shell pcomplete comint parse-time iso8601 time-date ls-lisp format-spec asm-mode bookmark text-property-search cperl-mode facemenu conf_qt semantic/bovine/c hideif semantic/bovine/c-by semantic/lex-spp semantic/idle semantic/bovine/gcc semantic/dep semantic/bovine semantic/analyze/refs semantic/db-find semantic/db-ref semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn semantic/db eieio-base semantic/ctxt semantic/format ezimage semantic/tag-ls semantic/find semantic/util-modes semantic/util semantic pp semantic/tag semantic/lex semantic/fw mode-local cedet qt-pro derived edmacro kmacro cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs conf_flycheck flycheck-color-mode-line face-remap flycheck ansi-color find-func dash use-package-bind-key bind-key easy-mmode company pcase saveplace ir-black-theme gcmh use-package-ensure use-package-core conf_package finder-inf beacon-autoloads cdlatex-autoloads tex-site cmake-mode-autoloads anaconda-mode-autoloads company-emojify-autoloads csharp-mode-autoloads ein-autoloads forge-autoloads gcmh-autoloads ghub-autoloads company-autoloads flycheck-autoloads helm-autoloads helm-core-autoloads async-autoloads lsp-java-autoloads dap-mode-autoloads lsp-docker-autoloads lsp-ui-autoloads lsp-mode-autoloads magit-libgit-autoloads magit-autoloads git-commit-autoloads libgit-autoloads magit-section-autoloads powerline comp comp-cstr warnings icons rx cl-extra help-mode advice powerline-separators ring color powerline-themes all-the-icons-autoloads markdown-mode-autoloads org-contrib-autoloads pdf-tools-autoloads projectile-autoloads pythonic-autoloads f-autoloads request-autoloads transient-autoloads treemacs-autoloads dash-autoloads with-editor-autoloads info compat-autoloads xr-autoloads yaml-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile cconv url-vars cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 1519175 1505133) (symbols 48 74463 58) (strings 32 392180 270445) (string-bytes 1 11781428) (vectors 16 183178) (vector-slots 8 5401424 2075944) (floats 8 1181 4688) (intervals 56 35573 13613) (buffers 992 455))
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Thu, 04 Aug 2022 08:02:02 GMT) Full text and rfc822 format available.Message #8 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Thu, 04 Aug 2022 11:01:37 +0300
> Date: Thu, 04 Aug 2022 10:36:50 +0300 > From: Bjoern Bidar via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> > > To trigger the bug there needs to be some usage so I'm not sure how to > trigger the bug with ~emacs -Q~. > However Emacs just stops usually, sometimes emacs freezes for a few sec > before. > I start emacs as a systemd --user service, systemd reports that emacs > stops like this: > emacs.service: Main process exited, code=exited, status=1/FAILURE > > No other output or crashdump is there. > > It happens after a time, sometimes it fails after hours sometimes it fails > after 10 minues. Please do provide some data we can work with: either a recipe to reproduce the crash, or the backtrace from a debugger when the crash happens (you can obtain the latter if you run Emacs under a debugger to begin with). Thanks.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Thu, 04 Aug 2022 08:22:01 GMT) Full text and rfc822 format available.Message #11 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Thu, 04 Aug 2022 11:21:41 +0300
[Please use Reply All to reply, to keep the bug tracker on the CC.] > From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> > Date: Thu, 04 Aug 2022 11:05:00 +0300 > > The issue is that Emacs doesn't crash, it just exists with 1. > > The recipe to reproduce the bug is to just use emacs and wait till it crashes. > > I start emacs like this: > # /home/user/.config/systemd/user/emacs.service > > [Unit] > Description=Emacs: the extensible, self-documenting text editor > Wants=graphical.target > Wants=environment.target > > [Service] > Type=forking > ExecStart=/usr/bin/emacs --daemon > ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" > Environment=SSH_AUTH_SOCK=%t/keyring/ssh > Environment=GDK_DPI_SCALE=2 > Environment=GDK_SCALE=2 > Restart=always > TimeoutStartSec=0 > [Install] > WantedBy=default.target > > # /home/user/.config/systemd/user/emacs.service.d/override.conf > [Service] > TimeoutStopSec=600 Then please run Emacs under a debugger, or attach a debugger to it after you start it, and place a breakpoint in the function Fkill_emacs. When that breakpoint breaks, produce a backtrace (with the "thread apply all bt" command in GDB) and post that backtrace here. > I'm not sure if it helps but the most crashes I experienced when using irc > through circe. It depends on what we will see in the backtrace. Thanks.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Thu, 04 Aug 2022 11:51:02 GMT) Full text and rfc822 format available.Message #14 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 56967 <at> debbugs.gnu.org, Bjoern Bidar <bjorn.bidar <at> thaodan.de> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Thu, 04 Aug 2022 19:49:53 +0800
Eli Zaretskii <eliz <at> gnu.org> writes: > [Please use Reply All to reply, to keep the bug tracker on the CC.] Indeed. When you reply the wrong way, other people with relevant things to say cannot respond. >> The issue is that Emacs doesn't crash, it just exists with 1. >> >> The recipe to reproduce the bug is to just use emacs and wait till it crashes. >> >> I start emacs like this: >> # /home/user/.config/systemd/user/emacs.service >> >> [Unit] >> Description=Emacs: the extensible, self-documenting text editor >> Wants=graphical.target >> Wants=environment.target >> >> [Service] >> Type=forking >> ExecStart=/usr/bin/emacs --daemon >> ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" >> Environment=SSH_AUTH_SOCK=%t/keyring/ssh >> Environment=GDK_DPI_SCALE=2 >> Environment=GDK_SCALE=2 >> Restart=always >> TimeoutStartSec=0 >> [Install] >> WantedBy=default.target >> >> # /home/user/.config/systemd/user/emacs.service.d/override.conf >> [Service] >> TimeoutStopSec=600 > Then please run Emacs under a debugger, or attach a debugger to it > after you start it, and place a breakpoint in the function > Fkill_emacs. When that breakpoint breaks, produce a backtrace (with > the "thread apply all bt" command in GDB) and post that backtrace > here. Please also place a breakpoint on _exit -- GDK always calls that with the exit code 1 that when a display connection is abruptly lost, in which case Fkill_emacs has no chance to run. Thanks in advance.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Thu, 04 Aug 2022 18:30:02 GMT) Full text and rfc822 format available.Message #17 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Bennet Yee (余仕斌) <bennet.yee <at> gmail.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Thu, 04 Aug 2022 21:29:18 +0300
[Please CC the bug address, don't send private email just to me.] > From: Bennet Yee (余仕斌) <bennet.yee <at> gmail.com> > Date: Thu, 4 Aug 2022 11:12:44 -0700 > > FWIW I appeared to have just ran into this. With emacs-gtk whenever I set mark and move down a line > (which would highlight the region) emacs would crash: > > Backtrace: > emacs(+0x150ed5)[0x55cb9e339ed5] > emacs(+0x4aa38)[0x55cb9e233a38] > emacs(+0x4af22)[0x55cb9e233f22] > emacs(+0x14eefd)[0x55cb9e337efd] > emacs(+0x14ef7d)[0x55cb9e337f7d] > /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f068ca42520] > /lib/x86_64-linux-gnu/libX11.so.6(XVisualIDFromVisual+0x4)[0x7f068e1f5f24] > /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_x11_window_foreign_new_for_display+0x18e)[0x7f068e979a2e] > /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6b9f8)[0x7f068e9649f8] > /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6d191)[0x7f068e966191] > /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70d28)[0x7f068e969d28] > /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_display_get_event+0x89)[0x7f068e92fa99] > /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70f46)[0x7f068e969f46] > /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b)[0x7f068e37ed1b] > /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xaa6f8)[0x7f068e3d36f8] > /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33)[0x7f068e37c3c3] > /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_iteration+0x19)[0x7f068ec48d99] > emacs(+0x105073)[0x55cb9e2ee073] > emacs(+0x13d482)[0x55cb9e326482] > emacs(+0x13da75)[0x55cb9e326a75] > emacs(+0x1ba1b5)[0x55cb9e3a31b5] > emacs(+0xb55ec)[0x55cb9e29e5ec] > emacs(+0x7bac4)[0x55cb9e264ac4] > emacs(+0x8b9e8)[0x55cb9e2749e8] > emacs(+0x90783)[0x55cb9e279783] > emacs(+0xa5611)[0x55cb9e28e611] > emacs(+0xa8096)[0x55cb9e291096] > emacs(+0x1b30dc)[0x55cb9e39c0dc] > emacs(+0x94363)[0x55cb9e27d363] > emacs(+0x140ef3)[0x55cb9e329ef3] > emacs(+0x143bea)[0x55cb9e32cbea] > emacs(+0x14538c)[0x55cb9e32e38c] > emacs(+0x1b3047)[0x55cb9e39c047] > emacs(+0x136190)[0x55cb9e31f190] > emacs(+0x1b2f89)[0x55cb9e39bf89] > emacs(+0x13611e)[0x55cb9e31f11e] > emacs(+0x13b72a)[0x55cb9e32472a] > emacs(+0x13ba69)[0x55cb9e324a69] > emacs(+0x52aca)[0x55cb9e23baca] > /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f068ca29d90] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f068ca29e40] > ... Thanks, but this kind of backtrace can only be interpreted on your system. Please either show the results of running addr2line on it (as explained in the node "Crashing" of the Emacs manual), or run Emacs under GDB and produce a human-readable backtrace from there.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 00:19:02 GMT) Full text and rfc822 format available.Message #20 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 03:18:17 +0300
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Then please run Emacs under a debugger, or attach a debugger to it
> > after you start it, and place a breakpoint in the function
> > Fkill_emacs. When that breakpoint breaks, produce a backtrace (with
> > the "thread apply all bt" command in GDB) and post that backtrace
> > here.
>
> Please also place a breakpoint on _exit -- GDK always calls that with
> the exit code 1 that when a display connection is abruptly lost, in
> which case Fkill_emacs has no chance to run.
>
> Thanks in advance.
Started emacs via systemd as and set both break points as asked.
There you go:
Thread 1 "emacs" hit Breakpoint 2, __GI__exit (status=status <at> entry=1) at ../
sysdeps/unix/sysv/linux/_exit.c:27
27 {
(gdb) bt
#0 __GI__exit (status=status <at> entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:
27
#1 0x00007fdac9c825ae in gdk_event_source_check
(base=base <at> entry=0x5626b0eb7770) at ../gtk/gdk/wayland/gdkeventsource.c:97
#2 0x00007fdac962411f in g_main_context_check (context=0x5626b71d9be0,
max_priority=2147483647, fds=<optimized out>, n_fds=<optimized out>) at ../
glib/glib/gmain.c:4035
#3 0x00007fdac9679e5e in g_main_context_iterate.constprop.0
(context=context <at> entry=0x5626b71d9be0, block=block <at> entry=0,
dispatch=dispatch <at> entry=0, self=<optimized out>) at ../glib/glib/gmain.c:4208
#4 0x00007fdac962132d in g_main_context_pending (context=0x5626b71d9be0) at
../glib/glib/gmain.c:4241
#5 0x00005626ab4f3bd2 in pgtk_read_socket.lto_priv ()
#6 0x00005626ab3a3731 in gobble_input ()
#7 0x00005626ab3a3ba5 in unblock_input ()
#8 0x00005626ab4c7f23 in ftcrfont_text_extents.lto_priv ()
#9 0x00005626ab30e4a5 in gui_produce_glyphs ()
#10 0x00005626ab2fcb90 in display_line.lto_priv ()
#11 0x00005626ab2ef021 in try_window ()
#12 0x00005626ab2f6641 in redisplay_window.lto_priv ()
#13 0x00005626ab2e7a1e in redisplay_window_1 ()
#14 0x00005626ab427ecc in internal_condition_case_1 ()
#15 0x00005626ab2ec09a in redisplay_internal.lto_priv ()
#16 0x00005626ab51c025 in redisplay_preserve_echo_area.constprop ()
#17 0x00005626ab49e8d6 in wait_reading_process_output ()
#18 0x00005626ab2b6419 in sit_for ()
#19 0x00005626ab3a0f02 in read_char ()
#20 0x00005626ab3a83f4 in read_key_sequence.lto_priv ()
#21 0x00005626ab39bba8 in command_loop_1.lto_priv ()
#22 0x00005626ab427e37 in internal_condition_case ()
#23 0x00005626ab3939ce in command_loop_2 ()
#24 0x00005626ab427d7a in internal_catch ()
#25 0x00005626ab396cd9 in command_loop.lto_priv ()
#26 0x00005626ab5298ab in recursive_edit_1.isra ()
#27 0x00005626ab397090 in Frecursive_edit ()
#28 0x00005626ab2aac2f in main ()
(gdb)
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 00:52:02 GMT) Full text and rfc822 format available.Message #23 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 08:50:39 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> > Then please run Emacs under a debugger, or attach a debugger to it
>> > after you start it, and place a breakpoint in the function
>> > Fkill_emacs. When that breakpoint breaks, produce a backtrace (with
>> > the "thread apply all bt" command in GDB) and post that backtrace
>> > here.
>>
>> Please also place a breakpoint on _exit -- GDK always calls that with
>> the exit code 1 that when a display connection is abruptly lost, in
>> which case Fkill_emacs has no chance to run.
>>
>> Thanks in advance.
>
> Started emacs via systemd as and set both break points as asked.
>
> There you go:
>
>
> Thread 1 "emacs" hit Breakpoint 2, __GI__exit (status=status <at> entry=1) at ../
> sysdeps/unix/sysv/linux/_exit.c:27
> 27 {
> (gdb) bt
> #0 __GI__exit (status=status <at> entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:
> 27
> #1 0x00007fdac9c825ae in gdk_event_source_check
> (base=base <at> entry=0x5626b0eb7770) at ../gtk/gdk/wayland/gdkeventsource.c:97
> #2 0x00007fdac962411f in g_main_context_check (context=0x5626b71d9be0,
> max_priority=2147483647, fds=<optimized out>, n_fds=<optimized out>) at ../
> glib/glib/gmain.c:4035
> #3 0x00007fdac9679e5e in g_main_context_iterate.constprop.0
> (context=context <at> entry=0x5626b71d9be0, block=block <at> entry=0,
> dispatch=dispatch <at> entry=0, self=<optimized out>) at ../glib/glib/gmain.c:4208
> #4 0x00007fdac962132d in g_main_context_pending (context=0x5626b71d9be0) at
> ../glib/glib/gmain.c:4241
> #5 0x00005626ab4f3bd2 in pgtk_read_socket.lto_priv ()
That's what I thought might be happening. Emacs calls
g_main_context_pending to read events from GDK, which notices that the
display connection has been abruptly terminated, and calls _exit to
abort.
Unfortunately, there's no way for us to fix this inside Emacs, so I
guess you should look into why Wayland display connections are so
unstable on your system.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:26:02 GMT) Full text and rfc822 format available.Message #26 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 09:25:02 +0300
> From: Po Lu <luangruo <at> yahoo.com> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 56967 <at> debbugs.gnu.org > Date: Fri, 05 Aug 2022 08:50:39 +0800 > > That's what I thought might be happening. Emacs calls > g_main_context_pending to read events from GDK, which notices that the > display connection has been abruptly terminated, and calls _exit to > abort. > > Unfortunately, there's no way for us to fix this inside Emacs, so I > guess you should look into why Wayland display connections are so > unstable on your system. Does _exit in glibc provide any hooks that we could use? Emacs cannot be the first application that doesn't want misbehaving libraries to forcibly exit it. Or maybe GTK has some knob to let it call us before it calls _exit?
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:29:01 GMT) Full text and rfc822 format available.Message #29 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:28:21 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:
> Does _exit in glibc provide any hooks that we could use?
Not that I know of.
> Emacs cannot be the first application that doesn't want misbehaving
> libraries to forcibly exit it.
It literally is, in the case of users of GDK.
> Or maybe GTK has some knob to let it call us before it calls _exit?
Nope, GTK simply does this:
if (wl_display_flush (display->wl_display) < 0)
{
g_message ("Error flushing display: %s", g_strerror (errno));
_exit (1);
}
if (for example) wl_display_flush, a low-level Wayland interface, fails
from an IO error.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:31:02 GMT) Full text and rfc822 format available.Message #32 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:29:47 +0800
[*Please* use "Reply All" to reply, otherwise your response will not be recorded on the bug tracker] Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > That's the thing it doesn't look like the connection is unstabl alos nothing > else but Emacs has this issue. Did you leave anything else up for long enough? Try keeping gtk3-demo up for a similar amount of time.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:32:01 GMT) Full text and rfc822 format available.Message #35 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 09:31:19 +0300
Also why should Emacs exit just when my display connection closes when it is run as server/daemon?
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:32:01 GMT) Full text and rfc822 format available.Message #38 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:31:35 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > Also why should Emacs exit just when my display connection closes when it is > run as server/daemon? Emacs can't do anything about it. GDK (the library used by the GTK toolkit for low-level display server interaction) automatically calls _exit upon an IO error when writing or reading from a display connection. And please use "Reply All" to reply, or otherwise the conversation will not be recorded on the bug tracker.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:36:01 GMT) Full text and rfc822 format available.Message #41 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:35:10 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > Also I have to add that I'm using two screens, Emacs mentioned that is > could be an issue when starting. What message did Emacs print in that case?
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:44:02 GMT) Full text and rfc822 format available.Message #44 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 09:43:44 +0300
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: bjorn.bidar <at> thaodan.de, 56967 <at> debbugs.gnu.org
> Date: Fri, 05 Aug 2022 14:28:21 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Does _exit in glibc provide any hooks that we could use?
>
> Not that I know of.
How about asking the glibc developers to provide one, citing this very
use case as the real-life problem to solve? Specifically, what I'd
like to do in that hook is to shut down Emacs in an orderly manner, so
that the user won't lose all his/her edits.
> > Or maybe GTK has some knob to let it call us before it calls _exit?
>
> Nope, GTK simply does this:
>
> if (wl_display_flush (display->wl_display) < 0)
> {
> g_message ("Error flushing display: %s", g_strerror (errno));
> _exit (1);
> }
>
> if (for example) wl_display_flush, a low-level Wayland interface, fails
> from an IO error.
Amazing. Where did those people learn to develop friendly, extensible
libraries? in what tyrannical culture?
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:54:02 GMT) Full text and rfc822 format available.Message #47 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:53:19 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:
> How about asking the glibc developers to provide one, citing this very
> use case as the real-life problem to solve? Specifically, what I'd
> like to do in that hook is to shut down Emacs in an orderly manner, so
> that the user won't lose all his/her edits.
By running the code inside `shut_down_emacs'? I will indeed ask for such
a hook.
>> > Or maybe GTK has some knob to let it call us before it calls _exit?
>>
>> Nope, GTK simply does this:
>>
>> if (wl_display_flush (display->wl_display) < 0)
>> {
>> g_message ("Error flushing display: %s", g_strerror (errno));
>> _exit (1);
>> }
>>
>> if (for example) wl_display_flush, a low-level Wayland interface, fails
>> from an IO error.
>
> Amazing. Where did those people learn to develop friendly, extensible
> libraries? in what tyrannical culture?
I'd say their culture has changed in the past decade and is now pretty
close to Apple's. Unfortunately, Wayland is gaining popularity (as
evidenced by the amount of our users who report related bugs), and GTK
is the only toolkit that provides useful support for it.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:56:01 GMT) Full text and rfc822 format available.Message #50 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 09:55:44 +0300
> Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > > Also I have to add that I'm using two screens, Emacs mentioned that is > > could be an issue when starting. > > What message did Emacs print in that case? Aug 03 18:06:22 odin emacs[158852]: Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a Aug 03 18:06:22 odin emacs[158852]: display connection is closed. The problem is especially difficult to fix, Aug 03 18:06:22 odin emacs[158852]: such that Emacs on Wayland with multiple displays is unlikely ever to be able Aug 03 18:06:22 odin emacs[158852]: to survive disconnects.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 06:57:01 GMT) Full text and rfc822 format available.Message #53 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 09:56:33 +0300
Am Freitag, 5. August 2022, 09:28:21 EEST schrieb Po Lu:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Does _exit in glibc provide any hooks that we could use?
>
> Not that I know of.
>
> > Emacs cannot be the first application that doesn't want misbehaving
> > libraries to forcibly exit it.
>
> It literally is, in the case of users of GDK.
>
> > Or maybe GTK has some knob to let it call us before it calls _exit?
>
> Nope, GTK simply does this:
>
> if (wl_display_flush (display->wl_display) < 0)
> {
> g_message ("Error flushing display: %s", g_strerror (errno));
> _exit (1);
> }
>
> if (for example) wl_display_flush, a low-level Wayland interface, fails
> from an IO error.
How should any app clean up after it selfs when GTK just closes it?
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 07:01:02 GMT) Full text and rfc822 format available.Message #56 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:59:58 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > How should any app clean up after it selfs when GTK just closes it? Programs cannot at present. I've asked the glibc developers for an appropriate hook.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 07:02:01 GMT) Full text and rfc822 format available.Message #59 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 15:01:07 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: >> Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: >> > Also I have to add that I'm using two screens, Emacs mentioned that is >> > could be an issue when starting. >> >> What message did Emacs print in that case? > > Aug 03 18:06:22 odin emacs[158852]: Due to a limitation in GTK 3, Emacs built > with PGTK will simply exit when a > Aug 03 18:06:22 odin emacs[158852]: display connection is closed. The problem > is especially difficult to fix, > Aug 03 18:06:22 odin emacs[158852]: such that Emacs on Wayland with multiple > displays is unlikely ever to be able > Aug 03 18:06:22 odin emacs[158852]: to survive disconnects. Right, but "display connection" here means a connection to the display server (Wayland compositor.) That isn't related to the number of monitors connected to your machine.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 07:35:01 GMT) Full text and rfc822 format available.Message #62 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 56967 <at> debbugs.gnu.org, "Bennet Yee \(余仕斌\)" <bennet.yee <at> gmail.com> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 15:34:38 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Bennet Yee (余仕斌) <bennet.yee <at> gmail.com>
>> Date: Thu, 4 Aug 2022 11:12:44 -0700
>>
>> FWIW I appeared to have just ran into this. With emacs-gtk whenever I set mark and move down a line
>> (which would highlight the region) emacs would crash:
>>
>> Backtrace:
>> emacs(+0x150ed5)[0x55cb9e339ed5]
>> emacs(+0x4aa38)[0x55cb9e233a38]
>> emacs(+0x4af22)[0x55cb9e233f22]
>> emacs(+0x14eefd)[0x55cb9e337efd]
>> emacs(+0x14ef7d)[0x55cb9e337f7d]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f068ca42520]
>> /lib/x86_64-linux-gnu/libX11.so.6(XVisualIDFromVisual+0x4)[0x7f068e1f5f24]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_x11_window_foreign_new_for_display+0x18e)[0x7f068e979a2e]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6b9f8)[0x7f068e9649f8]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6d191)[0x7f068e966191]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70d28)[0x7f068e969d28]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(gdk_display_get_event+0x89)[0x7f068e92fa99]
>> /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70f46)[0x7f068e969f46]
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b)[0x7f068e37ed1b]
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xaa6f8)[0x7f068e3d36f8]
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33)[0x7f068e37c3c3]
>> /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_iteration+0x19)[0x7f068ec48d99]
>> emacs(+0x105073)[0x55cb9e2ee073]
>> emacs(+0x13d482)[0x55cb9e326482]
>> emacs(+0x13da75)[0x55cb9e326a75]
>> emacs(+0x1ba1b5)[0x55cb9e3a31b5]
>> emacs(+0xb55ec)[0x55cb9e29e5ec]
>> emacs(+0x7bac4)[0x55cb9e264ac4]
>> emacs(+0x8b9e8)[0x55cb9e2749e8]
>> emacs(+0x90783)[0x55cb9e279783]
>> emacs(+0xa5611)[0x55cb9e28e611]
>> emacs(+0xa8096)[0x55cb9e291096]
>> emacs(+0x1b30dc)[0x55cb9e39c0dc]
>> emacs(+0x94363)[0x55cb9e27d363]
>> emacs(+0x140ef3)[0x55cb9e329ef3]
>> emacs(+0x143bea)[0x55cb9e32cbea]
>> emacs(+0x14538c)[0x55cb9e32e38c]
>> emacs(+0x1b3047)[0x55cb9e39c047]
>> emacs(+0x136190)[0x55cb9e31f190]
>> emacs(+0x1b2f89)[0x55cb9e39bf89]
>> emacs(+0x13611e)[0x55cb9e31f11e]
>> emacs(+0x13b72a)[0x55cb9e32472a]
>> emacs(+0x13ba69)[0x55cb9e324a69]
>> emacs(+0x52aca)[0x55cb9e23baca]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f068ca29d90]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f068ca29e40]
>> ...
Bennet Lee, do you have a clipboard manager installed on your system?
I'm going to guess changing the region caused ownership to be asserted
over the primary selection, in turn causing the clipboard manager to
send Emacs a selection request from an InputOnly window. GDK then tried
to create a wrapper around that window, but crashed because the visual
of the InputOnly window could not be found in its own client-side record
of GDK visual objects.
This chain of events should only be possible on PGTK builds running on
X. In that case, you should simply refrain from using PGTK on X. This
problem and many others cause us to not support running such builds on
X.
If not, please see if the following change is sufficient to fix the
problem:
diff --git a/src/xterm.c b/src/xterm.c
index 4bbcfb0e59..5bc755b41f 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -17613,6 +17613,12 @@ handle_one_xevent (struct x_display_info *dpyinfo,
if (eventp->target == dpyinfo->Xatom_XmTRANSFER_FAILURE)
x_dnd_action = None;
}
+
+ /* Selection requests for the widget should never reach
+ GDK. */
+#ifdef USE_GTK
+ *finish = X_EVENT_DROP;
+#endif
}
break;
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 07:47:02 GMT) Full text and rfc822 format available.Message #65 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 10:46:03 +0300
> From: Po Lu <luangruo <at> yahoo.com> > Cc: bjorn.bidar <at> thaodan.de, 56967 <at> debbugs.gnu.org > Date: Fri, 05 Aug 2022 14:53:19 +0800 > > Eli Zaretskii <eliz <at> gnu.org> writes: > > > How about asking the glibc developers to provide one, citing this very > > use case as the real-life problem to solve? Specifically, what I'd > > like to do in that hook is to shut down Emacs in an orderly manner, so > > that the user won't lose all his/her edits. > > By running the code inside `shut_down_emacs'? Yes. > I will indeed ask for such a hook. Thanks. > > Amazing. Where did those people learn to develop friendly, extensible > > libraries? in what tyrannical culture? > > I'd say their culture has changed in the past decade and is now pretty > close to Apple's. Unfortunately, Wayland is gaining popularity (as > evidenced by the amount of our users who report related bugs), and GTK > is the only toolkit that provides useful support for it. Maybe we should keep complaining there until someone hears us. Calling _exit after printing an error message is not a reasonable thing to do in a general-purpose library. Exiting is something an application should do.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 08:27:02 GMT) Full text and rfc822 format available.Message #68 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 11:26:34 +0300
Am Freitag, 5. August 2022, 10:46:03 EEST schrieb Eli Zaretskii: > > From: Po Lu <luangruo <at> yahoo.com> > > Cc: bjorn.bidar <at> thaodan.de, 56967 <at> debbugs.gnu.org > > Date: Fri, 05 Aug 2022 14:53:19 +0800 > > > > Eli Zaretskii <eliz <at> gnu.org> writes: > > > How about asking the glibc developers to provide one, citing this very > > > use case as the real-life problem to solve? Specifically, what I'd > > > like to do in that hook is to shut down Emacs in an orderly manner, so > > > that the user won't lose all his/her edits. > > > > By running the code inside `shut_down_emacs'? > > Yes. > > > I will indeed ask for such a hook. > > Thanks. > > > > Amazing. Where did those people learn to develop friendly, extensible > > > libraries? in what tyrannical culture? > > > > I'd say their culture has changed in the past decade and is now pretty > > close to Apple's. Unfortunately, Wayland is gaining popularity (as > > evidenced by the amount of our users who report related bugs), and GTK > > is the only toolkit that provides useful support for it. > > Maybe we should keep complaining there until someone hears us. > Calling _exit after printing an error message is not a reasonable > thing to do in a general-purpose library. Exiting is something an > application should do. I agree. Is there an existing bug for this? This reminds me of a similar bug in the X11 session that still isn't fixed.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 08:40:02 GMT) Full text and rfc822 format available.Message #71 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 16:38:45 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > I agree. Is there an existing bug for this? This reminds me of a > similar bug in the X11 session that still isn't fixed. There are several, the bug in the X11 backend applies (in a general sense) to this as well. The difference is there used to be a semi-working workaround provided by Xlib, involving longjmp, whose developers thankfully do not share the GTK approach to error handling.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 11:41:02 GMT) Full text and rfc822 format available.Message #74 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Gregory Heytings <gregory <at> heytings.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Po Lu <luangruo <at> yahoo.com>, 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 11:40:36 +0000
[Message part 1 (text/plain, inline)]
> > Does _exit in glibc provide any hooks that we could use? Emacs cannot > be the first application that doesn't want misbehaving libraries to > forcibly exit it. > It's possible (albeit tricky) to escape an _exit() call by using LD_PRELOAD, see attached example. Whether this is usable for Emacs, I don't know.
[escape-exit.tgz (application/x-gtar-compressed, attachment)]
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Fri, 05 Aug 2022 11:51:02 GMT) Full text and rfc822 format available.Message #77 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gregory Heytings <gregory <at> heytings.org> Cc: luangruo <at> yahoo.com, 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Fri, 05 Aug 2022 14:50:24 +0300
> Date: Fri, 05 Aug 2022 11:40:36 +0000 > From: Gregory Heytings <gregory <at> heytings.org> > cc: Po Lu <luangruo <at> yahoo.com>, 56967 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de > > > Does _exit in glibc provide any hooks that we could use? Emacs cannot > > be the first application that doesn't want misbehaving libraries to > > forcibly exit it. > > It's possible (albeit tricky) to escape an _exit() call by using > LD_PRELOAD, see attached example. Whether this is usable for Emacs, I > don't know. Interesting. I'll defer to Linux experts to tell whether this is something we could/should use. Thanks.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Sun, 07 Aug 2022 14:52:01 GMT) Full text and rfc822 format available.Message #80 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Sun, 07 Aug 2022 17:51:25 +0300
Am Freitag, 5. August 2022, 09:29:47 EEST schrieb Po Lu: > [*Please* use "Reply All" to reply, otherwise your response will not be > recorded on the bug tracker] > > Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > > That's the thing it doesn't look like the connection is unstabl alos > > nothing else but Emacs has this issue. > > Did you leave anything else up for long enough? Try keeping gtk3-demo up > for a similar amount of time. I did I had my hole session running, nothing else had that issue. I kept the GTK-Demo running nothing happened it ran just fine. After a few hours Emacs exited with the same behaviour as explained in the bug. I on the #gtk channel on what do and I got from ebassi that it is ok to just call _exit. He says it might be the client behaving wrong: <ebassi> Thaodan: It could happen because the client made an invalid request— Wayland mandates that the display server closes the connection in that case I don't really understand why calling _exit is an acceptable solution anyone that has to safe some state to the disk is lost. I attach the whole conversation to not take anything out of context here: <Thaodan> Hello why does GTK call _exit when a display connection is lost in wayland, how can the app react to loosing the display connection? <Thaodan> I noticed that Emacs sometimes looses the display connection under Wayland (not XWayland). <ebassi> You don't <ebassi> If a client loses the connection to a running compositor then it's generally a bug in the client <ebassi> If you lose the connection to the display server all hope is generally lost <Thaodan> ebassi: An app may run longer or before the compositor starts even if not it's not nice as an application to just quit and not even let the application clean up after it self. <ebassi> In theory, under Wayland, it might be possible to clean all data attached to the display, but it's unlikely this will ever work without applications dealing with it <ebassi> And if you lose the socket then you' <ebassi> you'll have to find the new one and reconnect <ebassi> Thaodan: Only emacs does that <ebassi> Pretty much literally <Thaodan> "that"? <ebassi> "app may run longer or before the compositor starts" <ebassi> Because emacs is really a 1980s teletype app <Thaodan> What does that change? calling _exit is not a solution. <Thaodan> Lets assume the fault for this happening is emacs, what could cause this? <ebassi> Calling exit is perfectly acceptable: the display connection is severed, and that can happen for multiple reasons, including the display server going away <ebassi> There's no "the display server is still running, but it closed the socket" mechanism for the toolkit to use <ebassi> The socket got closed <ebassi> The toolkit terminates <ebassi> Thaodan: It could happen because the client made an invalid request— Wayland mandates that the display server closes the connection in that case <ebassi> Or the display server decided to kill the client because it was unresponsive <Thaodan> Why should the toolkit/lib call exit isn't there any better mechanism to doing such a thing in glib or gtk for that matter? <Thaodan> It would be better to not need any hacks to prevent gtk from killing apps. <ebassi> Thaodan: There is no such mechanism <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, doesn't that break any other app that has state so safe too? like for example an office application that wants to safe it's data before going down. <ebassi> I already told you <ebassi> If the display connection is closed by the server, then there's no safe way to store the data
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Sun, 07 Aug 2022 15:08:01 GMT) Full text and rfc822 format available.Message #83 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: luangruo <at> yahoo.com, 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Sun, 07 Aug 2022 18:07:29 +0300
> Cc: 56967 <at> debbugs.gnu.org > Date: Sun, 07 Aug 2022 17:51:25 +0300 > From: Bjoern Bidar via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> > > I on the #gtk channel on what do and I got from ebassi that it is ok to just > call _exit. > He says it might be the client behaving wrong: > <ebassi> Thaodan: It could happen because the client made an invalid request— > Wayland mandates that the display server closes the connection in that case > > I don't really understand why calling _exit is an acceptable solution anyone > that has to safe some state to the disk is lost. > > I attach the whole conversation to not take anything out of context here: Those guys evidently think that an application without display cannot do anything. They forget that even if display connection is lost, and even if this is due to some fault of the application, that application could still shut down gracefully instead of losing all of the user's work, if only GTK wouldn't call _exit "because it's acceptable", or "because emacs is a 1980s teletype app", or because whatever other ridiculous justifications these guys come up for such misconduct. > <ebassi> I already told you > <ebassi> If the display connection is closed by the server, then there's no > safe way to store the data Really? Since when does saving data to disk require a display connection??
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Sun, 07 Aug 2022 15:15:01 GMT) Full text and rfc822 format available.Message #86 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Sun, 07 Aug 2022 18:14:50 +0300
Am Sonntag, 7. August 2022, 18:07:29 EEST schrieb Eli Zaretskii: > > Cc: 56967 <at> debbugs.gnu.org > > Date: Sun, 07 Aug 2022 17:51:25 +0300 > > From: Bjoern Bidar via "Bug reports for GNU Emacs, > > > > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> > > > > I on the #gtk channel on what do and I got from ebassi that it is ok to > > just call _exit. > > He says it might be the client behaving wrong: > > <ebassi> Thaodan: It could happen because the client made an invalid > > request— Wayland mandates that the display server closes the connection > > in that case > > > > I don't really understand why calling _exit is an acceptable solution > > anyone that has to safe some state to the disk is lost. > > > I attach the whole conversation to not take anything out of context here: > Those guys evidently think that an application without display cannot > do anything. They forget that even if display connection is lost, and > even if this is due to some fault of the application, that application > could still shut down gracefully instead of losing all of the user's > work, if only GTK wouldn't call _exit "because it's acceptable", or > "because emacs is a 1980s teletype app", or because whatever other > ridiculous justifications these guys come up for such misconduct. I don't know what to say, I'm befuddled too. The audacity to act such a way as a library. > > <ebassi> I already told you > > <ebassi> If the display connection is closed by the server, then there's > > no > > safe way to store the data > > Really? Since when does saving data to disk require a display > connection?? I don't know either, this is what came after: <ebassi> Because the toolkit has no idea what's left of the system's integrity <two[m]> how could it start before the compositor? <Thaodan> the display connection lost doesn't mean the whole system is broken but just the compositor. But I assume that the toolkit takes precedence over the app it self. <ebassi> Thaodan: You literally **cannot** know that <Thaodan> two[m]: background services such as systemd --user services <two[m]> wouldn't it fail because no $WAYLAND_DISPLAY? *** First activity: MichaelNazzarenoTrimarchi[m] joined 53 minutes 11 seconds ago. <MichaelNazzarenoTrimarchi[m]> Well the app can really do anything before starting the graphic subsystem. It can even wait that Wayland service is started before do any specific toolkit initialization <Thaodan> MichaelNazzarenoTrimarchi[m]: Exactly, apps such as editors might reload their last session which can take quite some time <Thaodan> There it makes sense to start as early as possible. <Thaodan> How can I find out if GTK did an invalid request to the compositor? <MichaelNazzarenoTrimarchi[m]> That is simple <MichaelNazzarenoTrimarchi[m]> You can activate Wayland tracing of message <MichaelNazzarenoTrimarchi[m]> You can see then message sent to compositor <MichaelNazzarenoTrimarchi[m]> It's rather difficult that is an application bug but could be a client side Wayland part bug
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Sun, 07 Aug 2022 15:45:02 GMT) Full text and rfc822 format available.Message #89 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: luangruo <at> yahoo.com, 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Sun, 07 Aug 2022 18:44:12 +0300
> From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> > Cc: luangruo <at> yahoo.com, 56967 <at> debbugs.gnu.org > Date: Sun, 07 Aug 2022 18:14:50 +0300 > > > > <ebassi> I already told you > > > <ebassi> If the display connection is closed by the server, then there's > > > no > > > safe way to store the data > > > > Really? Since when does saving data to disk require a display > > connection?? > > I don't know either, this is what came after: > > <ebassi> Because the toolkit has no idea what's left of the system's integrity > <two[m]> how could it start before the compositor? > <Thaodan> the display connection lost doesn't mean the whole system is broken > but just the compositor. But I assume that the toolkit takes precedence over > the app it self. > <ebassi> Thaodan: You literally **cannot** know that A tail wagging the dog, really...
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Mon, 08 Aug 2022 02:41:01 GMT) Full text and rfc822 format available.Message #92 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Mon, 08 Aug 2022 10:40:30 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > I did I had my hole session running, nothing else had that issue. > I kept the GTK-Demo running nothing happened it ran just fine. Thanks. > After a few hours Emacs exited with the same behaviour as explained in the > bug. Do you see the same if you run Emacs as something other a daemon? > I on the #gtk channel on what do and I got from ebassi that it is ok to just > call _exit. > He says it might be the client behaving wrong: > <ebassi> Thaodan: It could happen because the client made an invalid request— > Wayland mandates that the display server closes the connection in that case We don't make raw Wayland requests anywhere, so it must be a bug in GTK. > <ebassi> And if you lose the socket then you' > <ebassi> you'll have to find the new one and reconnect > <ebassi> Thaodan: Only emacs does that > <ebassi> Pretty much literally > <Thaodan> "that"? > <ebassi> "app may run longer or before the compositor starts" > <ebassi> Because emacs is really a 1980s teletype app > <Thaodan> What does that change? calling _exit is not a solution. > <Thaodan> Lets assume the fault for this happening is emacs, what could cause > this? Outdated information. The PGTK port of Emacs doesn't do anything close to that, because GTK doesn't let us. > <ebassi> Calling exit is perfectly acceptable: the display connection is > severed, and that can happen for multiple reasons, including the display > server going away > <ebassi> There's no "the display server is still running, but it closed the > socket" mechanism for the toolkit to use So why not use exit, which lets the atexit handlers run? > <ebassi> The socket got closed > <ebassi> The toolkit terminates > <ebassi> Thaodan: It could happen because the client made an invalid request— > Wayland mandates that the display server closes the connection in that case > <ebassi> Or the display server decided to kill the client because it was > unresponsive > <Thaodan> Why should the toolkit/lib call exit isn't there any better > mechanism to doing such a thing in glib or gtk for that matter? > <Thaodan> It would be better to not need any hacks to prevent gtk from killing > apps. > <ebassi> Thaodan: There is no such mechanism > <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, > doesn't that break any other app that has state so safe too? like for example > an office application that wants to safe it's data before going down. > <ebassi> I already told you > <ebassi> If the display connection is closed by the server, then there's no > safe way to store the data Store the data that is in Emacs core?? How did these people learn to write software?
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Mon, 08 Aug 2022 02:43:02 GMT) Full text and rfc822 format available.Message #95 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Mon, 08 Aug 2022 10:42:08 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > <MichaelNazzarenoTrimarchi[m]> That is simple > <MichaelNazzarenoTrimarchi[m]> You can activate Wayland tracing of message > <MichaelNazzarenoTrimarchi[m]> You can see then message sent to compositor > <MichaelNazzarenoTrimarchi[m]> It's rather difficult that is an application > bug but could be a client side Wayland part bug That's a good idea, but I don't remember how to do that. Perhaps you should ask there.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Mon, 08 Aug 2022 06:08:02 GMT) Full text and rfc822 format available.Message #98 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Mon, 08 Aug 2022 09:07:30 +0300
Am Montag, 8. August 2022, 05:40:30 EEST schrieb Po Lu: > Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > > I did I had my hole session running, nothing else had that issue. > > I kept the GTK-Demo running nothing happened it ran just fine. > > Thanks. > > > After a few hours Emacs exited with the same behaviour as explained in the > > bug. > > Do you see the same if you run Emacs as something other a daemon? I didn't but I can try. Maybe something in the environment variables is different. > > I on the #gtk channel on what do and I got from ebassi that it is ok to > > just call _exit. > > He says it might be the client behaving wrong: > > <ebassi> Thaodan: It could happen because the client made an invalid > > request— Wayland mandates that the display server closes the connection > > in that case > We don't make raw Wayland requests anywhere, so it must be a bug in GTK. > > > <ebassi> And if you lose the socket then you' > > <ebassi> you'll have to find the new one and reconnect > > <ebassi> Thaodan: Only emacs does that > > <ebassi> Pretty much literally > > <Thaodan> "that"? > > <ebassi> "app may run longer or before the compositor starts" > > <ebassi> Because emacs is really a 1980s teletype app > > <Thaodan> What does that change? calling _exit is not a solution. > > <Thaodan> Lets assume the fault for this happening is emacs, what could > > cause this? > > Outdated information. The PGTK port of Emacs doesn't do anything close > to that, because GTK doesn't let us. I guess that is his bias or prejudice about Emacs. > > <ebassi> Calling exit is perfectly acceptable: the display connection is > > severed, and that can happen for multiple reasons, including the display > > server going away > > <ebassi> There's no "the display server is still running, but it closed > > the > > socket" mechanism for the toolkit to use > > So why not use exit, which lets the atexit handlers run? > > > <ebassi> The socket got closed > > <ebassi> The toolkit terminates > > <ebassi> Thaodan: It could happen because the client made an invalid > > request— Wayland mandates that the display server closes the connection > > in that case <ebassi> Or the display server decided to kill the client > > because it was unresponsive > > <Thaodan> Why should the toolkit/lib call exit isn't there any better > > mechanism to doing such a thing in glib or gtk for that matter? > > <Thaodan> It would be better to not need any hacks to prevent gtk from > > killing apps. > > <ebassi> Thaodan: There is no such mechanism > > <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, > > doesn't that break any other app that has state so safe too? like for > > example an office application that wants to safe it's data before going > > down. <ebassi> I already told you > > <ebassi> If the display connection is closed by the server, then there's > > no > > safe way to store the data > > Store the data that is in Emacs core?? How did these people learn to > write software? I don't know but with such ignorance I don't see why anyone wants to use GTK.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Mon, 08 Aug 2022 08:57:02 GMT) Full text and rfc822 format available.Message #101 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Bjoern Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Mon, 08 Aug 2022 11:56:19 +0300
Am Montag, 8. August 2022, 05:40:30 EEST schrieb Po Lu: > Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > > I did I had my hole session running, nothing else had that issue. > > I kept the GTK-Demo running nothing happened it ran just fine. > > Thanks. > > > After a few hours Emacs exited with the same behaviour as explained in the > > bug. > > Do you see the same if you run Emacs as something other a daemon? > > > I on the #gtk channel on what do and I got from ebassi that it is ok to > > just call _exit. > > He says it might be the client behaving wrong: > > <ebassi> Thaodan: It could happen because the client made an invalid > > request— Wayland mandates that the display server closes the connection > > in that case > We don't make raw Wayland requests anywhere, so it must be a bug in GTK. What could be the way that GTK is used or is emacs with pgtk 99% a run of the mill gtk app? > > <ebassi> And if you lose the socket then you' > > <ebassi> you'll have to find the new one and reconnect > > <ebassi> Thaodan: Only emacs does that > > <ebassi> Pretty much literally > > <Thaodan> "that"? > > <ebassi> "app may run longer or before the compositor starts" > > <ebassi> Because emacs is really a 1980s teletype app > > <Thaodan> What does that change? calling _exit is not a solution. > > <Thaodan> Lets assume the fault for this happening is emacs, what could > > cause this? > > Outdated information. The PGTK port of Emacs doesn't do anything close > to that, because GTK doesn't let us. > > > <ebassi> Calling exit is perfectly acceptable: the display connection is > > severed, and that can happen for multiple reasons, including the display > > server going away > > <ebassi> There's no "the display server is still running, but it closed > > the > > socket" mechanism for the toolkit to use > > So why not use exit, which lets the atexit handlers run? I don't know, can someone ask? I feel like these people act like douches when some random person asks. > > <ebassi> The socket got closed > > <ebassi> The toolkit terminates > > <ebassi> Thaodan: It could happen because the client made an invalid > > request— Wayland mandates that the display server closes the connection > > in that case <ebassi> Or the display server decided to kill the client > > because it was unresponsive > > <Thaodan> Why should the toolkit/lib call exit isn't there any better > > mechanism to doing such a thing in glib or gtk for that matter? > > <Thaodan> It would be better to not need any hacks to prevent gtk from > > killing apps. > > <ebassi> Thaodan: There is no such mechanism > > <Thaodan> ebassi: OK so what's the idea behind using _exit as a mechanism, > > doesn't that break any other app that has state so safe too? like for > > example an office application that wants to safe it's data before going > > down. <ebassi> I already told you > > <ebassi> If the display connection is closed by the server, then there's > > no > > safe way to store the data > > Store the data that is in Emacs core?? How did these people learn to > write software? I guess they did but learned that they are always right when there's an issue? Idk.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Mon, 08 Aug 2022 10:11:01 GMT) Full text and rfc822 format available.Message #104 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Bjoern Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Mon, 08 Aug 2022 18:10:36 +0800
Bjoern Bidar <bjorn.bidar <at> thaodan.de> writes: > What could be the way that GTK is used or is emacs with pgtk 99% a run of the > mill gtk app? Emacs isn't a run-of-the-mill GTK app, but we only use what the platform-independent parts of what the GTK developers expose. > I don't know, can someone ask? I feel like these people act like douches when > some random person asks. They behave that way no matter who asks, which is why most people have already given up trying to interact with them. Simple example: apparently, all the GTK developers have expensive monitors, so modern font rendering techniques that improve font rendering on Full-HD monitors have been deleted from GTK 4, and anyone who complains is given some ridiculous excuse along the lines of "expensive monitors are the future" and "subpixel font anti-aliasing is not adaptable to our rendering pipeline", even though multiple people have already proposed patches that demonstrate the opposite.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Thu, 17 Nov 2022 16:51:01 GMT) Full text and rfc822 format available.Message #107 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Gavin Massingham <gavmassingham <at> gmail.com> To: 56967 <at> debbugs.gnu.org Subject: 29.0.50; Frequent crashes under Wayland Date: Thu, 17 Nov 2022 16:02:22 +0000
I am also getting this frustrating bug, but *only*, it seems, if Emacs server is running as a Systemd unit. I have not, so far, experienced a crash if I launch the server in some other way.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Tue, 13 Dec 2022 12:11:02 GMT) Full text and rfc822 format available.Message #110 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Björn Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Tue, 13 Dec 2022 14:10:01 +0200
The issue got picked up on Mastodon recently: https://home.social/@ebassi <at> mastodon.social/109505829096414816 Someone reported a similar issue under X11 years earlier: https://bugzilla.gnome.org/show_bug.cgi?id=646338
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Tue, 13 Dec 2022 12:11:02 GMT) Full text and rfc822 format available.Message #113 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Björn Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Tue, 13 Dec 2022 14:10:33 +0200
The issue got picked up on Mastodon recently: https://home.social/@ebassi <at> mastodon.social/109505829096414816 Someone reported a similar issue under X11 years earlier: https://bugzilla.gnome.org/show_bug.cgi?id=646338
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Tue, 13 Dec 2022 13:13:02 GMT) Full text and rfc822 format available.Message #116 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Björn Bidar <bjorn.bidar <at> thaodan.de> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Tue, 13 Dec 2022 21:11:53 +0800
Björn Bidar <bjorn.bidar <at> thaodan.de> writes: > The issue got picked up on Mastodon recently: > https://home.social/@ebassi <at> mastodon.social/109505829096414816 That site doesn't work for me, could you please paste an excerpt here? > Someone reported a similar issue under X11 years earlier: > https://bugzilla.gnome.org/show_bug.cgi?id=646338 That applies only to the GDK X11 backend though, sadly. Thanks.
bug-gnu-emacs <at> gnu.org:bug#56967; Package emacs.
(Tue, 13 Dec 2022 17:07:01 GMT) Full text and rfc822 format available.Message #119 received at 56967 <at> debbugs.gnu.org (full text, mbox):
From: Björn Bidar <bjorn.bidar <at> thaodan.de> To: Po Lu <luangruo <at> yahoo.com> Cc: 56967 <at> debbugs.gnu.org Subject: Re: bug#56967: 29.0.50; Frequent crashes under Wayland Date: Tue, 13 Dec 2022 19:06:43 +0200
Po Lu <luangruo <at> yahoo.com> writes: > Björn Bidar <bjorn.bidar <at> thaodan.de> writes: > >> The issue got picked up on Mastodon recently: >> https://home.social/@ebassi <at> mastodon.social/109505829096414816 > > That site doesn't work for me, could you please paste an excerpt here? This is my mastodon.el dump that should at some context, I added the first post then my toot and Emanuel Ebassi's replies to me: START mastdon.el dump I do not like #Electron but I'm also not a fan of #Emacs. However, I appreciate the self-deprecating humor. https://cdn.fosstodon.org/media_attachments/files/109/501/742/682/624/996/original/749afb0111253dab.png Aaron Toponce ⚛️:debian: (@atoponce <at> fosstodon.org) 2022-12-12 18:59:04 @atoponce @sotolf I think you get used to lisp, the language works just different to other languages, after a time it's not as bad. What usually bothers me is Emacs being single threaded quite often or using outdated technologies such as #xembed which is now used to embedded #webkit. The most annoying issue thou is #GTK doing funny stuff. Like for example if you loose your display manager connection on #Wayland then GTK just kills your application with _exit(). Björn (@thaodan) 2022-12-13 10:08:16 via Web ------------ @thaodan @atoponce @sotolf Terminating on display connection loss is recommended by the Wayland protocol, because Wayland is not UDP: events don't get resent, and if the compositor and the client don't agree on their state, you'll just going to crash later on. You could do an orderly display connection drop while keeping the process alive, but a) only Emacs even attempts this on X11 or Wayland; and b) it's not tested in toolkits because it's only needed by Emacs Emmanuele Bassi (@ebassi <at> mastodon.social) 2022-12-13 12:12:26 ------------ @ebassi @atoponce @sotolf Never argued against closing the display connection but using _ exit() instead of exit() to make sure the program can not react is bad at best or at worst malicious. This issue not only affects #Emacs but any program that wants to react on loosing the display connection. Björn (@thaodan) 2022-12-13 13:32:46 ------------ @thaodan @atoponce @sotolf GTK only uses `_exit()` on remote display close. It's kind of intentional: if the *server* terminates the connection, then there's nothing to recover from an application side. An application can only recover if it's the one that initiated the closing of the display connection. Emmanuele Bassi (@ebassi <at> mastodon.social) 2022-12-13 13:39:09 ------------ @ebassi @atoponce @sotolf So you decide for the application itself instead of letting the application decide to what to do on `exit()`? You say there's nothing to recover the applications opinion might be different. Björn (@thaodan) 2022-12-13 13:42:32 ------------ @thaodan @atoponce @sotolf You cannot safely/reliably/portably do something after server-side disconnection. We've been there with X11 first, and the same applies with Wayland: https://bugzilla.gnome.org/show_bug.cgi?id=646338 Emmanuele Bassi (@ebassi <at> mastodon.social) 2022-12-13 13:50:19 ✍ 2022-12-13 17:22:14 ------------ @atoponce @sotolf For reference the #Debuggs entry for this: https://lists.gnu.org/r/bug-gnu-emacs/2022-08/msg00305.html Björn (@thaodan) 2022-12-13 13:45:57 ------------ END mastodon.el dump >> Someone reported a similar issue under X11 years earlier: >> https://bugzilla.gnome.org/show_bug.cgi?id=646338 > > That applies only to the GDK X11 backend though, sadly. Worth to send a patch on this? I think it might be wort to talk other GTk developers, e.g. the one that has done the change. Br, Björn
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.