Subject: bug#27210: closed (Re: bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 04 Jun 2017 16:32:04 +0000

Your bug report

#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
27210: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27210
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on
From: Eli Zaretskii <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sun, 04 Jun 2017 19:31:34 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: [email-masked]
> Cc: [email-masked],  [email-masked]
> Date: Sun, 04 Jun 2017 11:08:59 -0400
> 
> Eli Zaretskii <[email-masked]> 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.

Subject: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on
From: Pierre Neidhardt <[email-masked]>
To: [email-masked]
Date: Sat, 3 Jun 2017 15:29:11 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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.