Frequently Asked Questions

Benito van der Zander Tim Hoffmann accdragon

Frequently Asked Questions

When will the next release be available?

There is no fixed release schedule for TXS. The added features have to be complete and sufficiently tested. Since it's a project we develop completely in our spare time, the time we can invest may strongly vary. Therefore it's hard to predict release dates.

If you are interested in the latest features, you can try a development version (no warrenty for stability and correctness). We provide development snapshots in irregular intervals for windows. Linux users need to compile TXS themselves. But it's straight forward.

Where are the settings stored?

The settings are stored in a file texstudio.ini. The default paths are:

  • Linux/Unix/Mac: ~/.config/texstudio/texstudio.ini
  • Windows: %APPDATA%\texstudio\texstudio.ini
  • Portable Version: config/texstudio.ini relative to the texstudio executable. (Older versions < 2.12.0: texstudio.ini is located directly in the directory of the texstudio executable.)

You can findout the actual path via Help -> Check LaTeX Installation. The resulting report contains a section Setting file.

Note: TeXstudio has to be closed while editing texstudio.ini. Otherwise the changes won't have any effect and will be overwritten when TeXstudio is closed.

How can I restore the default settings?

Just delete the settings file (texstudio.ini). Note: This has to be done, while TXS is not running. Otherwise it will recreate the file with the present settings on closing.

If you only want to restore the default settings temporarily, rename texstudio.ini (e.g. texstudio-backup.ini). You can go back to your settings by deleting the newly created texstudio.ini and renaming the backed-up ini again to texstudio.ini.

You can also just let it use another settings file with the --ini-file option. If you start TeXstudio with a non existing ini file texstudio --ini-file /tmp/randomfilename, it will temporarily use the default settings, without changing your normal settings.

How does the custom highlighting work?

Maybe you've found the Custom Highlighting section in the options. This is an unfinished feature with yet little capability:

  • You can define an environment, say foo and set its type either to verbatim or numbers. This results in the corresponding code between \begin{foo} and \end{foo} to be treated as verbatim or math. Note, that it currently doesn't register the environment to the completer / syntax checker. You have to do this manually by adding \begin{foo} to a custom .cwl file.

  • The section Additional Commands allows to specify new commands, e.g. \bar, i.e. register it to the syntax checker. It is superseeded by the .cwl files and should not be used any more.

Changes to the Custom Highlighting may only affect the editor after a restart of TXS.

Essentially the Custom Highlighting needs to be rewritten from scratch to make it really versatile.

Note: The recommended way to influence highlighting is customizing of the language definition.

Why does TeXstudio mark a command as unrecognized?

TXS checks all LaTeX commands in the document for validity. This helps you recognizing errors (typos and not loaded packages) already while typing. If a command is marked as unrecognized, TXS did not find a definition for it. See How does TXS know about valid commands? for more details.

Why does a command not show up in the completion?

First, check if TXS knows the command at all. Commands that are not known are marked in red by the syntax checker. See How does TXS know about valid commands? for more details. If the command is unknown, the solution is to write a cwl file defining the command and to put the file in the settings directory.

If TXS knows about the command, check if it appears in the all tab of the completer. Some commands are marked as unusual in the cwl file to keep the completer from overcrowding. As a result they will only show in the all tab, not in the typical tab. This is the default for all commands in automatically generated .cwl files. You are free to change this by editing the corresponding .cwl file.

How does TXS know about valid commands?

There are two ways to add new commands to a document: 1) defining new commands (e.g. via newcommand) and 2) importing them with a package.

  1. New commands: TXS needs the code defining the command. For single file documents this is always available. But it is also possible to define commands in another file and \import or \include them. In this case, TXS will recognize the command only if the file defining the commands is loaded (Note: There is an option Configure... -> Editor -> Automatically load included files. This loads files in the background (not visible in editor) to have access to the definitions therein.)

  2. Packages: TXS checks the \usepackage commands for included packages. for a given package, it obtains the commands from the corresponding .cwl file.

  3. You may statically activate additional cwl files at Options -> Completion. The commands defined in statically activated cwl files will be known in any document.

You can also switch off syntax checking at Configure... -> Editor -> Inline Checking -> Syntax.

What are cwl files good for and how do they work?

cwl stands for completion word list and is a file format originally used in Kile to define the commands listed in the completer. TeXstudio uses an extended format of cwls to include additional semantic information and allow for cursor and placeholder placement. It uses them for the following purposes:

  • Populating the autocompletion
  • Knowledge on the valid commands in the current document (depending on \usepackage statements)
  • Semantic information that provide additional context in the editor; e.g. a \ref-like command will check for the existence of the referenced label

Where do cwls come from?

TXS ships .cwl files for the most common packages. This list is not complete because there are far too many packages. If TXS cannot find a certain cwl file (see storage location below), it tries to auto-generate a cwl file by parsing the .sty file of the given package. This works pretty well in most cases. However TeX as a language is quite complex and you'd need to have a full LaTeX parser to be 100% sure what commands are valid in a given context.

Additionally, cwl files can supply more information than obtained by the auto-generation, e.g. it can mark commands as citation commands so that TXS can handle them like \cite for auto-completion and citation checking. Therefore cwl auto-generation is just a fallback and manually corrected and extended cwls are usually better than autogenerated ones.

