* bug#22993: 25.0.92; OS X app nap slows down tty emacsclient @ 2016-03-12 6:07 Aaron Jensen 2016-03-12 8:03 ` bug#22993: Potential fix/workaround for 22993 Aaron Jensen 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jensen @ 2016-03-12 6:07 UTC (permalink / raw) To: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-03-12 6:07 bug#22993: 25.0.92; OS X app nap slows down tty emacsclient Aaron Jensen @ 2016-03-12 8:03 ` Aaron Jensen 2016-06-10 18:40 ` Alan Third 2016-06-15 20:35 ` Alan Third 0 siblings, 2 replies; 20+ messages in thread From: Aaron Jensen @ 2016-03-12 8:03 UTC (permalink / raw) To: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-03-12 8:03 ` bug#22993: Potential fix/workaround for 22993 Aaron Jensen @ 2016-06-10 18:40 ` Alan Third 2016-06-11 15:51 ` Aaron Jensen 2016-06-15 20:35 ` Alan Third 1 sibling, 1 reply; 20+ messages in thread From: Alan Third @ 2016-06-10 18:40 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-06-10 18:40 ` Alan Third @ 2016-06-11 15:51 ` Aaron Jensen 2016-06-11 16:19 ` Alan Third 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jensen @ 2016-06-11 15:51 UTC (permalink / raw) To: Alan Third; +Cc: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-06-11 15:51 ` Aaron Jensen @ 2016-06-11 16:19 ` Alan Third 2016-06-11 16:23 ` Aaron Jensen 0 siblings, 1 reply; 20+ messages in thread From: Alan Third @ 2016-06-11 16:19 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-06-11 16:19 ` Alan Third @ 2016-06-11 16:23 ` Aaron Jensen 0 siblings, 0 replies; 20+ messages in thread From: Aaron Jensen @ 2016-06-11 16:23 UTC (permalink / raw) To: Alan Third; +Cc: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-03-12 8:03 ` bug#22993: Potential fix/workaround for 22993 Aaron Jensen 2016-06-10 18:40 ` Alan Third @ 2016-06-15 20:35 ` Alan Third 2016-06-16 13:47 ` Aaron Jensen ` (2 more replies) 1 sibling, 3 replies; 20+ messages in thread From: Alan Third @ 2016-06-15 20:35 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-06-15 20:35 ` Alan Third @ 2016-06-16 13:47 ` Aaron Jensen [not found] ` <57629b7f841b1a0000aa4164@polymail.io> 2021-07-01 20:47 ` Alan Third 2 siblings, 0 replies; 20+ messages in thread From: Aaron Jensen @ 2016-06-16 13:47 UTC (permalink / raw) To: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <57629b7f841b1a0000aa4164@polymail.io>]
* bug#22993: Potential fix/workaround for 22993 [not found] ` <57629b7f841b1a0000aa4164@polymail.io> @ 2016-07-03 9:19 ` Alan Third 2016-07-03 17:23 ` Aaron Jensen 0 siblings, 1 reply; 20+ messages in thread From: Alan Third @ 2016-07-03 9:19 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-03 9:19 ` Alan Third @ 2016-07-03 17:23 ` Aaron Jensen 2016-07-07 18:55 ` Alan Third 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jensen @ 2016-07-03 17:23 UTC (permalink / raw) To: Alan Third; +Cc: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-03 17:23 ` Aaron Jensen @ 2016-07-07 18:55 ` Alan Third 2016-07-07 19:08 ` Aaron Jensen 0 siblings, 1 reply; 20+ messages in thread From: Alan Third @ 2016-07-07 18:55 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993-done 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-07 18:55 ` Alan Third @ 2016-07-07 19:08 ` Aaron Jensen 2016-07-07 19:09 ` Aaron Jensen 2016-07-07 19:57 ` Alan Third 0 siblings, 2 replies; 20+ messages in thread From: Aaron Jensen @ 2016-07-07 19:08 UTC (permalink / raw) To: Alan Third; +Cc: 22993-done [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-07 19:08 ` Aaron Jensen @ 2016-07-07 19:09 ` Aaron Jensen 2016-07-07 19:57 ` Alan Third 1 sibling, 0 replies; 20+ messages in thread From: Aaron Jensen @ 2016-07-07 19:09 UTC (permalink / raw) To: Alan Third; +Cc: 22993-done [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-07 19:08 ` Aaron Jensen 2016-07-07 19:09 ` Aaron Jensen @ 2016-07-07 19:57 ` Alan Third 2016-07-08 5:29 ` Aaron Jensen 1 sibling, 1 reply; 20+ messages in thread From: Alan Third @ 2016-07-07 19:57 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-07 19:57 ` Alan Third @ 2016-07-08 5:29 ` Aaron Jensen 2016-07-10 9:53 ` Alan Third 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jensen @ 2016-07-08 5:29 UTC (permalink / raw) To: Alan Third; +Cc: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-08 5:29 ` Aaron Jensen @ 2016-07-10 9:53 ` Alan Third 2016-07-10 15:38 ` Aaron Jensen 0 siblings, 1 reply; 20+ messages in thread From: Alan Third @ 2016-07-10 9:53 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-10 9:53 ` Alan Third @ 2016-07-10 15:38 ` Aaron Jensen 2016-07-10 16:11 ` Alan Third 0 siblings, 1 reply; 20+ messages in thread From: Aaron Jensen @ 2016-07-10 15:38 UTC (permalink / raw) To: Alan Third; +Cc: 22993 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-07-10 15:38 ` Aaron Jensen @ 2016-07-10 16:11 ` Alan Third 0 siblings, 0 replies; 20+ messages in thread From: Alan Third @ 2016-07-10 16:11 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2016-06-15 20:35 ` Alan Third 2016-06-16 13:47 ` Aaron Jensen [not found] ` <57629b7f841b1a0000aa4164@polymail.io> @ 2021-07-01 20:47 ` Alan Third 2021-07-02 17:43 ` Aaron Jensen 2 siblings, 1 reply; 20+ messages in thread From: Alan Third @ 2021-07-01 20:47 UTC (permalink / raw) To: Aaron Jensen; +Cc: 22993 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22993: Potential fix/workaround for 22993 2021-07-01 20:47 ` Alan Third @ 2021-07-02 17:43 ` Aaron Jensen 0 siblings, 0 replies; 20+ messages in thread From: Aaron Jensen @ 2021-07-02 17:43 UTC (permalink / raw) To: Alan Third, Aaron Jensen, 22993 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2021-07-02 17:43 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-12 6:07 bug#22993: 25.0.92; OS X app nap slows down tty emacsclient Aaron Jensen 2016-03-12 8:03 ` bug#22993: Potential fix/workaround for 22993 Aaron Jensen 2016-06-10 18:40 ` Alan Third 2016-06-11 15:51 ` Aaron Jensen 2016-06-11 16:19 ` Alan Third 2016-06-11 16:23 ` Aaron Jensen 2016-06-15 20:35 ` Alan Third 2016-06-16 13:47 ` Aaron Jensen [not found] ` <57629b7f841b1a0000aa4164@polymail.io> 2016-07-03 9:19 ` Alan Third 2016-07-03 17:23 ` Aaron Jensen 2016-07-07 18:55 ` Alan Third 2016-07-07 19:08 ` Aaron Jensen 2016-07-07 19:09 ` Aaron Jensen 2016-07-07 19:57 ` Alan Third 2016-07-08 5:29 ` Aaron Jensen 2016-07-10 9:53 ` Alan Third 2016-07-10 15:38 ` Aaron Jensen 2016-07-10 16:11 ` Alan Third 2021-07-01 20:47 ` Alan Third 2021-07-02 17:43 ` Aaron Jensen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.