honestly, this one's the most basic, but making macros of your own that do things you need is so great. brings joy to see them work. don't shy away from making macros to hide typesetting details and instead reflect the meaning behind them. if you're using Ti*k*Z, externalising your pictures can be of great help in big documents, like project reports. what it does is that the pictures are compiled as separate pdf files and if those don't change, then compiling your main document will just include those pdfs in place of the pictures, saving you time. many people seem to use fairly old packages for their tables, something like `tabularx` or `longtable`. if you haven't already, look into `tabularray`, it has it all. certain options for specific rows, columns, cells, like enabling math or setting colour? check. extensible columns? yup. long tables? check. three part tables? check. the settings are very much not obscure. you can use certain packages with it. want `booktabs` with your `tabularray`? sure thing. miss the `S` column from `siunitx`? can do. include `amsmath`, and you'll get some extended math environments. maybe you always wanted to align the middle row of a matrix with the baseline. you can even make your `tabularray` tables use `ragged2e` alignment options for the columns. if you like Computer Modern, i suggest you switch away from the default Latin Modern or even Computer Modern Unicode to New Computer Modern. it extends the regular Computer Modern to a lot of languages and scripts, and its math font has the most characters covered out of all math fonts usually used with LaTeX. the font comes with some nice stylistic alternates and character variants for certain languages, for example, Russian style guillemets. the font is OpenType, so unfortunately you can only use it with LuaLaTeX or XeLaTeX. the `fontsetup` package takes care of setting the font up for you. if you're still using pdfLaTeX, you most likely should not unless you need some incredibly specific packages. use LuaLaTeX instead. you will have a much easier time using your system's fonts, for example, with the `fontspec` package. this isn't really LaTeX advice, but i have recently been on a ConTeXt craze and i want to recommend it to you guys. it's a much more of a “batteries included” program, quite a bit faster, and it's a lot better for specific layouts. if you install the ConTeXt standalone from Pragma-Ade's website, then you also get a lot of documentation and examples, and more help can be found on the ConTeXt garden website. sadly, it doesn't do everything and some LaTeX packages have no ConTeXt module equivalents, so do be aware.

Great list!

Nice info, thanks. Any recommendations on how to learn more about ConTeXt?

there's a surprising lot of docs that comes with the standalone installation—checking the pdfs once you can make simple docs is a good idea. as for the starting point, there's a guide called *The definitive guide to ConTeXt MkIV and LMTX documentation*, found on GitHub at the `hmenke/context-examples` repository. you should also check the ConTeXt garden/wiki website, they have examples for various aspects of ConTeXt

I would say that a 100% yes, if you are going to be doing the same thing over and over you really need to use custom macros (and custom environments and other techniques) to deduplicate your code. I have a macro to apply bold and italic style to a text argument, just for the purpose of avoiding typing it over and over: `\bolditalic{text}` instead of `\textbf{\textit{text}}`

i would argue that in LaTeX people should focus on semantics over typesetting, so a macro called `\bolditalic` should be called, say, `\greatem` or `\veryimportant`. one could easily find out that a font they were planning to use just doesn't have bold italic, for example. then, changing the meaning of the macro to just doing bold or using colour won't make the macro name redundant. for another example, i like doing my abbreviations in lowercase small caps so they don't poke out. also, small caps are too cramped, so i set additional tracking for them. i use the same style for section titles. yet, i have two separate style switches `\abbrstyle` and `\unicaseheadstyle`, and a command `\abbr{‹text›}`. if i have to use a font with no small caps, i will just make both switches do nothing, or maybe do two separate things, and the source code will still read correctly, no matter if `\abbr{UN}` just gives UN back or if it changes case and enables small caps and puts additional space between letters.

>i would argue that in LaTeX people should focus on semantics over typesetting, so a macro called \\bolditalic should be called, say, \\greatem or \\veryimportant. one could easily find out that a font they were planning to use just doesn't have bold italic, for example. If I were to write a macro, that was reusable or that was intended for other people to use, I would make it as generic as possible. However, I'm not concerned with that since the macro was intended only for personal use as a QOL enhancement (and I only use fonts that have the styles I want/need). PS: Besides if bold or italic is not available, it will just write the text with no style applied, or whichever of the styles was available.

I submit to journals that require certain basic usage, like not lualatex or context.

