bug#22993: 25.0.92; OS X app nap slows down tty emacsclient

bug#22993: 25.0.92; OS X app nap slows down tty emacsclient

[Aaron Jensen]

[-- Attachment #1.1: Type: text/plain, Size: 4655 bytes --]

This has been a terribly frustrating bug to track down, but here it is, along with a repro. The gist is that if you run gui emacs  as a server on OS X, tty emacsclients connected to it are adversely affected when the Emacs.app goes into “App Nap” mode on OS X.

Repro:

- On OS X El Capitan (probably works on Mavericks as well) run emacs -Q

- Do M-x server-start

- In terminal, run emacsclient --tty somefile

- Eval the following:

(defun test-app-nap ()

(interactive)

(message "Before %s" (current-time-string))

(redisplay)

(message "After redisplay %s" (current-time-string))

(message "read-event %s" (read-event nil t 0.001))

(message "After %s" (current-time-string)))

- M-x test-app-nap and observe that it immediately shows "After

"

- Wait for Emacs to switch to app nap. You may be able to monitor with

Activity Monitor, but emacs -Q doesn't always show up there. As long

as you are not focused on the GUI emacs, it should start to nap in a

minute or two.

- Back in the terminal, M-x test-app-nap

- You should see the "After redisplay

" message for several

(probably 10) seconds before seeing the "After

" message

- Switch to the emacs gui app, then back to the terminal and M-x

test-app-nap

- It should be back to the immediate "After

" message

App nap needs to be disabled in emacs, at least when the server is

running, but probably always. The typical workaround is to disable app

nap by going to the info window on the Emacs.app, but for some reason,

that checkbox is not available.

In GNU Emacs 25.0.92.1 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21))

of 2016-03-10 built on aaronmbp.local

Windowing system distributor 'Apple', version 10.3.1404

Configured using:

'configure --prefix=/usr/local/Cellar/emacs/25.0.92

--enable-locallisppath=/usr/local/share/emacs/site-lisp

--infodir=/usr/local/Cellar/emacs/25.0.92/share/info/emacs --with-xml2

--without-dbus --with-gnutls --with-rsvg --with-imagemagick --with-ns

--disable-ns-self-contained'

Configured features:

JPEG RSVG IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS

NS

Important settings:

value of $LC_CTYPE: en_US.UTF-8

value of $LANG: en_US.UTF-8

locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:

tooltip-mode: t

global-eldoc-mode: t

electric-indent-mode: t

mouse-wheel-mode: t

tool-bar-mode: t

menu-bar-mode: t

file-name-shadow-mode: t

global-font-lock-mode: t

font-lock-mode: t

blink-cursor-mode: t

auto-composition-mode: t

auto-encryption-mode: t

auto-compression-mode: t

line-number-mode: t

transient-mark-mode: t

Recent messages:

Making completion list...

You can run the command ‘server-start’ with M-x ser-s RET

When done with a buffer, type C-x #

Mark set

Auto-saving...

wtf

Before wtf Fri Mar 11 21:58:32 2016

After redisplay Fri Mar 11 21:58:32 2016

read-event nil

After wtf Fri Mar 11 21:58:38 2016

Load-path shadows:

None found.

Features:

(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml

mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode

mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047

rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase

cl-lib mail-prsvr mail-utils term/xterm xterm server time-date mule-util

tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type

mwheel ns-win ucs-normalize term/common-win 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 kqueue cocoa ns multi-tty

make-network-process emacs)

Memory information:

((conses 16 202233 6734)

(symbols 48 19770 0)

(miscs 40 57 215)

(strings 32 15988 5464)

(string-bytes 1 458233)

(vectors 16 33517)

(vector-slots 8 645323 6669)

(floats 8 170 338)

(intervals 56 234 0)

(buffers 976 14))

Aaron

[-- Attachment #1.2: Type: text/html, Size: 5320 bytes --]

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1.1: Type: text/plain, Size: 347 bytes --]

There are at least two ways to fix this, one is to disable app nap entirely. You can add this to Info.plist.in:

