From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#22993: Potential fix/workaround for 22993 Date: Sun, 10 Jul 2016 17:11:12 +0100 Message-ID: <20160710161112.GA51429@breton.holly.idiocy.org> References: <57629b7f841b1a0000aa4164@polymail.io> <20160703091937.GA11931@breton.holly.idiocy.org> <20160707185531.GA12590@breton.holly.idiocy.org> <20160707195759.GB12590@breton.holly.idiocy.org> <20160710095332.GA35411@breton.holly.idiocy.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1468167145 15370 80.91.229.3 (10 Jul 2016 16:12:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jul 2016 16:12:25 +0000 (UTC) Cc: 22993@debbugs.gnu.org To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 10 18:12:16 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 1bMHL4-00005R-LE for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2016 18:12:14 +0200 Original-Received: from localhost ([::1]:55838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMHL3-0003Bo-8j for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Jul 2016 12:12:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMHKw-000381-HN for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 12:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMHKs-0007GA-8f for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 12:12:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMHKs-0007G6-4a for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 12:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bMHKr-0005oO-SU for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2016 12:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2016 16:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 22993-submit@debbugs.gnu.org id=B22993.146816708222287 (code B ref 22993); Sun, 10 Jul 2016 16:12:01 +0000 Original-Received: (at 22993) by debbugs.gnu.org; 10 Jul 2016 16:11:22 +0000 Original-Received: from localhost ([127.0.0.1]:45354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMHKE-0005nN-Ga for submit@debbugs.gnu.org; Sun, 10 Jul 2016 12:11:22 -0400 Original-Received: from mail-wm0-f49.google.com ([74.125.82.49]:37284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMHKC-0005nB-PJ for 22993@debbugs.gnu.org; Sun, 10 Jul 2016 12:11:21 -0400 Original-Received: by mail-wm0-f49.google.com with SMTP id k123so67157358wme.0 for <22993@debbugs.gnu.org>; Sun, 10 Jul 2016 09:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=YhvoTfKemd24WiYKdgSagNlIJ2khAuXKJUHAqckFG+U=; b=Bnug3MPPCqFhg1XJLbSAGeGyY9D2Uig2XQQD+JUOsZqgMrRljz8nwcEGyTdInLjMVK BGf06p3yzZmoX76R7EBh+eFUYFRq7H/6EmEhzTJ3zDvc74kb1KS3eT/HW9CJ72cNCO2h LT37YCQ+3FcwbZXxKzcsppQBbckT+G6wp1FUJ13SnM7xzlZYjuBVMmQox3tS35DS7HG2 oJs9YQRHSTKCQUDWRwU/MeDAZ57dpf7UQx1uuvRO733kQyVbLHFHG5eWGjppqIxnYNYV Qju/T+42hHOVo1VKmmMdLrHRjlw0HNGTUj9x6C7TBC0ZNZu1Nk4E+UbnFtiuJs0rTAP5 +qMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=YhvoTfKemd24WiYKdgSagNlIJ2khAuXKJUHAqckFG+U=; b=a0069ZtJwUWiA3GeQjxi1u0I2pMoPj8binzt0Pyq8O9QlRFo+SrvFgZFUhStp9eSW2 gSRLtO8YSoqme1Z0dNr9mDnVAu6awaoAGE4yqt10RnEDoVTn06c89/x+y4bJFcAOeaVz ufD5bJE2uNg3m8Rz4Cck/+cLPgCsa935K9m4XPJexd25ew8l6o+Fs3SS4I7LucJibx63 aNlvNhTm4Yjxlpo5xTtS5WQnKpXRm4itHzTv034BW88nr5tQN54ofa23jheVsLTsBXHg aVHMXDoPSxNirpaX7UJw1ogRpym5qgEnS8ncGgNTIwdAiLYS3HE8VV0WaVqV8GxZ+aUt GIJw== X-Gm-Message-State: ALyK8tLfIXsSFNxVVgzFRQpqzcQKjXktj0PPKYh9vMUfp/Mb/0L3lsP8Njuz1AhSCor9mQ== X-Received: by 10.28.31.140 with SMTP id f134mr7780376wmf.69.1468167075166; Sun, 10 Jul 2016 09:11:15 -0700 (PDT) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-5cc4-ba14-a0d0-bdac.holly.idiocy.org. [2001:8b0:3f8:8129:5cc4:ba14:a0d0:bdac]) by smtp.gmail.com with ESMTPSA id a2sm8283244wma.2.2016.07.10.09.11.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jul 2016 09:11:14 -0700 (PDT) Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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:120768 Archived-At: On Sun, Jul 10, 2016 at 03:38:57PM +0000, Aaron Jensen wrote: > The code referenced is getting the main bundle, then getting its Info.plist > and writing `NSAppSleepDisabled` to be true. I’m sure you can tell that. > What I don’t know is if it actually modifies the Info.plist, or if it has > the same effect as the “defaults write” work around below. > > It also appears to not be the “correct”[1] way to disable appnap, which, > afaict, requires objective c[2]? > > [1]: http://lists.apple.com/archives/java-dev/2014/Feb/msg00051.html > [2]: https://github.com/bitcoin/bitcoin/pull/5804/files Yeah, I expect we'd have to convert it to Objective C since almost all the NS port specific code is written in it. I've seen the suggestion in your second link elsewhere too, and it's generally described as being for long-running processes that shouldn't be interrupted, not for a process sitting waiting for input. (Just using the code as provided will actually, as I understand it, prevent the PC from sleeping too, there's some other command that doesn't do that, but I don't have it to hand right now.) Apparently App Nap also doesn't affect any code that occurs within an event handler, which perhaps explains why I can type this email within an emacsclient -t session with no problems, but you're seeing trouble with other, possibly more complex, situations. > > For future reference, here are the known work-arounds for this problem: > > > > 1. At the command prompt: defaults write org.gnu.Emacs NSAppSleepDisabled > > -bool YES > > > > 2. Right-click on the Emacs icon and select 'get info' and tick the > > 'Disable App Nap' checkbox. (Although I don't get that tick box...) > > > > Nor do I, it’d be nice if we knew why this was. I get it for an Emacs 24.5 that I downloaded from Emacsformacosx.com, which made me wonder if it was because I compiled it myself or something... :/ > > 3. Run in daemon mode: Emacs as a daemon has no GUI so app nap > > is disabled automatically. > > > > > I wonder if it would be worth posting to an apple mailing list about this? > It seems to be an edge case—an app that is sometimes a gui+daemon. Yes, it appears that Apple haven't provided a way for apps to both have a GUI and act as a server. Perhaps we should raise it directly with them. It would also be nice if we could attract some people with Objective C and Cocoa experience to Emacs development, right now we seem to have none. I'm trying to pick up Objective C, Cocoa, GNUStep and Emacs's internals all at the same time. > I’ve also been unable to find Cocoa equivalents to the APIs > mentioned as the proper way to disable app nap (if we could use > these, we could begin an activity when a server starts, so app nap > would only be disabled in that case). If there were an easy way to > detect a tty frame coming into and leaving existence it could even > be done around that. Yes, I'd wondered about something like that, but I don't know how the server bit works. Anyone out there know about the practicalities of implementing this? Is there a hook that executes when a connection is made from emacsclient? Apparently there's server-visit-hook, but that only works if you load a file, and we need to be able to disable app nap even if no file is loaded. -- Alan Third