On Sat, Mar 22, 2025 at 12:42 AM Christopher Stacy wrote: > > On 3/21/25 7:48 PM, Ship Mints wrote: > > > On Fri, Mar 21, 2025 at 19:44 Christopher Stacy wrote: > >> >> On 3/21/25 7:32 PM, Ship Mints wrote: >> >> >> On Fri, Mar 21, 2025 at 19:29 Christopher Stacy wrote: >> >>> >>> On 3/21/25 7:16 PM, Ship Mints wrote: >>> >>> On Fri, Mar 21, 2025 at 7:11 PM Christopher Stacy >>> wrote: >>> >>>> On 3/21/25 6:32 PM, Ship Mints wrote: >>>> >>>> On Fri, Mar 21, 2025 at 6:16 PM Christopher Stacy >>>> wrote: >>>> >>>>> Yes, I forgot to say: This is all about fullscreen frames. >>>>> >>>>> You never use them. I use fullscreen exclusively, for Emacs. >>>>> >>>>> When I am in Emacs (which is all day every day), I just want Emacs in >>>>> front of me. No menu bars, titlebars. or anything! >>>>> >>>>> :) >>>>> >>>>> Firefox does the stupid effect in full screen mode, too, turns out. >>>>> So we can't look there for the answer. >>>>> >>>>> I don't think the correct solution is to change a setting on the OS, >>>>> since railwaycat Emacs does the right thing without external >>>>> adjustments. >>>>> >>>>> This bug is in fact what has kept me on his hacked Emacs all these >>>>> years. But due to other bugs I have been forced to upgrade to Emacs >>>>> 30, >>>>> and I don't think he's going to update from 29. >>>>> >>>> >>>> Looking at nsfns and nsterm 29.4 vs. 30.1 I don't see anything that >>>> stands out. >>>> >>>> Where did you get your 29.4 and 30.1 builds? >>>> >>>> The bugs forcing me to upgrade to 30.1 are entirely unrelated to >>>> windowing. (Just other things that were broken and recently fixed.) >>>> >>>> Windowing system distributor 'Apple', version 10.3.2113 >>>> System Description: macOS 12.7.6 >>>> >>>> Emacs 29 is the railwaycat version from Homebrew. >>>> This has the behavior that I want (no effects). >>>> brew tap railwaycat/emacsmacport >>>> Which supposedly comes from: >>>> https://github.com/railwaycat/homebrew-emacsmacport >>>> GNU Emacs 29.1 (build 1, x86_64-apple-darwin20.6.0, Carbon Version 164 >>>> AppKit 2022.7) of 2023-08-08 >>>> >>>> Emacs 30.1 I got from: https://emacsformacosx.com/ >>>> (I wish I knew who that entity is. I wonder if it has malware.) >>>> GNU Emacs 30.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 >>>> Version 10.14.6 (Build 18G9323)) of 2025-02-24 >>>> >>>> Is there an easy way to tell what compiler options were used on these >>>> builds? (Maybe some emacs command will tell me?) >>>> >>> It doesn't really take much effort to click around Caldwell's site and >>> find out more. You should. >>> >>> What is a "Caldwell"? >>> >> >> You'll see. >> >> Not if I don't have the URL. >> I have no idea what you're talking about. >> > > You gave it to us > https://emacsformacosx.com/ > > There is nothing on that web site pertaining to the Emacs bug I am > reporting here. > Christopher, at this point, it should be apparent that if you are not using vanilla GNU Emacs, and have chosen a build you haven't yourself made, that you need to dig into that build yourself--it's your responsibility and especially if you are concerned about "supply-chain" issues. If you "clicked around" the emacsformacosx.com site as I suggested rather than just reading it, you would have wound up here https://github.com/caldwell/build-emacs and you can see for yourself what's going on with the build you chose. Did you try the alternative build https://github.com/jimeh/emacs-builds/releases/tag/Emacs-30.1 I suggested for comparison? That's the build I use when not compiling my own. Both Caldwell's and jimeh's builds apply patches that are not in the supported GNU Emacs source. Until you put in a little more work on your own, it's not clear this is a bug in GNU Emacs. I also suggest that you attempt to replicate the behavior when running "emacs -Q". You cannot do that from the macOS launcher so run the binary directly from its location. -Stephane