2

I wonder if it is possible to abbreviate a given set of commands in the preamble? For example, is it possible give a one-line code that abbreviates the commands from \documentclass to \usepackage{}? Specifically, is it possible to write something like "\setpreamble" to stand for the commands "\documentclass{article}" and "\usepackage{amsmath}".

4
  • @marmot, Hi, thanks. Is it better now?
    – Yes
    Jan 20, 2019 at 3:29
  • 2
    Yes, it is better. I guess you could write your own package or even class that loads all the stuff you want with \RequirePackage{amsmath}, say. Note, however, that I would like to convince you to rethink if you really want to do this. To me this sounds like a proposal that will make you a lot of "friends" once you start working on documents with others.
    – user121799
    Jan 20, 2019 at 3:32
  • You can just use \input but as marmot pointed out, this is not a very good idea. In fact, i think, what you want is a sign that you don't really understand how LaTeX works.
    – Johannes_B
    Jan 20, 2019 at 11:31
  • @Johannes_B, Hi. Yes, I don't understand how LaTeX works.
    – Yes
    Jan 20, 2019 at 22:26

1 Answer 1

8

TeX and LaTeX offer a number of different mechanisms to achieve this sort of thing. Which you can or should use depends on a number of different considerations.

  1. A command? In theory you could define a macro which loads packages and so forth. So this "works":

    \def\myspecialcommand{\documentclass{article}\usepackage{amsmath}}
    \myspecialcommand
    

    But it's a very bad idea. Not only is it non-standard and non-portable: but it doesn't even really achieve anything, because you still have to define the command, and the definition takes as much space as the commands would!

  2. \input{}? You can have a file which contains your preamble and \input that file at the appropriate point (even as the first thing in your document file). This isn't such a bad idea. It has the advantage that you can keep a "standard" preamble, that corrections to it will propagate to any document that uses it, and it saves typing. It's main disadvantage is that nobody (including you!) can compile the document without the critical preamble file. And the \input gives very little clue in such a case about what this file might contain --- even what documentclass is required.

  3. Write your own class file? The whole point of .cls files is to enable a designer to put together a generally usable template. A class file can inherit from a base file, can use \RequirePackage to add any necessary packages, can adjust fonts, paper-sizes and so forth to its hearts content. But, for purely personal use, it has many of the same disadvantages as \input: it presents a third party (or you if you've lost the .cls file!) with a black box which may make it difficult or impossible to compile the document without access to that file.

  4. Write your own style? You can do similar things with a personal .sty file. A personal style that loads masses of packages has all the same issues as a personal class file really. There may be more legitimacy in a personal style file which contains particular macros which you find yourself often using and defining. Although it won't be possible to compile the document if the .sty file is lost, it's often easier to reconstruct (more or less precisely) such macros, because their context usually tells you what they are trying to do.

  5. Use the config facilities of the various packages you often load? Quite a number of packages, especially "big" ones, will allow you to set and read a configuration file of some sort to save you entering options in every document you write. So, for instance, biblatex offers biblatex.cfg to set global bibliography options; or KOMA-Script's letter class offers .lco files to set various basic data for letters. The main drawback of these facilities is the same as anything else that sets non-defaults invisibly (so far as the main file is concerned): if someone doesn't have your config file, they can't reproduce your work. But depending on the document that may not be a huge concern. Its main advantage is that it ensures consistency across your documents, without requiring you to remember what may be some rather tedious options, and without unduly cluttering your actual document.

  6. "Templates" a/k/a cut and paste. Your last option is in some ways the simplest: keep some sort of template document, and start your work by physically copying it into a new document. If you balk at the primitive technology of simply cutting-and-pasting or renaming, you can use an editor which offers templates, snippets, or what have you.

    The main advantages of this are that it's simple, and it produces documents which are (in the end) 100 percent portable: you have only to send someone the active file(s) and they can typeset your document precisely. The main disadvantage is that it's easy for things to get out of sync. While typesetting one document, you spot and correct a bug in your template. But do you remember to correct the template? And do you need to go back and correct all the other documents that used the same template? With the other methods, such changes are automatically propagated outwards; with "templates" you can end up with a mess.

    EDITED TO ADD As Au101 points out in the comments, another drawback of templates is that they can become dustbins into which you have added any package you conceivably might ever use. Besides being offensive to those who are tidily-minded, and resource-heavy, this an open invitation to package clashes and muddle. Even if you use a template as a starting point, it's good practice to think about how much you actually need for a particular document, and to comment your template to help you do that.

So what should you do? There's no one-size-fits-all solution. My own view:

  • If your document is or may be provided (as source) to anyone else, especially a collaborator, make it self-contained and standards-compliant. On a large project it's OK to divide the project into pieces and \input or \include multiple files (indeed, good practice, and a large project is bound to contain multiple files such as .bib files): but everything should form part of a single collection, organized so that they can easily be bundled together without any inadvertent omissions. So, for instance, in a single directory or structure of directories.

  • The same basically goes for any project that you want to maintain for a long time. You may be confident that you won't forget, when you change your laptop, to copy your localtexmf tree to your new machine. And maybe you won't. But don't take the risk.

  • For personal projects, you have more leeway. But in those cases, try to include in the preamble (as a template, for instance) standard package loads and their options. If you make personal modifications to their macros (e.g. redefining them) or if you have a library of macro definitions of your own, there's much more to be said for maintaining them as a separate file, because they will probably be buggy and you will probably develop them as time goes on, and it's better to make sure that the changes propagate properly.

  • For myself, I wouldn't write my own class unless I actually had a distinctive type of document that I wanted to be usable by other people as well as me. I'd rather stick with a template. But others take a different view: there's certainly nothing wrong with having your own class file. It's one of the things they exist for. I'm much more willing to write a personal .sty file to contain macro definitions, even idiosyncratic ones, that I find frequently useful. In either case, be super careful to preserve the relevant files safely (backed-up, version-controlled, and so forth).

  • In general, there's no good reason not to have an actual, readable, preamble in your file which includes \documentclass (and all its options) and every package you load with \usepackage (and all their options). If you do load a personal style file, the template should also comment that. It's the work of a moment to have a template that vomits that text into any new document you want to create. Using \input and its ilk as a substitute for that is generally a bad idea, because it buys you a few characters but at the expense of clarity to others and yourself in the future.

4
  • This is a really good answer (upvoted), but I can't really agree with your discussion about personal .cls files and .sty files, I think they're very much in keeping with the LaTeX philosophy. It's the higher level version of defining your own macro isn't it? Setting up your document in advance, rolling it all in to little packet, which you can then easily use and modify. You talk about losing the file, but we should always be backing up and ultimately you can't compile the document if you lose the .tex file either ...... And I'd much rather try to put a custom .cls file back together
    – Au101
    Jan 20, 2019 at 11:38
  • I mean you have a point that losing the .cls file would affect lots of documents, but I'm not persuaded. What is a good point is where to put the .cls file. It's worth stressing not to put it somewhere where it could get deleted with an update. I can imagine it would be a bad idea to put it in with the default classes like article - I can easily see the custom file being wiped out with an update?
    – Au101
    Jan 20, 2019 at 11:41
  • @AU101 Certainly there is room for personal views on that, as I hope I made clear. It's certainly not any sort of philosophical mistake to use personal .cls and .sty files: a lot depends on the sort of work you do, and your own personal preferences and habits. Over 20 years or so, I've come to find personal .sty files useful, and personal .cls files ... not. I'll edit anyway. Jan 20, 2019 at 11:41
  • The bigger problem is building for yourself an ultra preamble that tries to be all things to all men and then you're just asking for clashes and incompatibilities with packages you might load for specific documents. Generally I try and avoid huge preambles and I think a master .cls file could have similar problems with packages breaking, going out of date, becoming unmaintained etc. in the future
    – Au101
    Jan 20, 2019 at 11:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .