Version 4.0.0

[r-stein]

Since we are going to release a new major version, we may also do some bigger refactoring changes in the process. (I would release v3.14 as the last version for all). In general there are some things, we should improve:

• A lot of top level files. We may just remove some files and move the ST related files to an extra directory.
• Reformat the files. The python files should have the same format (and names) according to PEP8 and not a mix from the styles of different people. The json files should also have a sane format (no mix of tabs and spaces, etc.).
• Start time: LaTeXTools has a huge load-time at the startup of ST, because it has many modules and ships it own plugin system. Since ST is not only a LaTeX-editor, we should try to decrease that time, e.g. by just loading the builder, if a tex file is opened.

Incompatible changes

• [ ] rename Sublime Text commands to fit the naming guide line #1423
• [ ] prefix view settings with latextools. to avoid collusion with other packages #1467

Refactoring

• [ ] move sublime-* files into an extra directory.
• [x] remove outdated files
  • *.OLD
  • Symbol List.tmPreferences
• [ ] remove conditional loader (for preview), because we don't need it any more
• [ ] remove and join some python files
• [ ] Reformat python files to fit PEP8 (4 spaces indent)
• [ ] Reformat Keybindings
• [x] Rename release messages. Just rename them e.g. from 40d.txt to v3.13.4.txt

Improvements

• [ ] Lazy load. LaTeXTools needs a relative big time on ST startup. We may somehow change the loader to lazy load stuff (e.g. builder, viewers), when the first tex file is opened, to improve the startup time.

Features

We should also add some features (the release info should not just be "some internal improvement"). However some of those may be postponed to a 4.x release:

• [ ] insert math popup #1111
• [x] User entered text in quickpanel #1051 , #1118
• [ ] Rename command #1103
• [x] auto-insert label contents #1131
• [ ] TikZ/PGF support #1079

[quantumgolem]

I officially support improving the load time

[ig0774]

Lazy-loading the stuff included via the internal plugin mechanism should be pretty straight-forward. It's just a matter of delaying the add_plugin_path() call as long as possible (currently, this is handled in a series of plugin_loaded() calls, but there's no reason that it must be.

It may also be worth exploring delaying imports to save some amount of load time. We need to keep the various Commands in either top-level module(s) or at least have a top-level module that hoists the Commands to the right location, but it may be possible to delay importing what is essentially back-end code as long as possible.

We might also look at consolidating the EventListeners. Currently we have about 15. We could look into reducing that to a single EventListener that's automatically loaded and automatically loads individual event listeners if they are needed. This would probably entail maintaining our own event listener-like system, and may result in slightly slower performance overall when editing LaTeX docs, but it would probably make LaTeXTools as a whole feel like a "lighter" package, since our EventListeners wouldn't be invoked on every possible event.

On a smaller note, we should refactor the command names to match a single style (e.g. LatexCommand rather than the mishmash of naming conventions currently in use.

[r-stein]

I have created the first prerelease (just enable it to use them). See info in the tags page to read the changes.

[r-stein]

I think we should also slighty change the get_setting method to prefix the view settings with latextools. to avoid setting name problems. So you name set the setting in the LaTeXTools setting as e.g. enable_command_completion and in the project setting you have to use latextools.enable_command_completion. So we have no problems if the name is used by an other package.

[r-stein]

@ig0774 @msiniscalchi if you agree on this I would merge the incompatible changes #1467 and #1423 and release version 4 a few weeks afterwards. Additional changes can be executed without increasing the major version.

[msiniscalchi]

@r-stein for what it's worth, I'm in favor. It would be good to document the changes though.

I really should be getting back into actually contributing! That might even happen in the not so distant future. Always very grateful for the work you and @ig0774 have been doing.