From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#20247: 24.4; Emacs hangs at startup in desktop mode Date: Fri, 20 May 2016 10:15:53 -0700 (PDT) Message-ID: <4eebea73-4fcb-4dc7-b149-cef7a34a3c16@default> References: <<551D5EB90201036000390576_0_67183@p057> <09b74092-e4db-4ee0-8508-a71cc29e0205@default>> <<83d1og90iw.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1463764739 25153 80.91.229.3 (20 May 2016 17:18:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 May 2016 17:18:59 +0000 (UTC) Cc: rmunitz1@bloomberg.net, eggert@cs.ucla.edu, 20247@debbugs.gnu.org, lekktu@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 20 19:18:45 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b3o42-0005Y2-UD for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 May 2016 19:18:19 +0200 Original-Received: from localhost ([::1]:55700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3o3w-0001uV-Rf for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 May 2016 13:18:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3o2s-00016X-BT for bug-gnu-emacs@gnu.org; Fri, 20 May 2016 13:17:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3o2o-0007nQ-9G for bug-gnu-emacs@gnu.org; Fri, 20 May 2016 13:17:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3o2o-0007nM-5K for bug-gnu-emacs@gnu.org; Fri, 20 May 2016 13:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b3o2o-0005kT-1v for bug-gnu-emacs@gnu.org; Fri, 20 May 2016 13:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 May 2016 17:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20247 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20247-submit@debbugs.gnu.org id=B20247.146376457422042 (code B ref 20247); Fri, 20 May 2016 17:17:02 +0000 Original-Received: (at 20247) by debbugs.gnu.org; 20 May 2016 17:16:14 +0000 Original-Received: from localhost ([127.0.0.1]:59294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b3o21-0005jS-Na for submit@debbugs.gnu.org; Fri, 20 May 2016 13:16:13 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:16406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b3o1z-0005jD-Ci for 20247@debbugs.gnu.org; Fri, 20 May 2016 13:16:12 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4KHFuZq005968 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 May 2016 17:15:56 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u4KHFt1v019878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 May 2016 17:15:56 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u4KHFsnL008896; Fri, 20 May 2016 17:15:55 GMT In-Reply-To: <<83d1og90iw.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:118493 Archived-At: > > Can we not leave the default to respecting the saved display value, > > but also use a `condition-case' or similar to DTRT if that display > > does not exist or trying to use it raises an error in some other way? >=20 > Can you explain why using display that is not the current one even > makes sense? Ask Juanma, or whoever else might have been responsible for designing this aspect of desktop. Desktop is designed to support exactly that, no? You are apparently questioning the design. That's fair, but is it necessary to address this bug? Anyway, I can't speak to the reasons why desktop is designed as it is. I'm just assuming that the design is not insane, as you seem to be suggesting (this part of) it is. > > The proposed cure sounds like killing the patient. >=20 > To me it sounds like the only sane behavior. It sounds like you think it is insane for desktop to ever specify (record) or use a `display' entry. If so, that sounds like a design change for desktop. Do you not think there was a reason to allow users to record the display as part of a desktop record, and to restore the desktop using that recorded display? Can you not imagine such a use case? I can, but maybe I'm missing something. Desktop records lots of stuff that might not be usable when an attempt is made to restore the recorded desktop. Normally, it tries to be fault-tolerant during restoration, and back off when trying to restore something doesn't work or seems to be inappropriate in the restoration context. I don't see how this problem is different, or why it should be handled differently, especially by simply getting rid of any ability to restore to a particular display. As I said, this in no way affects how I use Emacs, personally. But I'm guessing that there was a (good) reason for allowing recording (and so restoring) a `display' value. And I'm guessing that some users might be taking advantage of it. I don't see how this bug necessitates tossing that part of the desktop design. But apparently you do. > > And it doesn't solve the underlying problem for a user who decides > > to customize the value to use the recorded display value. >=20 > The assumption is that if such a customization produces problematic > behavior, users won't do that. If you take the view you seem to be taking, then why not simply remove all desktop support for a `display' entry? Why stop with changing the default value of this option? Fix the problem by eliminating the cause altogether, not just as a default value. > > A better fix, I think, would be to do something like this: > > > > 1. Leave the default as is (not specifically important to this bug, > > however, as I mentioned: changing the default does NOT solve the > > problem, AFAICT). > > > > 2. If the current value says to use the recorded display then try > > to do that. If an error is raised then do not use it. >=20 > That's okay to try on master (if someone thinks it would be better), > but not on the release branch. Note that trying to use it might > display some of the frames, which would then be tricky to remove, and > flashing them might not look good. I don't doubt that it might be tricky to try to fix. > > I don't have the code for #2. No doubt Someone (TM) would need to > > _actually try to debug this_, to find out just what happens when a > > bad display value is tried. >=20 > I think it's clear without any debugging. Really? In that case, can you please make it raise an error instead of hanging? And if you can do that then I'm guessing it should be pretty simple to DTRT and check for that error - and when it is raised not try to restore to the recorded `display' entry. No? > > The first task is for Someone (TM) to actually try to find out > > what the problem is - what happens - when the display value is > > inappropriate. >=20 > The same thing that happens when you try to communicate with a machine > that is down or disconnected. So turn that eventuality into raising an error, and handle the error by abandoning continuing to try to use that nonexistent/broken display. IOW, act, when there is such an error, the way you apparently want Emacs to act all the time: as if no `display' entry were recorded. Again. I don't really care what you do with this bug, personally. It just sounds like you are perhaps throwing out the baby (=3D desktop support for `display' entries) with the bathwater. The baby needs a bath, sure, but s?he shouldn't be tossed out in the process, I think. I'm done here. Do what you will. Just trying to help.