+  <key>LSAppNapIsDisabled</key>

 +    <string>True</string>

The other would be to somehow cause the app to “wake up” whenever the tty client is used as well. I’m not sure how to do that, it may be trickier.

Aaron

[-- Attachment #1.2: Type: text/html, Size: 487 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

"Aaron Jensen" <aaronjensen@gmail.com> writes:

> The other would be to somehow cause the app to “wake up” whenever the
> tty client is used as well. I’m not sure how to do that, it may be
> trickier.

Hi Aaron, I can't replicate the bug on my machine because this seems to
be exactly what happens. Are you still seeing this bug in a current
build?
-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On Fri, Jun 10, 2016 at 11:40 AM Alan Third <alan@idiocy.org> wrote:

> Hi Aaron, I can't replicate the bug on my machine because this seems to
> be exactly what happens. Are you still seeing this bug in a current
> build?
>

Hi Alan,

Yes, I can still repro with 25.0.95.1 on OS X 10.11.5. The following makes
it easier to repro:

1. Make sure your emacsclient is open already and it is displaying a buffer
that is not displayed by any window on the gui frame.
2. Minimize the gui frame.
3. Watch Activity Monitor until Emacs says App Nap: Yes

At this point, typing in the terminal or running the function in the
original report should not wake up the app from App Nap. As far as I can
tell, the only thing that does is focusing the gui frame.
-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 1204 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

On Sat, Jun 11, 2016 at 03:51:50PM +0000, Aaron Jensen wrote:
> On Fri, Jun 10, 2016 at 11:40 AM Alan Third <alan@idiocy.org> wrote:
> 
> > Hi Aaron, I can't replicate the bug on my machine because this seems to
> > be exactly what happens. Are you still seeing this bug in a current
> > build?
> >
> 
> Hi Alan,
> 
> Yes, I can still repro with 25.0.95.1 on OS X 10.11.5. The following makes
> it easier to repro:
> 
> 1. Make sure your emacsclient is open already and it is displaying a buffer
> that is not displayed by any window on the gui frame.
> 2. Minimize the gui frame.
> 3. Watch Activity Monitor until Emacs says App Nap: Yes
> 
> At this point, typing in the terminal or running the function in the
> original report should not wake up the app from App Nap. As far as I can
> tell, the only thing that does is focusing the gui frame.

I can reproduce this. I suspect that I was doing something that was
causing the GUI window to update and that must have been bringing it
out of App Nap.

I don't actually see any performance issues, but that may just be
because my PC is otherwise idle.
-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Sat, Jun 11, 2016 at 9:19 AM Alan Third <alan@idiocy.org> wrote:

> I can reproduce this. I suspect that I was doing something that was
> causing the GUI window to update and that must have been bringing it
> out of App Nap.
>

Great, glad to hear I'm not the only one.


> I don't actually see any performance issues, but that may just be
> because my PC is otherwise idle.
>

Only certain things seem to have issues. read-event specifically does,
which is used in many places in my setup. I use evil, and to exit insert
mode, I hit ESC which ultimately calls read-event, meaning it takes a
second or two to exit. Helm has performance issues too. But yes, if your
computer is doing absolutely nothing else, maybe the scheduler is still
giving napping apps enough time. For me, I've always got something going on
so its pretty unusable.

As a workaround I use:

defaults write org.gnu.Emacs NSAppSleepDisabled -bool YES

But this should be built into the dist.
-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 1942 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

"Aaron Jensen" <aaronjensen@gmail.com> writes:

> There are at least two ways to fix this, one is to disable app nap
> entirely. You can add this to Info.plist.in:
>
> +  <key>LSAppNapIsDisabled</key>
>  +    <string>True</string>

Are you able to provide a patch for this? I've tried but it doesn't seem
to make any difference, so I expect I'm doing something wrong.

> The other would be to somehow cause the app to “wake up” whenever the
> tty client is used as well. I’m not sure how to do that, it may be
> trickier.

To my mind this would be preferable, as it means we could take advantage
of any power-saving features AppNap provides without causing performance
problems. I can't see anything anywhere about how to do it, though, so
perhaps it's impossible.
-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1.1: Type: text/plain, Size: 1724 bytes --]

