--- Begin Message ---
|
Subject: |
25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on |
|
Date: |
Sat, 3 Jun 2017 15:29:11 +0100 |
|
User-agent: |
Mutt/1.8.3 (2017-05-23) |
With the following init file:
(desktop-save-mode 1)
(global-linum-mode)
I visit "/usr/share/emacs/25.2/lisp/loaddefs.el" and everything is fine.
I save the desktop session with `desktop-save-in-desktop-dir' and kill
Emacs.
On next start, this displays in the terminal
Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
Emacs might crash when run in daemon mode and the X11 connection is
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have
this problem.
Note: file is write protected
and Emacs hangs for minutes at least, possibly forever, becoming a CPU hog. I
then have to kill Emacs.
The corresponding buffer entry in .emacs.desktop is the following:
;; Buffer section -- buffers listed in same order as in buffer list:
(desktop-create-buffer 208
"/usr/share/emacs/25.2/lisp/loaddefs.el"
"loaddefs.el"
'emacs-lisp-mode
'(linum-mode)
1
'(nil nil)
t
nil
'((buffer-file-coding-system . utf-8-unix))
'((mark-ring nil)))
If I remove the entry or if I disable linum-mode by commenting the corresponding
line in the init file, Emacs can start properly.
In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.10)
of 2017-04-22 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description: Arch Linux
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Load-path shadows:
None found.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on |
|
Date: |
Sun, 04 Jun 2017 19:31:34 +0300 |
> From: address@hidden
> Cc: address@hidden, address@hidden
> Date: Sun, 04 Jun 2017 11:08:59 -0400
>
> Eli Zaretskii <address@hidden> writes:
>
> > And don't forget that the initial frame is invisible in non-daemon
> > sessions as well, until some point during startup.
>
> I don't understand, is this an objection?
Sorry for being unclear: I meant to point out that a non-daemon
startup initially has such a frame as well, and we never heard any
complaints about that. Which might mean that some of the code
routinely run during startup expects to find that frame marked
visible.
> > My alternative proposal is much simpler, is localized to linum.el, and
> > in a nutshell tests exactly the same condition, since any frame in a
> > daemon session that can be visible is by definition a client frame.
> > Do you see any disadvantages with installing that instead?
>
> The only disadvantage is that we still have this invisible daemon frame
> which is marked as visible. I agree it's okay to apply your patch now
> and see if we get some other similar problems later.
OK, I've pushed the change. Let's keep an eye on similar problems if
they pop up.
--- End Message ---