Thank you for considering contributing to LTEX. There are many ways to do so:
- You can report bugs to help make LTEX better.
- You can request features to make LTEX more powerful.
- You can contribute code to accelerate the pace of LTEX's development.
- You can test pre-release versions to help find bugs before they affect thousands of users.
- You can edit the documentation to make LTEX easier to use.
- You can translate the user interface into your mother tongue to make LTEX more accessible.
If you like LTEX, but are not able to contribute in any of these ways, there are still some quick and simple alternatives to show your gratitude:
- You can star the repository on GitHub.
- You can write a positive review on the Visual Studio Marketplace or on Open VSX.
- Make sure that your issue is really an LTEX bug.
- Make sure that your issue can neither be found in the list of known issues below nor in the list of all open and closed GitHub issues.
- Create a minimal example document for which the bug occurs. To do so, take your original document, for which the bug occurs, and delete roughly half of it. If the bug does not occur anymore, undo the deletion and delete the other half instead. If the bug occurs, repeat by deleting half of the remaining half etc., until you arrive at a very small document, for which the bug still occurs. This is the minimal example document.
- Create a minimal example configuration for which the bug occurs. To do so, proceed as for the minimal example document, except that you delete half of your
ltex.
settings. - Set the setting
"ltex.trace.server": "verbose"
in yoursettings.json
. - Try to understand the bug by selecting
View
→Output
→LTeX Language Server
/LTeX Language Client
. - Do one of the following:
- Reproduce the bug and keep the document for which it occurs open. Execute the command
LTeX: Report Bug in LTeX
inside VS Code from the Command Palette (Ctrl+Shift+P
) and click onCopy report and create issue
. This will copy a prefilled bug report to your clipboard and open theNew Issue
page on GitHub in your browser (you may have to confirm that you really want to open the page). Enter a summary of the issue in the title field and paste the bug report from your clipboard into the description field. Before submitting the bug report, check that it doesn't contain any confidential data. OR - Manually open an issue on GitHub, select the
Bug Report
template, and fill in as much info as you can (theLTeX: Report Bug in LTeX
command would do that for you). This will help us reproduce the issue.
- Reproduce the bug and keep the document for which it occurs open. Execute the command
Important: Please follow the issue template. Issues that don't follow the template or that don't contain the vital information requested in the template (especially minimal example document and settings) may be immediately closed as invalid.
- The LaTeX parser is not perfect. False positives are sometimes reported as errors. However, it is impossible to fully parse LaTeX's output without compiling the source. This follows from the Turing-completeness of TeX and the halting problem.
- Initial checking might take a while (up to two minutes), depending on the length of the document. This is a limitation of LanguageTool.
- Make sure that your feature is actually about LTEX (not about LanguageTool, for example).
- Make sure that your feature is not in the list of all open and closed GitHub issues.
- Do one of the following:
- Execute the command
LTeX: Request Feature for LTeX
inside VS Code from the Command Palette (Ctrl+Shift+P
) and click onCreate issue
. This will open theNew Issue
page on GitHub in your browser (you may have to confirm that you really want to open the page). OR - Manually open an issue on GitHub and select the
Feature Request
template.
- Execute the command
- Enter a summary of the feature in the title field and fill out the template in the description field. Fill in as much info as you can. Using actual real-world examples that explain why you and many other users would benefit from the feature increases the request's chances of being implemented.
Important: Please follow the issue template. Issues that don't follow the template or that don't contain vital information requested in the template may be immediately closed as invalid.
As explained in the FAQ, LTEX consists of two components: vscode-ltex and ltex-ls. This guide is only about the vscode-ltex part. If you want to change ltex-ls as well, be sure to read and follow the contribution guidelines of ltex-ls.
- Install VS Code, Git, and npm.
- Fork vscode-ltex on GitHub.
- Clone the fork:
git clone https://github.com/<YOUR_USERNAME>/vscode-ltex.git
- Open the cloned folder in VS Code.
- Install the npm dependencies:
cd vscode-ltex && npm install
- Run the
Launch extension
task to launch and debug the extension.
- Set up the project.
- Implement your changes.
- Use commit messages in the following form: First line in imperative, first letter upper case, no trailing period, maximum 50 characters. Second line is blank. Additional information (if any) is in third and following lines. If the change is related to an issue, use
See #1234.
orFixes #1234.
as a separate final paragraph. - Check if the extension builds:
npm run compile
. - Check if there are no linter errors:
npm run lint
. - Open a pull request with the
develop
branch as the target branch. - If the GitHub Actions CI reports any errors, fix them.
- Wait until a maintainer reviews your PR.
You can help find bugs before they affect thousands of LTEX users by testing pre-releases.
- Check whether a pre-release is available on the releases pages of vscode-ltex (pre-releases, if there are any, are at the top of the page).
- Download the
*.vsix
file corresponding to your platform. - Install the
*.vsix
file in VS Code viaExtensions: Install from VSIX...
on the Command Palette. - Reload the window of VS Code.
- Check if all currently listed changes in the changelog on the
develop
branch work as announced.
The availability of pre-releases varies. Pre-releases are only available if a pre-release tag (a tag with the name of a version number with a dash in it, e.g., 8.0.0-alpha.3
) has been pushed to the repository. Pre-releases are only available for a limited time; they will be deleted once the regular release has been taken place.
Of course, pre-releases are not for productive work, they even may be harmful and mess up your settings, etc. Therefore, it's best to use a clean installation/profile of VS Code. You can do that by starting VS Code via code --extensions-dir /tmp/code-extensions --user-data-dir /tmp/code-user
. If you do use your existing installation, you can downgrade again by removing the extension and reinstalling it from the Marketplace. Close VS Code after removing the extension if X does not behave normally.
You can improve the documentation:
- Check whether the page you want to edit is listed in the table below.
- If yes, then follow the corresponding link to the source.
- If no, then click on “Edit me on GitHub” at the bottom of the page you want to edit.
- Implement your changes.
- Use commit messages in the form as mentioned above.
- Open a pull request with the
develop
branch as the target branch. - If the GitHub Actions CI reports any errors, fix them.
- Wait until a maintainer reviews your PR.
The user interface of LTEX is currently available in the following languages:
- English
- German
You're welcome to help extend this list. To do so, only fluent proficiency (CEFR C1-level) in the target language is required, no programming skills.
- Duplicate
package.nls.de.json
, replacingde
with the ISO 639-1 language code of your language. - For each of the entries in the duplicated file: Look up the English original of the entry in the corresponding English file, and replace the German translation with the translation into your language.
- Use commit messages in the form as mentioned above.
- Open a pull request with the
develop
branch as the target branch. - If the GitHub Actions CI reports any errors, fix them.
- Wait until a maintainer reviews your PR.
Of course, it's also possible to duplicate the English language files instead, but you only need to translate the strings that are shown in the user interface (the other ones are for logging, debugging, etc.). The German language files already provide the correct subset of strings.