I believe my first suggestion was incorrect, I apologize. This should do it:

 nextstep/templates/Info.plist.in | 2 ++

 1 file changed, 2 insertions(+)

diff --git a/nextstep/templates/Info.plist.in b/nextstep/templates/Info.plist.in

index dcd2fe3..6f56939 100644

--- a/nextstep/templates/Info.plist.in

+++ b/nextstep/templates/Info.plist.in

@@ -675,5 +675,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

        </array>

        <key>NSAppleScriptEnabled</key>

        <string>YES</string>

+       <key>LSAppNapIsDisabled</key>

+       <true/>

 </dict>

 </plist>

https://gist.github.com/aaronjensen/d81d94c116549d0893ba4bc637149550
https://gist.github.com/aaronjensen/d81d94c116549d0893ba4bc637149550

Aaron

Aaron

On Wed, Jun 15, 2016 at 1:35 PM Alan Third

<
mailto:Alan Third <alan@idiocy.org>
> wrote:

"Aaron Jensen" <
mailto:aaronjensen@gmail.com
> writes:

> There are at least two ways to fix this, one is to disable app nap

> entirely. You can add this to Info.plist.in:

>

> +

LSAppNapIsDisabled

> +

True

Are you able to provide a patch for this? I've tried but it doesn't seem

to make any difference, so I expect I'm doing something wrong.

> The other would be to somehow cause the app to “wake up” whenever the

> tty client is used as well. I’m not sure how to do that, it may be

> trickier.

To my mind this would be preferable, as it means we could take advantage

of any power-saving features AppNap provides without causing performance

problems. I can't see anything anywhere about how to do it, though, so

perhaps it's impossible.

--

Alan Third

[-- Attachment #1.2: Type: text/html, Size: 2520 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

Hi Aaron,

Sorry for taking so long to respond. I still see Emacs going into app
nap mode with this. Is it working for you?

On Thu, Jun 16, 2016 at 05:33:17AM -0700, Aaron Jensen wrote:
> I believe my first suggestion was incorrect, I apologize. This should do it:
> 
>  nextstep/templates/Info.plist.in | 2 ++
> 
>  1 file changed, 2 insertions(+)
> 
> diff --git a/nextstep/templates/Info.plist.in b/nextstep/templates/Info.plist.in
> 
> index dcd2fe3..6f56939 100644
> 
> --- a/nextstep/templates/Info.plist.in
> 
> +++ b/nextstep/templates/Info.plist.in
> 
> @@ -675,5 +675,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
> 
>         </array>
> 
>         <key>NSAppleScriptEnabled</key>
> 
>         <string>YES</string>
> 
> +       <key>LSAppNapIsDisabled</key>
> 
> +       <true/>
> 
>  </dict>
> 
>  </plist>
> 
> https://gist.github.com/aaronjensen/d81d94c116549d0893ba4bc637149550
> https://gist.github.com/aaronjensen/d81d94c116549d0893ba4bc637149550
> 
> Aaron
> 
> On Wed, Jun 15, 2016 at 1:35 PM Alan Third
> 
> <
> mailto:Alan Third <alan@idiocy.org>
> > wrote:
> 
> "Aaron Jensen" <
> mailto:aaronjensen@gmail.com
> > writes:
> 
> > There are at least two ways to fix this, one is to disable app nap
> 
> > entirely. You can add this to Info.plist.in:
> 
> >
> 
> > +
> 
> LSAppNapIsDisabled
> 
> > +
> 
> True
> 
> Are you able to provide a patch for this? I've tried but it doesn't seem
> 
> to make any difference, so I expect I'm doing something wrong.
> 
> > The other would be to somehow cause the app to “wake up” whenever the
> 
> > tty client is used as well. I’m not sure how to do that, it may be
> 
> > trickier.
> 
> To my mind this would be preferable, as it means we could take advantage
> 
> of any power-saving features AppNap provides without causing performance
> 
> problems. I can't see anything anywhere about how to do it, though, so
> 
> perhaps it's impossible.
> 


-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

Hi Alan,

On Sun, Jul 3, 2016 at 2:19 AM Alan Third <alan@idiocy.org> wrote:

> Hi Aaron,
>
> Sorry for taking so long to respond. I still see Emacs going into app
> nap mode with this. Is it working for you?
>

Yes, it's working for me. I just tested it again. I have seen reports of it
not working:

https://github.com/TauLabs/TauLabs/pull/2064#discussion_r45091777

And an alternative: https://github.com/TauLabs/TauLabs/pull/2094/files

That alternative is actually what I do today, but on the command line:

defaults write org.gnu.Emacs NSAppSleepDisabled -bool YES

I'm not familiar enough with the Emacs code to know where to add something
like
https://github.com/TauLabs/TauLabs/pull/2094/files#diff-5241674ea359ea2649ae759e69862569R268
but
maybe it can help you or someone else if the previous suggestion doesn't
work for all.
-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 1602 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

On Sun, Jul 03, 2016 at 05:23:01PM +0000, Aaron Jensen wrote:
> > Sorry for taking so long to respond. I still see Emacs going into app
> > nap mode with this. Is it working for you?
> >
> 
> Yes, it's working for me. I just tested it again. I have seen reports of it
> not working:

I'm going to push this change to master. In the worst case it doesn't
work for some people and nothing is different.

I can't see a better way of handling this problem.
-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Hi Alan,


On Thu, Jul 7, 2016 at 11:55 AM Alan Third <alan@idiocy.org> wrote:

> I'm going to push this change to master. In the worst case it doesn't
> work for some people and nothing is different.
>
> I can't see a better way of handling this problem.
> --
> Alan Third
>

Actually, I’d hold off. Even w/ this change in place, I saw it not work as
well, it just took longer/slept in different instances. I believe the fix I
linked to here would be best:
https://github.com/TauLabs/TauLabs/pull/2094/files

Thanks,

-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 1023 bytes --]

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

