-
dotfiles
My dotfiles: macOS, OpenBSD, Linux. Setup: git init; git remote add github https://github.com/rollcat/dotfiles; git pull github master (by rollcat)
I have a love-hate relationship with Emacs.
The defaults are absolutely awful. The editor is pretty unusable without at least a hundred lines of ELisp: basic stuff like CUA, setting up fonts, disabling useless UI clutter, delete-selection-mode, rebinding a couple keys, setting up packages, explaining where to find coreutils on BSD systems, etc. And then you get to packages.
If you want to do anything remotely useful, you're gonna have to start installing random stuff from GNU ELPA, MELPA, etc. There's no package pinning or SemVer so you get what you get, packages sometimes break in mysterious ways. So you write more code to work around various broken stuff in packages.
I've gone through several iterations of throwing away my entire init.el and starting from scratch with just the bare minimum needed to get work done. At the current iteration, ELisp is still ~33% of all source code volume in my dotfiles repo[0]. I haven't pushed my latest effort to unbreak "jump to definition" (because apparently dumb-jump is deprecated??? and I need to use xref??? but it doesn't work???) so that'll likely go up.
I never wanted to write enough ELisp to justify calling it a program, but Emacs made me.
But then there is magit[1], which is so damn good, it makes every other VCS interface look like a sad joke. Which is problematic, because configuring Emacs itself is a bit of a sad joke. I want to just write code, not write code to make just writing code less of a pain. :(
[0]: https://github.com/rollcat/dotfiles
[1]: https://magit.vc
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I've not used Sublime Text, but I think treemacs fits what you are looking for
https://github.com/Alexander-Miller/treemacs
-
I have a love-hate relationship with Emacs.
The defaults are absolutely awful. The editor is pretty unusable without at least a hundred lines of ELisp: basic stuff like CUA, setting up fonts, disabling useless UI clutter, delete-selection-mode, rebinding a couple keys, setting up packages, explaining where to find coreutils on BSD systems, etc. And then you get to packages.
If you want to do anything remotely useful, you're gonna have to start installing random stuff from GNU ELPA, MELPA, etc. There's no package pinning or SemVer so you get what you get, packages sometimes break in mysterious ways. So you write more code to work around various broken stuff in packages.
I've gone through several iterations of throwing away my entire init.el and starting from scratch with just the bare minimum needed to get work done. At the current iteration, ELisp is still ~33% of all source code volume in my dotfiles repo[0]. I haven't pushed my latest effort to unbreak "jump to definition" (because apparently dumb-jump is deprecated??? and I need to use xref??? but it doesn't work???) so that'll likely go up.
I never wanted to write enough ELisp to justify calling it a program, but Emacs made me.
But then there is magit[1], which is so damn good, it makes every other VCS interface look like a sad joke. Which is problematic, because configuring Emacs itself is a bit of a sad joke. I want to just write code, not write code to make just writing code less of a pain. :(
[0]: https://github.com/rollcat/dotfiles
[1]: https://magit.vc
-
-
prelude
Prelude is an enhanced Emacs 25.1+ distribution that should make your experience with Emacs both more pleasant and more powerful.
-
> (For example, when trying to test things out I haven't really found a way much better than typing into scratch, selecting code and running it while staring at messages....)
Are you talking about when you're noodling, trying to figure how things work, or actually trying to build something?
For playing around, I found that scratch works ok, but I found a better workflow.
I end up using a daily note in org-roam, with #begin_src elisp... I then tag the heading with :REFILE:ELISP: so I can always find it later. Basically evaluate everything inline within that org-babel block.
When I'm building something, or driving towards a specific goal, I use buttercup [0] to write actual unit tests. If I squint, it kinda looks like TDD.
Finally, for debugging of running elisp, take a look at edebug [1]. It's a pretty standard looking debugger (if you used something like gdb). By default emacs uses debug which is not as friendly.
[0]: https://github.com/jorgenschaefer/emacs-buttercup
[1]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed...
-
> I'd say that's kinda a big selling point of Emacs though: you can write elisp code to make anything you do (not just writing code) less of a pain.
I agree in principle, but in practice, I find myself writing a lot of ELisp just to work around Emacs' shortcomings. E.g. on macOS, to support dark/light theme switching integrated with the rest of the system, I need an external program[0], a shell script to tell that program to call emacsclient, a LaunchAgent to keep it running, an unholy build of Emacs with all of the GNU-unapproved Cocoa integrations that some kind soul is maintaining, and only THEN a piece of ELisp (which is also calling out to AppleScript) to actually change the theme[1]. And as I wrote this, I realised half of this glue didn't even make it into version control.
[0]: https://github.com/cormacrelf/dark-notify
[1]: https://github.com/rollcat/dotfiles/blob/7f6a6d7/.emacs.d/in...
I've been using Emacs for about 20 years, and with every passing year I just wish there was *less* ELisp for me to think about. The actual useful customisations (like adding the +x bit on shell scripts) are few and far between, most of it is just glue and fixes.
