Rework the way emacs is launched
The commits 15ce6a9e...a5756023 tackle the large task of finding a way to have emacs launch in daemon mode, so it can be used with emacsclient for very fast load times, and opening files in pre-existing windows code -r style, among other things. Because of how hastily it was thrown together, however, it's produced quite a few badnesses along the way.
Ultimately, one of the more annoying bits of this is how I currently handle launching emacs. This is kinda annoying in a couple of facets:
- emacs doesn't draw properly in terminal mode since I overrided the terminal-detection stuff in my doom theme to have my theme work better for graphical emacs clients, making small vim-like commandline edits very difficult.
- A proper terminal UI is being sketched out in issue #32, this issue primarily focuses on the conflict between terminal styling and emacsclient-frame styling.
-
Using my alis/bash-script/thing to launch emacs with other files feels clunky, because of bugs like #42 (closed), where centaur-tabs completely breaks whenever I open files outside of the current treemacs workspace. This makes the whole "open files quickly by just doingemacs <thefile>to suck up a file into the frame" advantage kinda useless.
This is partially ammended since I uninstalled treemacs for neotree, as documented in #54 (closed).Even if the emacs did launch with out-of-workspace buffers properly, it'd still likely be a bit clunkey. Ultimately, we really just want thevscode-like behavior that allowed me to just open a directory, and have the directory tree to the left.
- Ideally, I'd like to be able to have multiple emacs windows open for each project. The problem is, since they're all interacting w/ the one server, one might change the environment for the other (which isn't super desirable). Things like windows, buffers, etc, stick around when I don't really want them to.
Edited by MyriaCore