Also, I apologize for not sending an update after I saw it repro again with
the apparently-not-working fix in place.
-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 243 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

On Thu, Jul 07, 2016 at 07:08:29PM +0000, Aaron Jensen wrote:
> On Thu, Jul 7, 2016 at 11:55 AM Alan Third <alan@idiocy.org> wrote:
> 
> > I'm going to push this change to master. In the worst case it doesn't
> > work for some people and nothing is different.
> >
> > I can't see a better way of handling this problem.
> >
> 
> Actually, I’d hold off. Even w/ this change in place, I saw it not work as
> well, it just took longer/slept in different instances.

I've already pushed it to master. I guess I could revert it, but I'm
not sure it's worth it.

> I believe the fix I
> linked to here would be best:
> https://github.com/TauLabs/TauLabs/pull/2094/files

Unfortunately I can't quite work out what they're doing. That
QSettings thing is specific to QT, as far as I can tell. There must be
a Cocoa equivalent, but I don't know what it is.

I'll re-open the bug report, since I already closed it. :)
-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On Thu, Jul 7, 2016 at 12:58 PM Alan Third <alan@idiocy.org> wrote:

> Unfortunately I can't quite work out what they're doing. That
> QSettings thing is specific to QT, as far as I can tell. There must be
> a Cocoa equivalent, but I don't know what it is.
>

