GNU bug report logs - #24298
25.1; problem with restoring desktop

Previous Next

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

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

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

From: John Covici <covici <at> ccs.covici.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 07:31:03 -0400

I am having a problem restoring my desktop, when there are several
buffers.  Instead of restoring the correct buffer as the current one, a
random buffer is restored.

Here is my .emacs file if that would help.

;; Added by Package.el.  This must come before configurations of
;; installed packages.  Don't delete this line.  If you don't want it,
;; just comment it out by adding a semicolon to the start of the line.
;; You may delete these explanatory comments.
(require 'package)
(add-to-list 'package-archives
		   '("melpa" . "http://melpa.org/packages/")
		   (when (< emacs-major-version 24)
			;; For important compatibility libraries like cl-lib
			  (add-to-list 'package-archives '("gnu" . "http://elpa.gnu.org/packages/"))))
(package-initialize)

(setq  gnus-inhibit-startup-message t        )

(setq default-major-mode 'text-mode)
(load "bookmark")
(load "saveplace")
(setq history-length t)

(add-hook'c-mode-common-hook 
 (function(lambda()
(c-toggle-auto-state 1))))
;   (autoload 'csharp-mode "csharp-mode" "Major mode for editing C# code." t)
;   (setq auto-mode-alist
;      (append '(("\\.cs$" . csharp-mode)) auto-mode-alist))
;   (setq auto-mode-alist
;      (append '(("\\.cs$" . csharp-mode)) auto-mode-alist))


(add-hook 'text-mode-hook 'turn-on-auto-fill)
(global-set-key [f1] 'help-command)
(global-set-key "\C-s" 'nonincremental-re-search-forward)
(global-set-key "\C-r" 'nonincremental-re-search-backward)
(global-set-key [f6] 'nonincremental-repeat-search-forward)
(global-set-key [f7] 'nonincremental-repeat-search-backward)
(global-set-key [f8] 'replace-regexp)
(global-set-key [f9] 'repeat-matching-complex-command)
(global-set-key [home] 'beginning-of-line)
(global-set-key [end] 'end-of-line)
(column-number-mode 1)

;(autoload 'perl-mode "cperl-mode" "alternate mode for editing Perl programs" t)
(add-hook'cperl-mode-hook
 (function(lambda()
(setq cperl-hairy t)
(setq cperl-extra-newline-before-brace 1)
(setq cperl-auto-newline 1)
(setq cperl-auto-newline-after-colon 1)
(setq cperl-indent-level 4)
(setq cperl-electric-parens-string nil)
(setq cperl-continued-statement-offset 0)

)))

;; Add signature at the end of the email.
(add-hook 'mh-letter-mode-hook
       '(lambda () (save-excursion
               (goto-char (point-max))
               (mh-insert-signature))))
(setq-default next-line-add-newlines nil)
(setq font-running-xemacs nil)
;          (defun turn-off-backup ()
;            (set (make-local-variable 'version-control) 2))
          
;(add-hook 'nnfolder-save-buffer-hook (lambda () (turn-off-backup)))
(setq next-screen-context-lines 0)
(setq inhibit-startup-message t)
(menu-bar-mode -1); turn off those ------- menus
(setq browse-url-lynx-input-attempts 1)
(setq browse-url-lynx-emacs-args "-showcursor")
(defun browse-url-lynx-emacs (url &optional new-buffer)
  "Ask the Lynx WWW browser to load URL.
Default to the URL around or before point.  With a prefix argument, run
a new Lynx process in a new buffer.

When called interactively, if variable `browse-url-new-window-flag' is
non-nil, load the document in a new lynx in a new term window,
otherwise use any existing one.  A non-nil interactive prefix argument
reverses the effect of `browse-url-new-window-flag'.

When called non-interactively, optional second argument NEW-WINDOW is
used instead of `browse-url-new-window-flag'."
  (interactive (browse-url-interactive-arg "Lynx URL: "))
  (let* ((system-uses-terminfo t)       ; Lynx uses terminfo
	 ;; (term-term-name "vt100") ; ??
	 (buf (get-buffer "*lynx*"))
	 (proc (and buf (get-buffer-process buf)))
	 (n browse-url-lynx-input-attempts))
    (if (and (browse-url-maybe-new-window new-buffer) buf)
	;; Rename away the OLD buffer. This isn't very polite, but
	;; term insists on working in a buffer named *lynx* and would
	;; choke on *lynx*<1>
	(progn (set-buffer buf)
	       (rename-uniquely)))
    (if (or (browse-url-maybe-new-window new-buffer)
	    (not buf)
	    (not proc)
	    (not (memq (process-status proc) '(run stop))))
	;; start a new lynx
	(progn
          (setq buf
                (apply #'make-term
                       `("lynx" "lynx" nil ,@browse-url-lynx-emacs-args
			 ,url)))
          (switch-to-buffer buf)
          (term-char-mode)
          (set-process-sentinel
           (get-buffer-process buf)
           ;; Don't leave around a dead one (especially because of its
           ;; munged keymap.)
           (lambda (process event)
             (if (not (memq (process-status process) '(run stop)))
                 (let ((buf (process-buffer process)))
                   (if buf (kill-buffer buf)))))))
      ;; send the url to lynx in the old buffer
      (let ((win (get-buffer-window buf t)))
	(if win
	    (select-window win)
	  (switch-to-buffer buf)))
      (if (eq (following-char) ?_)
	  (cond ((eq browse-url-lynx-input-field 'warn)
		 (error "Please move out of the input field first"))
		((eq browse-url-lynx-input-field 'avoid)
		 (while (and (eq (following-char) ?_) (> n 0))
		   (term-send-down) ; down arrow
		   (sit-for browse-url-lynx-input-delay))
		 (if (eq (following-char) ?_)
		     (error "Cannot move out of the input field, sorry")))))
      (term-send-string proc (concat "g" ; goto
				     "\C-u" ; kill default url
				     url
				     "\r")))))

(defun forward-word-to-nonblank ()
"forwards past the blank space where forward-word normally lands"
(interactive)
(forward-word 2)
(forward-word -1)
)
(global-set-key [\C-right] 'forward-word-to-nonblank)
(global-set-key [\M-right] 'forward-word-to-nonblank)
(global-set-key "\M-f" 'forward-word-to-nonblank)
 
(defun  eir-fix-articles () 
"function to replaceeir articles with correct versions and do cleanup"
(setq ignore-auto 1)
(setq noconfirm 1)
(setq preserve-modes 1)
(shell-command "ls *.TXT >temp.sc")
(shell-command "chmod u+x temp.sc")
(find-file "temp.sc")
(goto-char (point-min))
  (while (re-search-forward "^.*$" nil t)
    (replace-match "\\& \\&" nil nil))
(goto-char (point-min))
  (while (re-search-forward " EIR...\$*" nil t)
    (replace-match " " nil nil))
(goto-char (point-min))
  (while (re-search-forward "\\$" nil t)
    (replace-match "\\\\$" nil nil))
(goto-char (point-min))
  (while (re-search-forward "^" nil t)
    (replace-match "mv " nil nil))
(beginning-of-line)
(kill-line)
(save-buffer)
(shell-command "./temp.sc")
(when (file-exists-p "CON.TXT")
(rename-file "CON.TXT" "CONX.TXT"))
(shell-command "ls *.TXT >temp.sc")
(revert-buffer ignore-auto noconfirm preserve-modes)
(goto-char (point-min))
  (while (re-search-forward "^" nil t)
    (replace-match "miles2 " nil nil))
(beginning-of-line)
(kill-line)
(save-buffer)
(shell-command "./temp.sc")
(shell-command "ls -1 -F -a .. >temp.sc")
(revert-buffer ignore-auto noconfirm preserve-modes)
(goto-char (point-min))
(re-search-forward "txt/" nil t)
(beginning-of-line)
(kill-line)
(kill-line)
(goto-char (point-min))
(kill-line)
(kill-line)
(kill-line)
(kill-line)
  (while (re-search-forward "\*" nil t)
    (replace-match "" nil nil))
(goto-char (point-min))
  (while (re-search-forward "^.*$" nil t)
    (replace-match "\\& \\&" nil nil))
(goto-char (point-min))
  (while (re-search-forward "\\..* " nil t)
    (replace-match ".art ../" nil nil))
(goto-char (point-min))
  (while (re-search-forward "^" nil t)
    (replace-match "mv " nil nil))
(beginning-of-line)
(kill-line)
(save-buffer)
)
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(browse-url-browser-function (quote browse-url-lynx-emacs))
 '(browse-url-lynx-emacs-args nil t)
 '(browse-url-lynx-input-field nil)
 '(canlock-password "5de3542f3d08b117db60777f7b3f934ff0248a72")
 '(delete-old-versions t)
 '(desktop-missing-file-warning nil)
 '(desktop-path (quote (".")))
 '(desktop-save t)
 '(desktop-save-mode t nil (desktop))
 '(dired-kept-versions 1)
 '(dired-recursive-copies (quote always))
 '(dired-recursive-deletes (quote always))
 '(doc-view-conversion-refresh-interval 0)
 '(doc-view-odf->pdf-converter-program "odt2txt")
 '(doc-view-pdftotext-program "pdftotext")
 '(doc-view-unoconv-program "odt2txt")
 '(elmo-imap4-default-port 993)
 '(elmo-imap4-default-server "ccs.covici.com")
 '(elmo-imap4-default-stream-type (quote ssl))
 '(elmo-message-fetch-confirm t)
 '(elmo-message-fetch-threshold 900000)
 '(epa-pinentry-mode (quote loopback))
 '(erc-log-channels-directory "~/irclog")
 '(erc-log-mode t)
 '(erc-log-write-after-insert t)
 '(erc-log-write-after-send t)
 '(erc-nick "covici")
 '(kept-new-versions 5)
 '(kept-old-versions 0)
 '(large-file-warning-threshold 93000000)
 '(line-number-display-limit 100000000)
 '(mail-archive-file-name "copy_of_outgoing.txt")
 '(mail-default-headers nil)
 '(mail-default-reply-to "covici <at> ccs.covici.com")
 '(mail-host-address nil)
 '(mail-send-nonascii nil)
 '(mail-signature t)
 '(mail-use-rfc822 t)
 '(mail-user-agent (quote message-user-agent))
 '(mail-yank-ignored-headers
   "^via:\\|^mail-from:\\|^origin:\\|^status:\\|^remailed\\|^received:\\|^message-id:\\|^summary-line:\\|^in-reply-to:\\|^return-path:")
 '(mail-yank-prefix ">")
 '(mh-compose-space-does-completion-flag t)
 '(mh-delete-yanked-msg-window-flag t)
 '(mh-display-buttons-for-alternatives-flag t)
 '(mh-forward-subject-format "%s: %s (fwd)")
 '(mh-identity-default nil)
 '(mh-identity-list (quote (("covici" ((":pgg-default-user-id" . "covici"))))))
 '(mh-inc-spool-list nil)
 '(mh-invisible-header-fields (quote ("Organization" "Sender" "User-agent" "X-")))
 '(mh-reply-default-reply-to "all")
 '(mh-yank-behavior (quote autoattrib))
 '(mime-display-text/plain-flowed-fill-column 65)
 '(mime-edit-split-message nil)
 '(mime-edit-translate-hook (quote (mime-edit-insert-signature)))
 '(mime-pgp-decrypt-when-preview t)
 '(mime-view-text/html-previewer (quote shr))
 '(next-line-add-newlines nil)
 '(package-selected-packages (quote (wanderlust)))
 '(pgg-query-keyserver t)
 '(save-place-limit nil)
 '(save-place-mode t)
 '(save-place-version-control (quote nospecial))
 '(scroll-down-aggressively nil)
 '(scroll-up-aggressively nil)
 '(send-mail-function nil)
 '(split-width-threshold nil)
 '(tab-width 5)
 '(track-eol t)
 '(undo-ask-before-discard nil)
 '(undo-limit 30000)
 '(undo-outer-limit 4000000)
 '(undo-strong-limit 40000)
 '(url-automatic-caching t)
 '(url-keep-history t)
 '(url-news-server "news.patriot.net")
 '(url-personal-mail-address "covici <at> ccs.covici.com")
 '(url-privacy-level (quote none))
 '(user-full-name "John Covici")
 '(version-control t)
 '(w3-maximum-line-length 80)
 '(wl-alias-file "~/Mail/aliases")
 '(wl-auto-save-drafts-interval 30)
 '(wl-demo nil)
 '(wl-demo-display-logo nil)
 '(wl-draft-always-delete-myself t)
 '(wl-draft-folder "+drafts")
 '(wl-draft-preview-process-pgp t)
 '(wl-draft-send-mail-function (quote wl-draft-send-mail-with-sendmail))
 '(wl-fcc "+Sent Items")
 '(wl-folder-move-cur-folder t)
 '(wl-interactive-send nil)
 '(wl-message-ignored-field-list (quote ("^.*$")))
 '(wl-message-visible-field-list
   (quote
    ("^To:" "^Subject:" "^Date:" "^Reply" "^From:" "^Cc:")))
 '(wl-nntp-posting-port nil)
 '(wl-nntp-posting-server "news-central.giganews.com")
 '(wl-nntp-posting-user "gn71330")
 '(wl-organization "Covici Computer Systems")
 '(wl-smtp-authenticate-type "login")
 '(wl-smtp-connection-type (quote starttls))
 '(wl-smtp-posting-port 587)
 '(wl-smtp-posting-server "ccs.covici.com")
 '(wl-smtp-posting-user "covici")
 '(wl-summary-width nil)
 '(wl-temporary-file-directory "/audio/tmp/")
 '(wl-trash-folder "+Deleted Items"))

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )




(add-hook 'w3-mode-hook (lambda () (setq truncate-lines nil)))
;;; Emacs-w3 configuration options
(autoload 'w3-preview-this-buffer "w3" "WWW Previewer" t)
(autoload 'w3-follow-url-at-point "w3" "Find document at pt" t)
(autoload 'w3 "w3" "WWW Browser" t)
(autoload 'w3-open-local "w3" "Open local file for WWW browsing" t)
(autoload 'w3-fetch "w3" "Open remote file for WWW browsing" t)
(autoload 'w3-use-hotlist "w3" "Use shortcuts to view WWW docs" t)
(autoload 'w3-show-hotlist "w3" "Use shortcuts to view WWW docs" t)
(autoload 'w3-follow-link "w3" "Follow a hypertext link." t)
(autoload 'w3-batch-fetch "w3" "Batch retrieval of URLs" t)
(autoload 'url-get-url-at-point "url" "Find the url under the cursor" nil)
(autoload 'url-file-attributes  "url" "File attributes of a URL" nil)
(autoload 'url-popup-info "url" "Get info on a URL" t)
(autoload 'url-retrieve   "url" "Retrieve a URL" nil)
(autoload 'url-buffer-visiting "url" "Find buffer visiting a URL." nil)
(autoload 'gopher-dispatch-object "gopher" "Fetch gopher dir" t)
;;; End of Emacs-w3 configuration options
;;; Emacs-w3 configuration options
(autoload 'w3-preview-this-buffer "w3" "WWW Previewer" t)
(autoload 'w3-follow-url-at-point "w3" "Find document at pt" t)
(autoload 'w3 "w3" "WWW Browser" t)
(autoload 'w3-open-local "w3" "Open local file for WWW browsing" t)
(autoload 'w3-fetch "w3" "Open remote file for WWW browsing" t)
(autoload 'w3-use-hotlist "w3" "Use shortcuts to view WWW docs" t)
(autoload 'w3-show-hotlist "w3" "Use shortcuts to view WWW docs" t)
(autoload 'w3-follow-link "w3" "Follow a hypertext link." t)
(autoload 'w3-batch-fetch "w3" "Batch retrieval of URLs" t)
(autoload 'url-get-url-at-point "url" "Find the url under the cursor" nil)
(autoload 'url-file-attributes  "url" "File attributes of a URL" nil)
(autoload 'url-popup-info "url" "Get info on a URL" t)
(autoload 'url-retrieve   "url" "Retrieve a URL" nil)
(autoload 'url-buffer-visiting "url" "Find buffer visiting a URL." nil)
(autoload 'gopher-dispatch-object "gopher" "Fetch gopher dir" t)
;;; End of Emacs-w3 configuration options

;;; Emacs/W3 Configuration
(setq load-path (cons "/usr/share/emacs/site-lisp" load-path))
(condition-case () (require 'w3-auto "w3-auto") (error nil))

(put 'upcase-region 'disabled nil)
   (autoload 'vm "vm" "Start VM on your primary inbox." t)
   (autoload 'vm-visit-folder "vm" "Start VM on an arbitrary folder." t)
   (autoload 'vm-visit-virtual-folder "vm" "Visit a VM virtual folder." t)
   (autoload 'vm-mode "vm" "Run VM major mode on a buffer" t)
   (autoload 'vm-mail "vm" "Send a mail message using VM." t)
   (autoload 'vm-submit-bug-report "vm" "Send a bug report about VM." t)

---- .emacs ends here -----




In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.20.8)
 of 2016-08-23 built on ccs.covici.com
System Description:	Gentoo Base System release 2.2

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-dependency-tracking
 --disable-silent-rules --docdir=/usr/share/doc/emacs-25.1_rc2
 --htmldir=/usr/share/doc/emacs-25.1_rc2/html --libdir=/usr/lib64
 --program-suffix=-emacs-25 --infodir=/usr/share/info/emacs-25
 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-gameuser=:gamestat --without-compress-install
 --with-file-notification=inotify --enable-acl --with-dbus --with-gpm
 --without-hesiod --without-kerberos --without-kerberos5 --with-xml2
 --without-selinux --with-gnutls --without-wide-int --with-zlib
 --with-sound=alsa --with-x --without-ns --without-gconf
 --without-gsettings --without-toolkit-scroll-bars --with-gif
 --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
 --without-imagemagick --without-xft --without-cairo --without-libotf
 --without-m17n-flt --with-x-toolkit=gtk3 --without-xwidgets
 GENTOO_PACKAGE=app-editors/emacs-25.1_rc2 'CFLAGS=-O2 -mtune=core2
 -pipe -ggdb' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  desktop-save-mode: t
  save-place-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading bookmark...done
Loading saveplace...done
Loading desktop...done
Wrote /home/covici/.emacs.desktop.lock
Desktop: 1 frame, 1 buffer restored.
For information about GNU Emacs and the GNU system, type C-h C-a.
Type C-x 1 to delete the help window.

Load-path shadows:
/home/covici/.emacs.d/elpa/flim-20160311.1537/hex-util hides /usr/share/emacs/25.1/lisp/hex-util
/home/covici/.emacs.d/elpa/flim-20160311.1537/md4 hides /usr/share/emacs/25.1/lisp/md4
/home/covici/.emacs.d/elpa/flim-20160311.1537/ntlm hides /usr/share/emacs/25.1/lisp/net/ntlm
/home/covici/.emacs.d/elpa/flim-20160311.1537/hmac-def hides /usr/share/emacs/25.1/lisp/net/hmac-def
/home/covici/.emacs.d/elpa/flim-20160311.1537/sasl-digest hides /usr/share/emacs/25.1/lisp/net/sasl-digest
/home/covici/.emacs.d/elpa/flim-20160311.1537/sasl-ntlm hides /usr/share/emacs/25.1/lisp/net/sasl-ntlm
/home/covici/.emacs.d/elpa/flim-20160311.1537/sasl hides /usr/share/emacs/25.1/lisp/net/sasl
/home/covici/.emacs.d/elpa/flim-20160311.1537/sasl-cram hides /usr/share/emacs/25.1/lisp/net/sasl-cram
/home/covici/.emacs.d/elpa/flim-20160311.1537/hmac-md5 hides /usr/share/emacs/25.1/lisp/net/hmac-md5
/usr/share/emacs/site-lisp/mh-e/mh-compat hides /usr/share/emacs/25.1/lisp/mh-e/mh-compat
/usr/share/emacs/site-lisp/mh-e/mh-e hides /usr/share/emacs/25.1/lisp/mh-e/mh-e
/usr/share/emacs/site-lisp/mh-e/mh-xface hides /usr/share/emacs/25.1/lisp/mh-e/mh-xface
/usr/share/emacs/site-lisp/mh-e/mh-seq hides /usr/share/emacs/25.1/lisp/mh-e/mh-seq
/usr/share/emacs/site-lisp/mh-e/mh-utils hides /usr/share/emacs/25.1/lisp/mh-e/mh-utils
/usr/share/emacs/site-lisp/mh-e/mh-search hides /usr/share/emacs/25.1/lisp/mh-e/mh-search
/usr/share/emacs/site-lisp/mh-e/mh-scan hides /usr/share/emacs/25.1/lisp/mh-e/mh-scan
/usr/share/emacs/site-lisp/mh-e/mh-funcs hides /usr/share/emacs/25.1/lisp/mh-e/mh-funcs
/usr/share/emacs/site-lisp/mh-e/mh-show hides /usr/share/emacs/25.1/lisp/mh-e/mh-show
/usr/share/emacs/site-lisp/mh-e/mh-limit hides /usr/share/emacs/25.1/lisp/mh-e/mh-limit
/usr/share/emacs/site-lisp/mh-e/mh-tool-bar hides /usr/share/emacs/25.1/lisp/mh-e/mh-tool-bar
/usr/share/emacs/site-lisp/mh-e/mh-speed hides /usr/share/emacs/25.1/lisp/mh-e/mh-speed
/usr/share/emacs/site-lisp/mh-e/mh-print hides /usr/share/emacs/25.1/lisp/mh-e/mh-print
/usr/share/emacs/site-lisp/mh-e/mh-junk hides /usr/share/emacs/25.1/lisp/mh-e/mh-junk
/usr/share/emacs/site-lisp/mh-e/mh-mime hides /usr/share/emacs/25.1/lisp/mh-e/mh-mime
/usr/share/emacs/site-lisp/mh-e/mh-thread hides /usr/share/emacs/25.1/lisp/mh-e/mh-thread
/usr/share/emacs/site-lisp/mh-e/mh-acros hides /usr/share/emacs/25.1/lisp/mh-e/mh-acros
/usr/share/emacs/site-lisp/mh-e/mh-letter hides /usr/share/emacs/25.1/lisp/mh-e/mh-letter
/usr/share/emacs/site-lisp/mh-e/mh-alias hides /usr/share/emacs/25.1/lisp/mh-e/mh-alias
/usr/share/emacs/site-lisp/mh-e/mh-inc hides /usr/share/emacs/25.1/lisp/mh-e/mh-inc
/usr/share/emacs/site-lisp/mh-e/mh-identity hides /usr/share/emacs/25.1/lisp/mh-e/mh-identity
/usr/share/emacs/site-lisp/mh-e/mh-folder hides /usr/share/emacs/25.1/lisp/mh-e/mh-folder
/usr/share/emacs/site-lisp/mh-e/mh-buffers hides /usr/share/emacs/25.1/lisp/mh-e/mh-buffers
/usr/share/emacs/site-lisp/mh-e/mh-gnus hides /usr/share/emacs/25.1/lisp/mh-e/mh-gnus
/usr/share/emacs/site-lisp/mh-e/mh-loaddefs hides /usr/share/emacs/25.1/lisp/mh-e/mh-loaddefs
/usr/share/emacs/site-lisp/mh-e/mh-comp hides /usr/share/emacs/25.1/lisp/mh-e/mh-comp

Features:
(shadow sort mail-extr warnings emacsbug message dired rfc822 mml
mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums thingatpt
term/xterm xterm eww mm-url gnus gnus-ems nnheader mail-utils wid-edit
url-queue url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio
eieio-core cl-macs gnus-util time-date mm-util help-fns mail-prsvr
password-cache url-vars mailcap shr dom subr-x browse-url format-spec
desktop frameset cus-start cus-load saveplace bookmark pp finder-inf
info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv site-gentoo edmacro kmacro cl-loaddefs pcase
cl-lib imenu mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 199073 6176)
 (symbols 48 29257 0)
 (miscs 40 51 138)
 (strings 32 47311 6660)
 (string-bytes 1 1248933)
 (vectors 16 19828)
 (vector-slots 8 513662 3906)
 (floats 8 271 242)
 (intervals 56 411 136)
 (buffers 976 23)
 (heap 1024 21938 1143))

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 17:23:52 +0300

> From: John Covici <covici <at> ccs.covici.com>
> Date: Wed, 24 Aug 2016 07:31:03 -0400
> 
> I am having a problem restoring my desktop, when there are several
> buffers.  Instead of restoring the correct buffer as the current one, a
> random buffer is restored.

I use desktop.el for a long time, and never had any such problems: I
always get the buffer that was current when I shut down Emacs.

> Here is my .emacs file if that would help.

Hard to analyze such a large file.  One difference from what I have is
that my ~/.emacs has this single line

  (desktop-save-mode 1)

near the very end of the file, whereas you activate desktop-save-mode
via Customize, and it's not the last thing done in the init file.  So
maybe what comes after the activation of desktop-save-mode causes the
problem?

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 10:53:21 -0400

Now one other bit of information.  If I go back to the following
commit it works correctly
c97cd6c005e138856d99ecef86fa04674c34b779
whereas it is broke on latest git or the rc-2.

Maybe I could do a git bisect, but its very time consuming.

On Wed, 24 Aug 2016 10:23:52 -0400,
Eli Zaretskii wrote:
> 
> > From: John Covici <covici <at> ccs.covici.com>
> > Date: Wed, 24 Aug 2016 07:31:03 -0400
> > 
> > I am having a problem restoring my desktop, when there are several
> > buffers.  Instead of restoring the correct buffer as the current one, a
> > random buffer is restored.
> 
> I use desktop.el for a long time, and never had any such problems: I
> always get the buffer that was current when I shut down Emacs.
> 
> > Here is my .emacs file if that would help.
> 
> Hard to analyze such a large file.  One difference from what I have is
> that my ~/.emacs has this single line
> 
>   (desktop-save-mode 1)
> 
> near the very end of the file, whereas you activate desktop-save-mode
> via Customize, and it's not the last thing done in the init file.  So
> maybe what comes after the activation of desktop-save-mode causes the
> problem?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 18:11:06 +0300

> Date: Wed, 24 Aug 2016 10:53:21 -0400
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> Now one other bit of information.  If I go back to the following
> commit it works correctly
> c97cd6c005e138856d99ecef86fa04674c34b779
> whereas it is broke on latest git or the rc-2.

How do you mean "go back"?  The commit you show was on master, whereas
the version of Emacs reported with your bug report was 25.1, i.e. the
RC, which was tarred from the emacs-25 branch.  And when you say
"latest git", which branch is that?

FWIW, I see no such problems in RC2, either.

Strange.

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

From: martin rudalics <rudalics <at> gmx.at>
To: covici <at> ccs.covici.com, 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 17:46:02 +0200

> I am having a problem restoring my desktop, when there are several
> buffers.  Instead of restoring the correct buffer as the current one, a
> random buffer is restored.

What happens when you set ‘desktop-restore-frames’ to nil?

Apparently, restoring the buffer order with framesets seems to be a
problem, see also bug#15382 and bug#23630.  Sadly, not much has been
done in this area since Juanma disappeared ...

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24298 <at> debbugs.gnu.org, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 19:02:12 +0300

> Date: Wed, 24 Aug 2016 17:46:02 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > I am having a problem restoring my desktop, when there are several
>  > buffers.  Instead of restoring the correct buffer as the current one, a
>  > random buffer is restored.
> 
> What happens when you set ‘desktop-restore-frames’ to nil?

FWIW, the stuff works for me reliably without changing the defaulot
value of that variable.

> Apparently, restoring the buffer order with framesets seems to be a
> problem, see also bug#15382 and bug#23630.

Doesn't happen here, FWIW.

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

From: nljlistbox2 <at> gmail.com (N. Jackson)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 17:57:09 -0300

At 19:02 +0300 on Wednesday 2016-08-24, Eli Zaretskii wrote:

>> Date: Wed, 24 Aug 2016 17:46:02 +0200
>> From: martin rudalics <rudalics <at> gmx.at>
>> 
>>  > I am having a problem restoring my desktop, when there are several
>>  > buffers.  Instead of restoring the correct buffer as the current one, a
>>  > random buffer is restored.
>> 
>> What happens when you set ‘desktop-restore-frames’ to nil?
>
> FWIW, the stuff works for me reliably without changing the defaulot
> value of that variable.

FWIW, I too have recently been bothered by my windows being populated by
random buffers when I start Emacs (instead of the ones I had when I last
closed Emacs).

I typically have three frames with one window in each.

I might say (half jokingly) that I quite like this new "feature": I
get buffers popping up that I was working on six months ago and forgot
all about! Starting Emacs now is always surprising. :)

N.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 21:32:48 -0400

hmmm, maybe I am using master after all, but my emacs-version says
"25.1.50.1" but my gentoo ebuild looks like its branch is master.  The
problem appears in both branches, however.  Very strange indeed.  I
will try to figure out what broke and update later.

On Wed, 24 Aug 2016 11:11:06 -0400,
Eli Zaretskii wrote:
> 
> > Date: Wed, 24 Aug 2016 10:53:21 -0400
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: 24298 <at> debbugs.gnu.org
> > 
> > Now one other bit of information.  If I go back to the following
> > commit it works correctly
> > c97cd6c005e138856d99ecef86fa04674c34b779
> > whereas it is broke on latest git or the rc-2.
> 
> How do you mean "go back"?  The commit you show was on master, whereas
> the version of Emacs reported with your bug report was 25.1, i.e. the
> RC, which was tarred from the emacs-25 branch.  And when you say
> "latest git", which branch is that?
> 
> FWIW, I see no such problems in RC2, either.
> 
> Strange.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: John Covici <covici <at> ccs.covici.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Wed, 24 Aug 2016 21:33:54 -0400

I am using a text console, would that change what you are saying?

On Wed, 24 Aug 2016 11:46:02 -0400,
martin rudalics wrote:
> 
> > I am having a problem restoring my desktop, when there are several
> > buffers.  Instead of restoring the correct buffer as the current one, a
> > random buffer is restored.
> 
> What happens when you set ‘desktop-restore-frames’ to nil?
> 
> Apparently, restoring the buffer order with framesets seems to be a
> problem, see also bug#15382 and bug#23630.  Sadly, not much has been
> done in this area since Juanma disappeared ...
> 
> martin
> 
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 11:16:42 +0200

>> What happens when you set ‘desktop-restore-frames’ to nil?
>
> FWIW, the stuff works for me reliably without changing the defaulot
> value of that variable.
>
>> Apparently, restoring the buffer order with framesets seems to be a
>> problem, see also bug#15382 and bug#23630.
>
> Doesn't happen here, FWIW.

Which seems to indicate that some other issue plays a role here.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: "N. Jackson" <nljlistbox2 <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 11:16:52 +0200

> I might say (half jokingly) that I quite like this new "feature": I
> get buffers popping up that I was working on six months ago and forgot
> all about!

At least this part seems hardly related to framesets.  It might be
related to your desktop file settings.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 11:17:04 +0200

> I am using a text console, would that change what you are saying?

I don't think so.  IIUC framesets should apply everywhere.

martin

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

From: John Covici <covici <at> ccs.covici.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 06:56:00 -0400

On Thu, 25 Aug 2016 05:17:04 -0400,
martin rudalics wrote:
> 
> > I am using a text console, would that change what you are saying?
> 
> I don't think so.  IIUC framesets should apply everywhere.

How would you have more than one frame on a text console, or is there
another meaning to framesets?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: martin rudalics <rudalics <at> gmx.at>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 14:27:53 +0200

> How would you have more than one frame on a text console,

(progn
  (make-frame)
  (frame-list))

> or is there
> another meaning to framesets?

Even if there is one and only one frame to restore, the use of framesets
might clobber the current buffer and/or the buffer list.

martin

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

From: nljlistbox2 <at> gmail.com (N. Jackson)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24298 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 10:09:50 -0300

At 11:16 +0200 on Thursday 2016-08-25, martin rudalics wrote:

>> I might say (half jokingly) that I quite like this new "feature": I
>> get buffers popping up that I was working on six months ago and forgot
>> all about!
>
> At least this part seems hardly related to framesets.  It might be
> related to your desktop file settings.

Hi Martin,

At the risk of further noise but to be sure that I haven't muddied the
waters with my previous post, to be clear:

- These are buffers that have been open in every session since I was
working on them, they just haven't had windows for months (or years).

- When I said they're "popping up" I really ought to have just said that
they're randomly being given windows when Emacs starts.

- (These are in GUI frames on GNU/Linux.)

I understood this to be the complaint of the OP which I understood Eli
to have said he doesn't see:

At 07:31 -0400 on Wednesday 2016-08-24, John Covici wrote:

> I am having a problem restoring my desktop, when there are several
> buffers. Instead of restoring the correct buffer as the current one, a
> random buffer is restored.

I don't believe I have any settings in this area at all, other than
these two settings in my custom-set-variables:

  '(desktop-path (quote ("." "~/.emacs.d/" "~")))
  '(desktop-save-mode t)

I haven't yet tried your suggestion of setting desktop-restore-frames to
`nil' (it is currently `t') because it's doc string merely says:

  When non-nil, save and restore the frame and window configuration.
  See related options `desktop-restore-reuses-frames',
  `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'.

This neglects to mention what it does when it's set to `nil'.

N.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24298 <at> debbugs.gnu.org, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 17:48:14 +0300

> Date: Thu, 25 Aug 2016 11:16:42 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: covici <at> ccs.covici.com, 24298 <at> debbugs.gnu.org
> 
>  >> What happens when you set ‘desktop-restore-frames’ to nil?
>  >
>  > FWIW, the stuff works for me reliably without changing the defaulot
>  > value of that variable.
>  >
>  >> Apparently, restoring the buffer order with framesets seems to be a
>  >> problem, see also bug#15382 and bug#23630.
>  >
>  > Doesn't happen here, FWIW.
> 
> Which seems to indicate that some other issue plays a role here.

Most probably.

For starters, I'd suggest that people who see this problem compare the
order of buffers in their .emacs.desktop file with what was on screen
before Emacs was shut down or saved the desktop.  Does the current
buffer appear where we expect it to be?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24298 <at> debbugs.gnu.org, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 17:50:24 +0300

> Date: Thu, 25 Aug 2016 14:27:53 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 24298 <at> debbugs.gnu.org
> 
>  > How would you have more than one frame on a text console,
> 
> (progn
>    (make-frame)
>    (frame-list))

Or even

  C-x 5 f SOME-FILE RET
  C-x 5 o

(and also look at the left corner of the mode line to see the frame
name change when you do the above).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: nljlistbox2 <at> gmail.com (N. Jackson)
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at, covici <at> ccs.covici.com
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 17:52:05 +0300

> From: nljlistbox2 <at> gmail.com (N. Jackson)
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  24298 <at> debbugs.gnu.org,  covici <at> ccs.covici.com
> Date: Thu, 25 Aug 2016 10:09:50 -0300
> 
> I haven't yet tried your suggestion of setting desktop-restore-frames to
> `nil' (it is currently `t') because it's doc string merely says:
> 
>   When non-nil, save and restore the frame and window configuration.
>   See related options `desktop-restore-reuses-frames',
>   `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'.
> 
> This neglects to mention what it does when it's set to `nil'.

Quite obviously, it doesn't do what is described for the non-nil
value.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 11:31:35 -0400

What I found was that the random buffer appears and if I get the
buffer list, *scratch is next and then the buffers as I had them
before.  If I close and reopen, a new random buffer appears followed
by the  previous random  buffer, etc.

I hope this helps.

On Thu, 25 Aug 2016 10:48:14 -0400,
Eli Zaretskii wrote:
> 
> > Date: Thu, 25 Aug 2016 11:16:42 +0200
> > From: martin rudalics <rudalics <at> gmx.at>
> > CC: covici <at> ccs.covici.com, 24298 <at> debbugs.gnu.org
> > 
> >  >> What happens when you set ‘desktop-restore-frames’ to nil?
> >  >
> >  > FWIW, the stuff works for me reliably without changing the defaulot
> >  > value of that variable.
> >  >
> >  >> Apparently, restoring the buffer order with framesets seems to be a
> >  >> problem, see also bug#15382 and bug#23630.
> >  >
> >  > Doesn't happen here, FWIW.
> > 
> > Which seems to indicate that some other issue plays a role here.
> 
> Most probably.
> 
> For starters, I'd suggest that people who see this problem compare the
> order of buffers in their .emacs.desktop file with what was on screen
> before Emacs was shut down or saved the desktop.  Does the current
> buffer appear where we expect it to be?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 19:22:43 +0300

> Date: Thu, 25 Aug 2016 11:31:35 -0400
> From: John Covici <covici <at> ccs.covici.com>
> Cc: martin rudalics <rudalics <at> gmx.at>, 24298 <at> debbugs.gnu.org
> 
> What I found was that the random buffer appears and if I get the
> buffer list, *scratch is next and then the buffers as I had them
> before.  If I close and reopen, a new random buffer appears followed
> by the  previous random  buffer, etc.

Is that exactly what you see in the .emacs.desktop file?  IOW, is the
wrong order recorded in the file (which would mean the problem happens
when the desktop file is written), or is the order in the file
correct, which would mean the problem happens when restoring the
session from the file?

Thanks.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 14:22:57 -0400

On Thu, 25 Aug 2016 12:22:43 -0400,
Eli Zaretskii wrote:
> 
> > Date: Thu, 25 Aug 2016 11:31:35 -0400
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: martin rudalics <rudalics <at> gmx.at>, 24298 <at> debbugs.gnu.org
> > 
> > What I found was that the random buffer appears and if I get the
> > buffer list, *scratch is next and then the buffers as I had them
> > before.  If I close and reopen, a new random buffer appears followed
> > by the  previous random  buffer, etc.
> 
> Is that exactly what you see in the .emacs.desktop file?  IOW, is the
> wrong order recorded in the file (which would mean the problem happens
> when the desktop file is written), or is the order in the file
> correct, which would mean the problem happens when restoring the
> session from the file?
> 
> Thanks.

I think it must be on the restore, because if I go to a version which
works, it gives me the original buffer I had.  I was looking in the
buffer list c-x-c-b for the order.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 21:30:17 +0300

> Date: Thu, 25 Aug 2016 14:22:57 -0400
> From: John Covici <covici <at> ccs.covici.com>
> Cc: rudalics <at> gmx.at, 24298 <at> debbugs.gnu.org
> 
> I was looking in the buffer list c-x-c-b for the order.

Please look in the .emacs.desktop file itself.  It's a text file, so
is human-readable.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 15:04:11 -0400

On Thu, 25 Aug 2016 14:30:17 -0400,
Eli Zaretskii wrote:
> 
> > Date: Thu, 25 Aug 2016 14:22:57 -0400
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: rudalics <at> gmx.at, 24298 <at> debbugs.gnu.org
> > 
> > I was looking in the buffer list c-x-c-b for the order.
> 
> Please look in the .emacs.desktop file itself.  It's a text file, so
> is human-readable.

And the order does correspond to what I see in the buffer list.  Aside
from the damage of restoring the desktop in a version which broke the
restore, it looks like I had it before the problem started.  I have
some 159 buffers, so I did notice this right away, but I even could
reproduce it with 3 or 4 buffers.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 22:18:56 +0300

> Date: Thu, 25 Aug 2016 15:04:11 -0400
> From: John Covici <covici <at> ccs.covici.com>
> Cc: rudalics <at> gmx.at, 24298 <at> debbugs.gnu.org
> 
> > Please look in the .emacs.desktop file itself.  It's a text file, so
> > is human-readable.
> 
> And the order does correspond to what I see in the buffer list.  Aside
> from the damage of restoring the desktop in a version which broke the
> restore, it looks like I had it before the problem started.

Sorry, I'm confused: when you say "I had it", what do you mean by
"it"?

The desktop file records the buffer that was current in each frame, as
part of the "frameset" at the beginning of the file, and then it
records the list of buffers unrelated to frames.  Does the frameset
state the buffers correctly?

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#24298: 25.1; problem with restoring desktop
Date: Thu, 25 Aug 2016 15:30:23 -0400

On Thu, 25 Aug 2016 15:18:56 -0400,
Eli Zaretskii wrote:
> 
> > Date: Thu, 25 Aug 2016 15:04:11 -0400
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: rudalics <at> gmx.at, 24298 <at> debbugs.gnu.org
> > 
> > > Please look in the .emacs.desktop file itself.  It's a text file, so
> > > is human-readable.
> > 
> > And the order does correspond to what I see in the buffer list.  Aside
> > from the damage of restoring the desktop in a version which broke the
> > restore, it looks like I had it before the problem started.
> 
> Sorry, I'm confused: when you say "I had it", what do you mean by
> "it"?

I mean the order of the buffers before I used a version with the
problem.

> 
> The desktop file records the buffer that was current in each frame, as
> part of the "frameset" at the beginning of the file, and then it
> records the list of buffers unrelated to frames.  Does the frameset
> state the buffers correctly?
What is in the framset is correct, but when the bug is present another
buffer is made current.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: John Covici <covici <at> ccs.covici.com>
To: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 03 Dec 2016 20:51:48 -0500

OK, doing a git bisect, I found the commit which breaks my desktop
restore -- I am using a text console here.

[c9f7ec736b78bef5359b6da03296277c535e8e89] * lisp/desktop.el: Disable
restore frameset if in non-graphic display.

Thanks, I hope someone can help resolve this one.

On Wed, 24 Aug 2016 07:32:01 -0400,
GNU bug Tracking System wrote:
> 
> Thank you for filing a new bug report with debbugs.gnu.org.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  bug-gnu-emacs <at> gnu.org
> 
> If you wish to submit further information on this problem, please
> send it to 24298 <at> debbugs.gnu.org.
> 
> Please do not send mail to help-debbugs <at> gnu.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 24298: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24298
> GNU Bug Tracking System
> Contact help-debbugs <at> gnu.org with problems
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sun, 04 Dec 2016 17:28:23 +0200

> Date: Sat, 03 Dec 2016 20:51:48 -0500
> From: John Covici <covici <at> ccs.covici.com>
> 
> OK, doing a git bisect, I found the commit which breaks my desktop
> restore -- I am using a text console here.
> 
> [c9f7ec736b78bef5359b6da03296277c535e8e89] * lisp/desktop.el: Disable
> restore frameset if in non-graphic display.

Does this mean you have more than one frame in your text-terminal
sessions, after restoring the desktop?  What effect does the following
command produce after you restore the session?

  C-x 5 o

If you have more than one frame, you should now see "Fn" at the left
edge of the mode line, where n is a small integer, which is different
from the one you saw there before the above command.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sun, 04 Dec 2016 10:34:37 -0500

On Sun, 04 Dec 2016 10:28:23 -0500,
Eli Zaretskii wrote:
> 
> > Date: Sat, 03 Dec 2016 20:51:48 -0500
> > From: John Covici <covici <at> ccs.covici.com>
> > 
> > OK, doing a git bisect, I found the commit which breaks my desktop
> > restore -- I am using a text console here.
> > 
> > [c9f7ec736b78bef5359b6da03296277c535e8e89] * lisp/desktop.el: Disable
> > restore frameset if in non-graphic display.
> 
> Does this mean you have more than one frame in your text-terminal
> sessions, after restoring the desktop?  What effect does the following
> command produce after you restore the session?
> 
>   C-x 5 o
> 
> If you have more than one frame, you should now see "Fn" at the left
> edge of the mode line, where n is a small integer, which is different
> from the one you saw there before the above command.

Nope, this is a text console,  the command does nothing.  IIn fact, it
does not seem to complete.   In the echo area I just get c-x-5-o
sitting there.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 16:19:07 +0200

> Date: Sun, 04 Dec 2016 10:34:37 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> On Sun, 04 Dec 2016 10:28:23 -0500,
> Eli Zaretskii wrote:
> > 
> > > Date: Sat, 03 Dec 2016 20:51:48 -0500
> > > From: John Covici <covici <at> ccs.covici.com>
> > > 
> > > OK, doing a git bisect, I found the commit which breaks my desktop
> > > restore -- I am using a text console here.
> > > 
> > > [c9f7ec736b78bef5359b6da03296277c535e8e89] * lisp/desktop.el: Disable
> > > restore frameset if in non-graphic display.
> > 
> > Does this mean you have more than one frame in your text-terminal
> > sessions, after restoring the desktop?  What effect does the following
> > command produce after you restore the session?
> > 
> >   C-x 5 o
> > 
> > If you have more than one frame, you should now see "Fn" at the left
> > edge of the mode line, where n is a small integer, which is different
> > from the one you saw there before the above command.
> 
> Nope, this is a text console,  the command does nothing.

Then I'm afraid I cannot reproduce this.  I tried restoring my desktop
in "emacs -nw" several times, and each time I end up looking at the
same 2 buffers displayed in 2 windows one below the other.

Could you perhaps create the smallest desktop file that reproduces
this problem for you, and post it?  I'd like to experiment with it.

Thanks.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 10:02:11 -0500

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

On Sat, 10 Dec 2016 09:19:07 -0500,
Eli Zaretskii wrote:
> 
> > Date: Sun, 04 Dec 2016 10:34:37 -0500
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: 24298 <at> debbugs.gnu.org
> > 
> > On Sun, 04 Dec 2016 10:28:23 -0500,
> > Eli Zaretskii wrote:
> > > 
> > > > Date: Sat, 03 Dec 2016 20:51:48 -0500
> > > > From: John Covici <covici <at> ccs.covici.com>
> > > > 
> > > > OK, doing a git bisect, I found the commit which breaks my desktop
> > > > restore -- I am using a text console here.
> > > > 
> > > > [c9f7ec736b78bef5359b6da03296277c535e8e89] * lisp/desktop.el: Disable
> > > > restore frameset if in non-graphic display.
> > > 
> > > Does this mean you have more than one frame in your text-terminal
> > > sessions, after restoring the desktop?  What effect does the following
> > > command produce after you restore the session?
> > > 
> > >   C-x 5 o
> > > 
> > > If you have more than one frame, you should now see "Fn" at the left
> > > edge of the mode line, where n is a small integer, which is different
> > > from the one you saw there before the above command.
> > 
> > Nope, this is a text console,  the command does nothing.
> 
> Then I'm afraid I cannot reproduce this.  I tried restoring my desktop
> in "emacs -nw" several times, and each time I end up looking at the
> same 2 buffers displayed in 2 windows one below the other.
> 
> Could you perhaps create the smallest desktop file that reproduces
> this problem for you, and post it?  I'd like to experiment with it.
> 
> Thanks.

I can reproduce this with a  desktop with just two buffers, what
happens is when the commit is there, the wrong buffer is the current
one and  if I do c-x-b it has the scratch buffer as the next one
rather than the previous buffer.  For instance in the desktop I will
send you, the current buffer is the Makefile, but when I restore the
desktop, default.xml is made the current buffer instead and the
scratch buffer is the default for c-x-b.  Now this is not bad in
itself, but in a desktop with a lot of buffers, it makes the current
buffer some random one instead, so its very annoying.

Here is the desktop which reproduces this every time.

[.emacs.desktop (application/octet-stream, attachment)]

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

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 17:50:05 +0200

> Date: Sat, 10 Dec 2016 10:02:11 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> I can reproduce this with a  desktop with just two buffers, what
> happens is when the commit is there, the wrong buffer is the current
> one and  if I do c-x-b it has the scratch buffer as the next one
> rather than the previous buffer.  For instance in the desktop I will
> send you, the current buffer is the Makefile, but when I restore the
> desktop, default.xml is made the current buffer instead and the
> scratch buffer is the default for c-x-b.

The desktop file you sent doesn't have Makefile, it has default.xml
and brltty-9999.ebuild.  The buffer that's expected to be the current
one after restoring is the first one in the list, and in your case
it's default.xml.  So if that buffer becomes the current after
restoring desktop, I don't see a problem in the restore stage, and
don't understand how that commit could have changed this.

What do you see in the list returned by buffer-list, before you end a
session?  The buffers are recorded in the desktop file in the order
they appear in that list, and in my case, this is the current buffer
when I invoke desktop-save.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 11:02:47 -0500

On Sat, 10 Dec 2016 10:50:05 -0500,
Eli Zaretskii wrote:
> 
> > Date: Sat, 10 Dec 2016 10:02:11 -0500
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: 24298 <at> debbugs.gnu.org
> > 
> > I can reproduce this with a  desktop with just two buffers, what
> > happens is when the commit is there, the wrong buffer is the current
> > one and  if I do c-x-b it has the scratch buffer as the next one
> > rather than the previous buffer.  For instance in the desktop I will
> > send you, the current buffer is the Makefile, but when I restore the
> > desktop, default.xml is made the current buffer instead and the
> > scratch buffer is the default for c-x-b.
> 
> The desktop file you sent doesn't have Makefile, it has default.xml
> and brltty-9999.ebuild.  The buffer that's expected to be the current
> one after restoring is the first one in the list, and in your case
> it's default.xml.  So if that buffer becomes the current after
> restoring desktop, I don't see a problem in the restore stage, and
> don't understand how that commit could have changed this.
> 
> What do you see in the list returned by buffer-list, before you end a
> session?  The buffers are recorded in the desktop file in the order
> they appear in that list, and in my case, this is the current buffer
> when I invoke desktop-save.

I am sorry, it wasn't a makefile, you are correct.  OK, let me try
again.  Before the restore commit, when I enter emacs, the current
buffer is brltty-9999.ebuild but after the commit the current buffer
is the default.xml.    Before the restore commit, if I do c-x-b the
default buffer it wants to switch to is default.xml.  After the
restore commit, when the current buffer is default.xml when it should
be brltty-9999.ebuild the default buffer to switch to is the scratch
buffer.  In a desktop with many buffers, after the restore commit, it
seems to pick a random buffer to be the current buffer rather than the
one it should be.

I hope this is clear now.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 19:47:24 +0200

> Date: Sat, 10 Dec 2016 11:02:47 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> > The desktop file you sent doesn't have Makefile, it has default.xml
> > and brltty-9999.ebuild.  The buffer that's expected to be the current
> > one after restoring is the first one in the list, and in your case
> > it's default.xml.  So if that buffer becomes the current after
> > restoring desktop, I don't see a problem in the restore stage, and
> > don't understand how that commit could have changed this.
> > 
> > What do you see in the list returned by buffer-list, before you end a
> > session?  The buffers are recorded in the desktop file in the order
> > they appear in that list, and in my case, this is the current buffer
> > when I invoke desktop-save.
> 
> I am sorry, it wasn't a makefile, you are correct.  OK, let me try
> again.  Before the restore commit, when I enter emacs, the current
> buffer is brltty-9999.ebuild but after the commit the current buffer
> is the default.xml.    Before the restore commit, if I do c-x-b the
> default buffer it wants to switch to is default.xml.  After the
> restore commit, when the current buffer is default.xml when it should
> be brltty-9999.ebuild the default buffer to switch to is the scratch
> buffer.  In a desktop with many buffers, after the restore commit, it
> seems to pick a random buffer to be the current buffer rather than the
> one it should be.
> 
> I hope this is clear now.

It is, thanks.  But please also answer my question above about the
order of buffers in the list returned by buffer-list, before you quite
Emacs which writes the desktop file.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 13:46:15 -0500

On Sat, 10 Dec 2016 12:47:24 -0500,
Eli Zaretskii wrote:
> 
> > Date: Sat, 10 Dec 2016 11:02:47 -0500
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: 24298 <at> debbugs.gnu.org
> > 
> > > The desktop file you sent doesn't have Makefile, it has default.xml
> > > and brltty-9999.ebuild.  The buffer that's expected to be the current
> > > one after restoring is the first one in the list, and in your case
> > > it's default.xml.  So if that buffer becomes the current after
> > > restoring desktop, I don't see a problem in the restore stage, and
> > > don't understand how that commit could have changed this.
> > > 
> > > What do you see in the list returned by buffer-list, before you end a
> > > session?  The buffers are recorded in the desktop file in the order
> > > they appear in that list, and in my case, this is the current buffer
> > > when I invoke desktop-save.
> > 
> > I am sorry, it wasn't a makefile, you are correct.  OK, let me try
> > again.  Before the restore commit, when I enter emacs, the current
> > buffer is brltty-9999.ebuild but after the commit the current buffer
> > is the default.xml.    Before the restore commit, if I do c-x-b the
> > default buffer it wants to switch to is default.xml.  After the
> > restore commit, when the current buffer is default.xml when it should
> > be brltty-9999.ebuild the default buffer to switch to is the scratch
> > buffer.  In a desktop with many buffers, after the restore commit, it
> > seems to pick a random buffer to be the current buffer rather than the
> > one it should be.
> > 
> > I hope this is clear now.
> 
> It is, thanks.  But please also answer my question above about the
> order of buffers in the list returned by buffer-list, before you quite
> Emacs which writes the desktop file.

Here is what I have before the restore commit.

CRM Buffer                 Size Mode             File
.   brltty-9999.ebuild     4916 Text
/usr/local/portage/app-accessibility/brltty/brltty-9999.ebuild
    default.xml           48920 nXML Invalid
    /etc/freeswitch/conf/dialplan/default.xml
     %* *Completions*           275 Completion List
	    *scratch*               145 Lisp Interaction
	     %* *Messages*              578 Messages

And here is what I get after the commit
CRM Buffer                 Size Mode             File
    *scratch*               145 Lisp Interaction
     %* *Messages*              206 Messages
	    brltty-9999.ebuild     4916 Text
	    /usr/local/portage/app-accessibility/brltty/brltty-9999.ebuild
	    .   default.xml           48920 nXML Invalid
	    /etc/freeswitch/conf/dialplan/default.xml

and if I quit emacs and use emacs before the commit, I get the first
one.

Hope this helps.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 17 Dec 2016 15:11:59 +0200

> Date: Sat, 10 Dec 2016 13:46:15 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> > > I am sorry, it wasn't a makefile, you are correct.  OK, let me try
> > > again.  Before the restore commit, when I enter emacs, the current
> > > buffer is brltty-9999.ebuild but after the commit the current buffer
> > > is the default.xml.    Before the restore commit, if I do c-x-b the
> > > default buffer it wants to switch to is default.xml.  After the
> > > restore commit, when the current buffer is default.xml when it should
> > > be brltty-9999.ebuild the default buffer to switch to is the scratch
> > > buffer.  In a desktop with many buffers, after the restore commit, it
> > > seems to pick a random buffer to be the current buffer rather than the
> > > one it should be.
> > > 
> > > I hope this is clear now.
> > 
> > It is, thanks.  But please also answer my question above about the
> > order of buffers in the list returned by buffer-list, before you quite
> > Emacs which writes the desktop file.
> 
> Here is what I have before the restore commit.
> 
> CRM Buffer                 Size Mode             File
> .   brltty-9999.ebuild     4916 Text
> /usr/local/portage/app-accessibility/brltty/brltty-9999.ebuild
>     default.xml           48920 nXML Invalid
>     /etc/freeswitch/conf/dialplan/default.xml
>      %* *Completions*           275 Completion List
> 	    *scratch*               145 Lisp Interaction
> 	     %* *Messages*              578 Messages
> 
> And here is what I get after the commit
> CRM Buffer                 Size Mode             File
>     *scratch*               145 Lisp Interaction
>      %* *Messages*              206 Messages
> 	    brltty-9999.ebuild     4916 Text
> 	    /usr/local/portage/app-accessibility/brltty/brltty-9999.ebuild
> 	    .   default.xml           48920 nXML Invalid
> 	    /etc/freeswitch/conf/dialplan/default.xml
> 
> and if I quit emacs and use emacs before the commit, I get the first
> one.
> 
> Hope this helps.

Thanks, can you try the patch below and see if it solves this problem?


diff --git a/lisp/desktop.el b/lisp/desktop.el
index 1f460b7..e83891b 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -1157,13 +1157,13 @@ desktop-lazy-timer
 ;; ----------------------------------------------------------------------------
 (defun desktop-restoring-frameset-p ()
   "True if calling `desktop-restore-frameset' will actually restore it."
-  (and desktop-restore-frames desktop-saved-frameset t))
+  (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
 
 (defun desktop-restore-frameset ()
   "Restore the state of a set of frames.
 This function depends on the value of `desktop-saved-frameset'
 being set (usually, by reading it from the desktop)."
-  (when (and (display-graphic-p) (desktop-restoring-frameset-p))
+  (when (desktop-restoring-frameset-p)
     (frameset-restore desktop-saved-frameset
 		      :reuse-frames (eq desktop-restore-reuses-frames t)
 		      :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 17 Dec 2016 09:05:00 -0500

Preliminary testing indicates its good,  I will try with latest master
and see what happens.

Thanks.

On Sat, 17 Dec 2016 08:11:59 -0500,
Eli Zaretskii wrote:
> 
> diff --git a/lisp/desktop.el b/lisp/desktop.el
> index 1f460b7..e83891b 100644
> --- a/lisp/desktop.el
> +++ b/lisp/desktop.el
> @@ -1157,13 +1157,13 @@ desktop-lazy-timer
>  ;; ----------------------------------------------------------------------------
>  (defun desktop-restoring-frameset-p ()
>    "True if calling `desktop-restore-frameset' will actually restore it."
> -  (and desktop-restore-frames desktop-saved-frameset t))
> +  (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
>  
>  (defun desktop-restore-frameset ()
>    "Restore the state of a set of frames.
>  This function depends on the value of `desktop-saved-frameset'
>  being set (usually, by reading it from the desktop)."
> -  (when (and (display-graphic-p) (desktop-restoring-frameset-p))
> +  (when (desktop-restoring-frameset-p)
>      (frameset-restore desktop-saved-frameset
>  		      :reuse-frames (eq desktop-restore-reuses-frames t)
>  		      :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 17 Dec 2016 16:46:44 +0200

> Date: Sat, 17 Dec 2016 09:05:00 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> Preliminary testing indicates its good,  I will try with latest master
> and see what happens.

I'd prefer that you test with the latest emacs-25 branch, if you can,
because I would like to fix this in Emacs 25.2, not 26.1.

Thanks in advance.

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

From: John Covici <covici <at> ccs.covici.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24298 <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 17 Dec 2016 11:41:13 -0500

OK, looks good with that branch as well.

On Sat, 17 Dec 2016 09:46:44 -0500,
Eli Zaretskii wrote:
> 
> > Date: Sat, 17 Dec 2016 09:05:00 -0500
> > From: John Covici <covici <at> ccs.covici.com>
> > Cc: 24298 <at> debbugs.gnu.org
> > 
> > Preliminary testing indicates its good,  I will try with latest master
> > and see what happens.
> 
> I'd prefer that you test with the latest emacs-25 branch, if you can,
> because I would like to fix this in Emacs 25.2, not 26.1.
> 
> Thanks in advance.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici <at> ccs.covici.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298-done <at> debbugs.gnu.org
Subject: Re: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 17 Dec 2016 19:07:17 +0200

> Date: Sat, 17 Dec 2016 11:41:13 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> OK, looks good with that branch as well.

Thanks, I installed the patch for the upcoming Emacs 25.2, and I'm
marking this bug done.

Thank you for your patience while this bug was being analyzed.

Previous Next

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