configuration VS use-package

FWIW I have this little Perl script that fetches BibTeX from doi.org for DOI numbers: https://github.com/cadadr/configuration/blob/76466b1342aaadfddf3453ab70ada4a15e82afbb/bin/doi2bib.pl I searched a lot for a way to make something similar for ISBN -> BibTeX to no avail...

If you're writing LaTeX without using any supporting software, it will be harder. But there are some things that you can use to make life way easier. One of these is the concept of "snippets". In Emacs I use something called yasnippet, and it works like this: I define a snippet like this or even something more elaborate like this. They have "trigger words". E.g. for the second one, I type "report" in a file and hit TAB. It inserts all that "snippet" to the file, and I can edit parts marked as $1, $2 and similar, jumping between them using TAB. I use this with Org mode, which is like Markdown, so it's not much different from typing into Word, essentially. There's some initial work figuring out how to do something like a syntax tree or say an equation, but once you figure a pattern out you can make it into a template using snippets and it's easier than Word once you have that.

There are some examples in my init.el, you can find them if you search for :after.

The way I do python is, I've a proxy shell script which I set as the python interpreter in Emacs.

One particular thing I can suggest for equations is dynamic latex equation previews, which toggles TeX source when the cursor is on an equation but when it goes out of it it toggles a rendered preview. See this and this, adapted from this).

Wrt LSP specifically, I only use it with python and the whole config is this couple lines plus this hook. IDK how lsp-mode is configured but this works fairly well for me, and actual Python config is a bit more cumbersome (because Microsoft comes up with a new Python LSP package every other day and you can't know which one to deal with...). It hooks into Emacs' complete-symbol (i.e. C-M-i), so if company or whatever (sorry, I don't really know those packages well, there was auto-something too but IDK which one is better or recommended these days) does use that mechanism as a backend, it should work seamlessly. I've made these little bindings to quickly pick a completion from the *Completions* window (gk-interactively is just a macro that expands to (lambda () ). Again, eglot hooks into Emacs' completion mechanism, so I'd risk a guess that helm or ivy would just work with that. Personally I don't like these completion frameworks because again they look to me like they are somewhat useful but not enough to warrant their complexity. I like good old completing-read, with some modern configuration (and BTW the UI Semantics section that bit is in in my init.el contains a lot of what you could call "saner defaults"). Notably they've added some very neat structural and fuzzy matching abilities starting with 25.1 IIRC and I don't even feel the need to turn ido on when those features are enabled.

I have a little project system that I use a lot and is a life saver: https://github.com/cadadr/configuration/tree/3e11ef25344188cc55b16f314c3c5358ace8a266/emacs.d/init.el#L1249 It's simple but it's very helpful. I like to have a project command view with dired at root on the left and magit or vc.el on the right, and I can go back to that view with a single command, gk-home, bound to the Home key. Popping a shell at bottom like yakuake with a single keybinding to gk-pop-shell is very useful too. I use frame parameters to tie projects up with frames so these two functions know what to do in each project frame. Titles are set up such that it's easy to find a particular frame with something like Rofi.

Depends on what you want to do. Linux is a more welcoming environment for programmers and an OS-level package manager is very helpful. I have one big repo for all my configs, and if my computer failed today I can get up and running on anything else in a couple hours, typing a few commands only. With Windows it's always a manual process and takes longer. And sometimes Windows makes some programmers' tasks too hard, like setting environment variables, etc. And more advanced things like scripting, virtualisation, containers, etc. are generally easier to do in Linux.

E.g. a very important detail IMHO is the active vs. inactive modelines. In your light theme they are virtually the same, so you need to chase the cursor to find the active window. The first thing I modify in themes I use is to make modeline colours such that inactive one is faded but still legible, and active modeline really stands out: https://github.com/cadadr/configuration/blob/bf8b87c36dbab85d1ec35f3c9aa6f7d3c5e1f347/emacs.d/init.el#L5842 In general if you're not limited by a palette it's easier to adjust everything perfectly.

Another way would be to redefine parts of the bind-key macro or its use-package support functions

The package-install call installs use-package that provides a utility of the same name to make it easier to manage packages. It's admittedly a little overkill for this specific config, but it's a cheap investment that sets you up for later success.

Granted, the Doom macro makes your code looks nice and compact. But you can get very close to that just by using do-list and define-key together. Or by using the bind-key.el package, which is included with Use-package.

> Deps is well documented.

> The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool.

This strikes me as a contradiction, because if it was well documented you wouldn’t need to look at other people’s configs to see how to use it.

My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them.

I still don’t know how to reliably configure a project to use nrepl or socket repl without just using an editor plugin. I definitely have no idea how to use those in conjunction with a tool like reveal.

To me, none of that is simple. Simple would be like Emacs’ use-package. With that I know how to add dependencies, specify keybinds, and do initialization and configuration off the top of my head. And it has really nice documentation with tons of examples.

https://github.com/jwiegley/use-package

Since you are doing code development, the first things to go for would be setting up your emacs packaging (installing use-package and melpa (use-package's documentation covers this) so you have more packages to choose from (do be careful to not just pick things willy nilly but research them a bit first)) and then setting up lsp-mode. lsp-mode lets you use LSP servers for the specific programming languages you work with in a somewhat unified fashion. You then need to install and setup the LSP servers for the languages you use, and possibly install language specific Emacs packages as support (note, Emacs has builtin functionality for many).

I'm using use-package as my package manager and the package ligature for the ligatures.

I have been crafting my emacs config for about 10 years. I started with vanilla and intentionally stayed away from frameworks. About two years ago I declared config bankruptcy and went down for a rewrite using use-package and straight.

ref: https://github.com/radian-software/straight.el https://github.com/jwiegley/use-package

use-package! is a macro over use-package, and respect its syntax, with a few additions. Useful reference on use-package keywords.