I don't have a handle on your broader question but I've used the following snippet for years to get full screen on MacOS. (I use Mituharu Yamamoto's emacs-mac port, in case that matters.)

(set-frame-parameter
   nil 'fullscreen
   (when (not (frame-parameter nil 'fullscreen)) 'fullscreen))

Okay I'll take a look at this. Thanks for the tip

I chased the internet and tried different distributions on MacOS (which I use at work), to make sense of Emacs frames there, I ended up settling for: • frame maximised at startup (was already my default, but it helps anyway) via (add-to-list 'default-frame-alist '(fullscreen . maximized)); • when I use more monitors (almost always), there's another issue after resuming after screen locks: Emacs frames (and a lot of other program windows) go to the smaller Mac screen, so I drag it back to the bigger monitor, then resize it with a custom binding which invokes toggle-frame-maximized , a couple of toggles do the trick (just realised now I could improve with with 2 toggles in 1 stroke :rolling_on_the_floor_laughing: - I'll check also the approach suggested above in the previous message). If there's a better way, I'm all ears 🙂 In general the window resizing behaviour in that OS is insane, is not an Emacs specific issue (somehow Finder manages to behave even worse, just to name one). I hear a lot of people get around it installing extensions you have to pay for, personally I couldn't be bothered. Command key, my main "issue" was setting it positioned as it is on Linux/Windows, not sure this is what you're aiming to as well.

(setq mac-option-modifier 'meta)
(setq mac-command-modifier 'super)
(setq ns-function-modifier 'hyper)

So I discovered what my issue was last night. I was thinking that it was a distribution issue but it was not so simple. the railwaycat/homebrew-emacsmacport and (if (fboundp 'menu-bar-mode) (menu-bar-mode -1)) together caused a weird side effect that would change the way double-click works when clicking the window banner in macOS. the default behavior from my testing with emacsformacosx is the first double-click would full height the window then a second double-click would full-width the window then a third would reset the window and then my green bubble would be the correct arrows. when I would run the above fn then it would change my green button to a +`

testing all the same stuff with the railwaycat/homebrew-emacsmacport everything was completely different and out of the box i didn't get a full-width double click and my green fullscreen bubble worked just as expected with the fullscreen arrows. but if I ran the about fn then my green button would change to the + rather than the fullscreen arrows. I ended up finding it easiest to use some of the functions y'all supplied and change the default full screen/maximize from using the function keys to a custom keybind. and i could just use whichever osx build that i want

thanks for the functions y'all suggested and mentioned cause that helped me choose something that would work for either osx build and something i find comfortable to use

I don't know if it's related or not, but recently the typing latency in markdown-mode has gotten noticeably worse for me as well

I use the current https://github.com/bbatsov/adoc-mode (now maintained by our own @U051BLM8F!) and have not noticed a slowdown yet. Not entirely sure, but I might be using master HEAD (I use doom-emacs and added it via packages.el). But... I also tend to edit adoc in Visual Studo Code because it has a convenient preview feature that I like.

I moved to Visual Code now, because I didn't want to put in the effort to figure out the root cause

Might be something to do with the font-locking changes we’ve been doing recently - e.g. the introduction of native code block fontification.

See https://github.com/bbatsov/adoc-mode#native-syntax-highlighting-of-source-code-blocks

I haven’t noticed any slowdown myself, though.

I've just felt the adoc-mode slowdown myself when editing https://github.com/clj-commons/etaoin/blob/master/doc/01-user-guide.adoc if any interested party wants to give that a whirl. I only notice a huge lag (maybe sometimes 1s?) when editing larger code blocks like this one: https://github.com/clj-commons/etaoin/blob/4cf633f41b928cf81ff870ee680f7a7038677b1c/doc/01-user-guide.adoc?plain=1#L235-L309 @U051BLM8F would you like me to raise an issue?

@UE21H2HHD Sure!

Ok, that was a bit of a learning curve for this emacs elisp neophyte, but issue raised: https://github.com/bbatsov/adoc-mode/issues/33

@U04V15CAJ was your slowdown experience similar to mine? TLDR; keystroke lag when editing in larger code blocks?

I think so yes