homebrew-emacsmacport VS dotemacs

Run emacs -q (no add-ons loaded) and it should be a lot faster than VS Code. Which means that a library you loaded is the culprit. Things like Doom Emacs are notorious for unexpected slowness since they're not very well put together and load questionable libraries.

In the unlikely case where emacs -q is still slow, use Emacs Mac Port (https://github.com/railwaycat/homebrew-emacsmacport/releases...).

This is at least 2x perceivably faster than VS Code on Mac.

Important note: I learned that apparently not all Emacsen properly support :stipple (despite happily accepting it as a face attribute). Linux/UNIX is safe, emacs-mac supports it on MacOS, but Windows may not at all (untested). Also, terminal emacs does not (to my knowledge) implement :stipple. Let me know how you fare. Update: Pure GTK emacs apparently does display stipples, but incorrectly (as an inverse mask).

I don't use macOS anymore, but the best port I found for speed was https://github.com/railwaycat/homebrew-emacsmacport

There is the code to do just that. Works with emacs-mac and emacs-plus.

There's the "Mac" version, from Mitsuharu Yamamoto or railwaycat. The Mac port works more like Mac than the NextStep port. And it looks like the Mac port does work with C-f4.

Homebrew

You can install emacs-mac by homebrew (see https://github.com/railwaycat/homebrew-emacsmacport). $ brew tap railwaycat/emacsmacport $ brew install emacs-mac This emacs contains mac-win.el. Mac Auto ASCII mode in the mac-win.el automatically selects the most-recently-used ASCII-capable keyboard input source on some occasions: after prefix key (bound in the global keymap) press such as C-x and M-g, and at the start of minibuffer input. This function is very useful. I guess you can read Japanese, please visit Japanese setup page of my website (https://taipapamotohus.com/post/japanese\_setup/).

For what it's worth, the emacs-mac port provides a mac-effective-appearance-change-hook hook to do the same thing as the System appearance change plugin. I use it like this:

Here's my mu4e setup

7 - Meow: Meow is great. I switched from evil a few months ago and am pretty happy with it. I also dropped general.el for bind-key.el, which is included with use-package (which I see you are using anyway). You can look at my setup of meow here and a more generic setup of keybindings here. I haven't had any trouble with using this instead of general.

One thought is to limit which parts of the org-cite libraries to load. I had similar issues with speed. You can look at my current setup in my dotfiles here. I just use oc and oc-csl, along with citar (no org-ref) and everything works pretty well.

Here’s the link: https://github.com/mclear-tools/dotemacs

Another thing you might consider (this depends on how many tabs you usually keep open, etc.) is not displaying tabs in the tab-bar at all (setq tab-bar-show nil) and displaying them in the echo-area instead. I use a combination of https://github.com/fritzgrabo/tab-bar-echo-area and https://github.com/qaiviq/echo-bar.el to give a consistent but very unobtrusive presentation of the tabs in the echo bar on the bottom right. You can see that in this image -- and my config for it is here.

Yes. It’s not a problem (it’s also easy to write papers in markdown using markdown mode). If you want to see some of the packages involved look at my setup-writing.el file in my config.

If you just want folding then you can use emacs' built-in outline mode. And there are very easy ways to jump around a "modular" or multi-file config as well. I use both of these tools in my own config. I also like that I can easily load just small parts of my config via command line args, and of course that I don't need to worry about bootstrapping org-mode to get things running.

You can take a look atmy setup and see if any of it looks helpful. The relevant modules for you will be:

Yeah +1 for perspective.el. I use it with projectile to manage projects and have discrete buffers for different projects. You can look at my setup if it is helpful here.