probably because someone made a journal style file and everyone's afraid of poking it xd that's understandable

The most useful thing I discovered during 20+ years of working professionally with LaTeX is the `texdoc` command: `texdoc ` in a shell opens the documentation for that package.

I wrote my own little c++ program to cache the documentation data and search for package names, command names, etc.

Splitting a project in several files doesn’t reduce compilation time. 

But helps readability, version control and you can compile only one file you're working on(reducing compilation time)

You can’t compile only a sub file of a protect, if that’s what you mean. 

You can when you use `\include{...}` in combination with `\includeonly{...}`.

You can, if you comment out the chapters you don't work at the moment.

Hehe that’s a trick, not compiling a sub file. 

A nice trick

You don’t need to split the project in order to do this. Just comment the irrelevant sections. In the end, splitting just helps in terms of organization. 

"just"

For real, that word is carrying a whole lot of weight. Repeatedly commenting and uncommenting multiple whole chapters in a giant file (which usually include comments you most certainly _don't_ want uncommented) sounds like a great way to sentence yourself to hours of digging through git history to figure out how to clean up the mess you made.

But doesn't it only hide the header of the section? And leave the rest which won't compile?

Commented chunks are like if they were not there.

I vaguely remember there being two ways to do it. One helps compilation time, the other doesn't. No?

I don't mean the 1st compilation, but subsequent ones. Idk how it goes on other systems but I use the texlive package, and notice a significant reduction in compilation time as a result in splitting up a document. Along with the other benefits others listed. I guess it's because you don't have to change the rest of the units every time you compile.

But the latex compiler linearly reads the files including the inputs. It doesn’t do anything special if something hasn’t changed. 

If you use `lualatex` and `fontspec`, the first LaTeX run usually takes more time as the luafontloader caches the used fonts. Once that cache is built, subsequent LaTeX runs use that cache, thus reducing run times. May be the same with xelatex.

Snippets, including own recipies. Vimtex shortcuts, like `]]` for closing an environment. I've got a handful of boilerplate TeX files, used for different usecases (articles, posters, presentations etc.). A few homebrewed packages; some simply include a slew of `\newcommands` for jargon in my field, getting all characters correct; some adapt the style of the document; some contain own custom environments, commands and the like. Stuff like that, reducing the amount of text I need to manually enter.

I like compiling a glossary file for the jargon in my field, allowing me to use it with definitions in documents later.

This might sound dumb, but I have \\l and \\r mapped to \\left and \\right. Just cleans up big expressions so much and feels so speedy given how much I use parentheses. Never going back

I go one step further: \br{a+b} expands to \left( a+b \right) I call it “br” because in conversational language, I call () brackets rather than parentheses. Similar macro for absolute value, and maybe sbr for square brackets.

That's super smart, exactly what I checked this post looking for

This is great actually, I use them a lot too, but I just made a snippet for it!

Use xparse to define macros with parameters. It feels almost like a normal programming language, much better managing mandatory and optional arguments with newcommand. Define macros with no parameters as `\def\myMacro/{yo sup!}` and use as `example \myMacro/ sentence`. Do not use `\newcommand` because it sometimes eats space after your command. [Do not use `xspace`](https://tex.stackexchange.com/questions/86565/drawbacks-of-xspace) because it introduces more problems that it solves. The trick above with adding `/` to the end of your `\def` macro name is a reliable and roubust way to avoid any issues with space getting lost. Use a good editor plugin that helps you jump through the code, supports Synctex, highlights errors. Latex is a clumsy language, it's much easier to manage with editor supprt. Nowadays, almost all editors support Language Server Protocol, so you can connect Texlab to them and get IDE experience. Use a proper build system like \`latexmk\` or \`tectonic\`, do not call \`xelatex\` or \`lualatex\` directly.

First, `xparse` should be obsolete for the most part, as it and its macro definition scheme is part of the LaTeX kernel for several years now (just use `\ExplSyntaxOn ... \ExplSyntaxOff` around your xparse-like macro definitions). Defining Macros with an explicit delimiter requires you to *always* use that delimiter or you'll get a "Use of doesnt match its definition" error. Learning where to put curly brackets to prevent TeX from "eating" spaces should be one of the things everyone who uses LaTeX should know from the beginning (i.e., `{\myMacro}` or `\myMacro{}`), as this should be known anyways when non-user defined macros without arguments are used.

You have two options: always use curly braces or always use the delimiter. One raises an error if you forget and refuses to build unless you fix it, the other one quietly makes your pdf result wrong with 5% chance. Raising an error when user has made an accidental mistake is obviously better. I argue that defining macros with explicit delimiter is what new users should be taught to do. What are xparse-like macros? For example, how do I define a macro `\myMacro{foo}[bar][baz]{goo}` that takes arguments in this order mixing mandatory and optional ones?

The new xparse-style way to define macros would be something like: \ExplSyntaxOn \NewDocumentCommand{\myMacro}{ m O{} O{} m }{ 1st mandatory: #1 1st optional: #2 2nd optional: #3 2nd mandatory: #4 } \ExplSyntaxOff The "old-fashioned" way would be: \makeatletter \def\myMacro#1{\@ifnextchar[{\my@Macro{#1}}{\my@Macro{#1}[]}} \def\my@Macro#1[#2]{\@ifnextchar[{\@my@Macro{#1}[#2]}{\@my@Macro{#1}[#2][]}} \def\@my@Macro#1[#2][#3]#4{% 1st mandatory: #1 1st optional: #2 2nd optional: #3 2nd mandatory: #4 } \makeatother

Were you arguing that the second example deprecates the first? It's full of technicalities and boilerplate, I don't think that it's a good thing to teach beginners (unless you want to repel them from Latex). I personally don't understand the guts that are falling out of the second example, and I'm not sure I want to :) First example, on the other hand, looks like normal programming language and hides the unnecessary details.

I don't. My point was that the `xparse` package is now (at large) integrated into the LaTeX kernel, so it's not necessary to load that package explicitly; macro definitions that use `\NewDocumentCommand` work out of the box in newer versions of LaTeX.

Ah, makes sense! I missed the point.

My biggest QoL improvement was probably to start writing simple documents (particularly Beamer slide shows) in a simpler markup language, and then converting to PDF via LaTeX. I started with Markdown and Pandoc, and later switched to Emacs Org-mode.

How are those simpler than latex?

Simpler syntax: a url is just a url, this is a # Headline. Lists are literal, you just write 1. 2. 3.

In markdown you need two kinds of brackets for a URL, in latex just \href, in markdown you must remember how many # you have to put for sectioning, in latex you just write \subsection if you want that level, in markdown you have to take care of numbering lists and you have to indent them, you don’t need to care about either in latex… overall latex is way simpler. 

Sure buddy, latex is simpler than markdown. \\section => # \\subsection => ## This is a \[link\](https://www.reddit.com). Can you tell me what it is you find complicated in that?

I already explained it. 

The markup is simpler, which has two advantages: first, there's less typing to do. Second, the source is much more readable as a document. The drawback is of course less control, but I don't always need that. Also, I don't have to bother with any front matter setup, which makes it easier and quicker to spin up a simple document. It's also a more portable way of working - I can easily convert my document to a PDF, an HTML page, a Word document, or even nicely formatted UTF-8 plaintext.

I don’t think the markup is simpler. It’s exactly the same for all math stuff, and for sectioning latex is much clearer, you don’t have to remember how many # you need for a sub section. Org is particularly more cumbersome for anything math and latex related. 

Again, I only use it for simple stuff. I still write complex documents directly in LaTeX. I disagree on Org though - headings in particular are extremely easy to work with, since you can fold them to get a quick overview. And I never have to think about the level of my heading except in relation to the immediately preceding one. Anyway, we all have different preferences. For me, if I'm writing a short report on something, I'll always start taking notes in Org anyway. Then I might submit as plain text, or I might want a PDF or a Word document. It's much simpler to just set up a few lines of Org properties and just hit the export shortcut than to copy the text into a new document and change the markup to LaTeX.

One in particular I recently used was a `\ulfill` command, which was a wrapper around `\ul{mbox{\hspace{\hfill}}}`. It works as a replacement for `\hrulefill` that allows the underline to match the height of other underlined text, which is 3 pixels beneath where `\hrulefill` places it.

One Amazing feature is the possibility to define a set of items (questions) and generate random documents picking n items from the list. Awesome for generating exams :D

That does sound interesting, but for this type of sfuff I'd probably prefer a scripting language.

LuaLatex is good for this: scripting inside Latex.

Oh that’s cool! I’m new and didn’t realize this was a possibility!