I believe it’s this:

 CFDictionarySetValue(infoDict, CFSTR(“NSAppSleepDisabled"),
kCFBooleanTrue);

via
https://github.com/salamanderrake/KDevelop/blob/0e9822520dde913e177d00ed964e07e73fb7f936/app/main.cpp#L194


<https://github.com/salamanderrake/KDevelop/blob/0e9822520dde913e177d00ed964e07e73fb7f936/app/main.cpp#L194>
>
>
> I'll re-open the bug report, since I already closed it. :)
>

Thanks!
-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 1376 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

On Fri, Jul 08, 2016 at 05:29:26AM +0000, Aaron Jensen wrote:
> On Thu, Jul 7, 2016 at 12:58 PM Alan Third <alan@idiocy.org> wrote:
> 
> > Unfortunately I can't quite work out what they're doing. That
> > QSettings thing is specific to QT, as far as I can tell. There must be
> > a Cocoa equivalent, but I don't know what it is.
> >
> 
> I believe it’s this:
> 
>  CFDictionarySetValue(infoDict, CFSTR(“NSAppSleepDisabled"),
> kCFBooleanTrue);
> 
> via
> https://github.com/salamanderrake/KDevelop/blob/0e9822520dde913e177d00ed964e07e73fb7f936/app/main.cpp#L194
> 
> 
> <https://github.com/salamanderrake/KDevelop/blob/0e9822520dde913e177d00ed964e07e73fb7f936/app/main.cpp#L194>

I've reverted the change, but I'm not keen to make the above changes
because they're not trivial, I don't understand them, and I would
basically be copying and pasting code. I suspect we could have license
issues with that. If anyone knows different feel free to chime in.

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...)

3. Run in daemon mode: Emacs as a daemon has no GUI so app nap
   is disabled automatically.

-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

On Sun, Jul 10, 2016 at 2:53 AM Alan Third <alan@idiocy.org> wrote:

> I've reverted the change, but I'm not keen to make the above changes
> because they're not trivial, I don't understand them, and I would
> basically be copying and pasting code. I suspect we could have license
> issues with that. If anyone knows different feel free to chime in.
>

I have also tried adding:

<key>NSAppSleepDisabled</key>
<true/>

To the plist and it still napped.

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


> 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.


>
> 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. 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.

-- 
Aaron

[-- Attachment #2: Type: text/html, Size: 3100 bytes --]

bug#22993: Potential fix/workaround for 22993

[Alan Third]

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

bug#22993: Potential fix/workaround for 22993

[Alan Third]

On Wed, Jun 15, 2016 at 09:35:24PM +0100, Alan Third wrote:
> "Aaron Jensen" <aaronjensen@gmail.com> writes:
> 
> > There are at least two ways to fix this, one is to disable app nap
> > entirely. You can add this to Info.plist.in:
> >
> > +  <key>LSAppNapIsDisabled</key>
> >  +    <string>True</string>
> 
> Are you able to provide a patch for this? I've tried but it doesn't seem
> to make any difference, so I expect I'm doing something wrong.

Hi Aaron,

I know this is ancient, and I don't know if it's still relevant any
more, but I've discovered that after making a change to Info.plist you
have to run:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
-v -f nextstep/Emacs.app

for it to take.

I have no idea what that is doing.

I found it while trying to work out how to fix PATH issues with native
compilation and running Emacs from Finder.
-- 
Alan Third

bug#22993: Potential fix/workaround for 22993

[Aaron Jensen]

On Thu, Jul 1, 2021 at 1:47 PM Alan Third <alan@idiocy.org> wrote:
>
> On Wed, Jun 15, 2016 at 09:35:24PM +0100, Alan Third wrote:
> > "Aaron Jensen" <aaronjensen@gmail.com> writes:
> >
> > > There are at least two ways to fix this, one is to disable app nap
> > > entirely. You can add this to Info.plist.in:
> > >
> > > +  <key>LSAppNapIsDisabled</key>
> > >  +    <string>True</string>
> >
> > Are you able to provide a patch for this? I've tried but it doesn't seem
> > to make any difference, so I expect I'm doing something wrong.
>
> Hi Aaron,
>
> I know this is ancient, and I don't know if it's still relevant any
> more, but I've discovered that after making a change to Info.plist you
> have to run:
>
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
> -v -f nextstep/Emacs.app
>
> for it to take.
>
> I have no idea what that is doing.
>
> I found it while trying to work out how to fix PATH issues with native
> compilation and running Emacs from Finder.

Interesting, thanks. I'm not even sure what I'm doing for this now. I
haven't had this problem in a while, so we must have fixed it along
the way.