math-delimiters VS emacs-config

math-delimiters. Provides a nice command to insert LaTeX math delimiters and to toggle between inline and display versions of them.

(use-package math-delimiters :vc (:url "https://github.com/oantolin/math-delimiters" :rev :newest))

I use the math-delimiters package for this. It has a command you bind to $. Pressing it once inserts \(\) and leves point in the middle. Pressing it a second time changes those to \[\]. If you had an active region at the time, it will wrap that region in the delimiters. If you press $ after the closing delimiter it will switch to the other kind of delimiter and will take care of tucking punctuation in or out. I use it both in Org and LaTeX buffers.

In terms of LaTeX entry, I make heavy use of CDLaTeX (config), math-delimiters, latex-change-env (expository blog post here), as well as aas (config) (as well as many macros, of course!). I also have a few interesting-ish functions that e.g. automatically insert dollars around single characters, so that writing long documents is more ergonomic; I've written about these things a little bit here (this also showcases the preview feature of AUCTeX, which I quite like), and here.

One more excellent tool for text input is /u/oantolin's math-delimiters package; it can be used to toggle from inline to display math (which is a feature that I've found myself using quite often while editing).

You may be interested in my math-delimiters package. It defines a command math-delimiters-insert which you should bind to $. That single command is all you need to insert math delimiters, toggle them between inline and display math, and wrap an active region in math delimiters. Thanks to a recent addition by u/slinchisl it even handles moving ending punctuation in and out of the delimiters when toggling between inline and display math.

block-undo. Have keyboard macros undo in a single step (something vi gets right!).

Installing that Embark key series implementation I mentioned above, to get extra actions for key series such binding them to a key or turning them into named keyboard macros.

Generally I recommend to maintain all personal code in the form of tiny but proper Elisp libraries. The config just glues everything together using use-package/setup/your-self-baked-macro. See also /u/oantolin's config which uses this style: https://github.com/oantolin/emacs-config. I cannot recommend this enough!

I have 3720 lines in my configuration. I try to write as much of it as tiny packages that I configure with use-package, just like I do for external packages. (I highly recommend this form of organization) Many of these are only useful to me, but some would be very reasonable to steal, like:

I have a slightly different take on this in my configuration, file shr-heading.el. In addition to imenu support I wanted next and previous heading navigation commands. It turns out you then get imenu support for free, since one way you can specify imenu entries is by providing a "goto previous imenu entry" function.

I wrote a small drag-region package once. You mark a region, turn on drag-region-mode and then your normal motion commands will drag the region along until you turn the minor mode off again. I never tested it with evil.

I'm very happy with ecomplete now, I mostly just need the completion and automatic storing of addresses I write to, as configured in your post. But occasionally I want to remove an address or manually add one, so I wrote a couple of commands to do that which I bind in embark-email-map to + (for adding) and \ (for removing). I don't think I've used these commands directly, always as Embark actions. When I want to add an email to ecomplete I usually have it written in some buffer already. And the command to remove an email I've only ever used from the ecomplete completion interface or from a message buffer after mistakenly having inserted it and realized that's an old address I'll never use again.

I keep some packages in a subdirectory my personal configuration and don't create a separate repo for them. (Also, not every file there is really a package that could be released: some don't follow proper naming conventions, or depend on details of my configuration).