You can created a cwl yourself and put it in the settings directory to use it. More information on the cwl format is found in the user manual. We are continuously extending the cwls shipped with TXS, so you are welcome to send cwls of packages that we do not include yet. See the source code of the buitlin cwls for a list of currently included cwls.

Where are cwl files stored?

up to version 2.10.8:
TXS ships with a number of bulitin cwl files. You cannot see them because they are compiled into the executable, however you may have a look at the source code of the buitlin cwls.

Additional cwls will be loaded from the settings directory. This is the place in which autogenerated cwls will be stored. You can add your self-written cwls there as well.

newer versions:
TXS searches for cwl files in three different locations:

1) settings directory/completion/user
2) builtin cwls
3) settings directory/completion/autogenerated

When are cwl files loaded?

Whenever TXS finds a \usepackage{packagename} command, it will try to load packagename.cwl for the context of the current document. This means you usually don't have to care about which cwls are loaded.

Additionally, you can statically activate cwls at Options -> Completion. In early versions of TXS this was the only way to load cwls. However, nowerdays this is not necessary in most cases because of the automatic loading based on \usepackage. So most likely you will just have the basic tex.cwl activated statically.

Why does TXS mark a package as missing?

TXS tries to determine the LaTeX packages installed on your system. This information is used for package name completion and to warn you if you try to import a package that is not installed.


TeXstudio queries MikTeX about the installed packages (mpm.exe --list). This information is used for the highlighting of missing packages.

Note: The list of installed packages is not necessarily the same as the list of available packages (e.g. you could manually add packages which are not maintained by MikTeX). It would be more correct to get the information from the filename database (FNDB) in MikTeX. However there doen't seem to be an API for that and the FNDB itself is a proprietary binary format. Therefore, mpm.exe --list is our best guess for MikTeX.


We determine the tex file database using kpsewhich --show-path ls-R and parse its content.

The package scan is started after startup. Depending on your system it may take some time to finish (up to a few minutes in extreme cases). After completing the scan, the highlighting is updated. Further changes of you TeX environment will remain unnoticed. You would need to restart TXS to enforce a new scan.

This package detection mechanism is completely independent of the LaTeX compiler. In some rare cases it may be that TXS is wrong and the compiler can find the package anyway (e.g. when you have multiple LaTeX distributions are installed or use some packages not maintained by the TeX distribution). In the end, it just matters if the compiler finds the packages. TXS tries to warn you if it thinks that the package is missing (in special cases it may be wrong). This is just for your convenience so that you can recognize possible errors before compiling. You can disable the checks in the options.

How can I keep Texstudio up-to-date on my Linux distribution?

If you want to update your Texstudio installation independently of the update schedule of the repositories of the distribution you are using, you have to do the following:

Head over to the opensuse homepage and select the distribution you are using. Depending on your choice, you will be presented with instructions on how to manually integrate the repository into your system. In some cases, you might have to use apt-pinning.

For Ubuntu Trusty Tahr (14.04) you would enter a command along this line into your terminal:

sudo sh -c "echo 'deb /' >> /etc/apt/sources.list.d/owncloud.list"
sudo apt-key add - < Release.key
sudo apt-get update
sudo apt-get install texstudio

I cannot type certain characters on my keyboard that involve AltGr on Windows

Some of TXS standard shortcuts contain Ctrl+Alt (e.g. Ctrl+Alt+S - Save As...). Accidentially windows treats AltGr like Ctrl+Alt. Therefore, you wouldn't be able to type AltGr+S, which is a certain character e.g. on a Polish keyboard, but instead you would trigger "Save As...". Since there are only a few such cases and it's limited to windows, we do not want to disregard Ctrl+Alt shortcuts completely.

Instead, we've included a list of exceptions. Known problematic shortcuts will be changed or deactivated on startup based on the current keyboard language. If you experience problems with certain characters, please report them so that we can add them to the exclude list. As a workaround, you can also change the corresponding shortcut in the options.

ِDoes TeXstudio support projects (i.e. mutli-file documents)?

Yes we do, but you won't find the word project anywhere. That's because of our philosophy that a project is implicit. As opposed to other editors in which you create a project or define a master file you don't have to configure anything in TeXstudio.

A project is basically a relation between files. You've already encoded this information in your tex files. Say, you have root.tex which includes a.tex and b.tex. TeXstudio extracts this information and makes the three of them an inplicit project. No matter which file you are currently editing, a compilation will always be executed on root.tex. Other knowledge of the document will be shared as well (e.g. imported packages, user-defined commands, labels, bibliographies etc.). You can also search in the project context.

Of course, there's one limitation for the automatic creation of the project tree. TXS has to load and parse all relevant files. Either you have to have them open in TXS, or you can activate Options -> Editor -> Automatically load included files. This option is disabled by default because it might affect loading times in very large project (still to be evaluated). For normal-size projects it should be fine and we recommend to activate it. With that options, it's sufficient to have the root file open, and TXS will parse all project information in the background.

We feel that the implicit project is a simplification for the user, because you don't have to bother with configuring a project. While it works very well for the majority of cases, there might still be problems with very complex configurations. In that case, feel free to file a bug report. Also, the concept hasn't made it yet to some elements of the user-interface. For example, the structure view is still file-based. But it is planned to provide a project-view of the outline.


Wiki: Compiling
Wiki: Home
Wiki: Tips and Tricks

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks