Contributing ============ If you make changes to this software, feel free to e-mail a patch to zeta@zetafiles.org If it's a big update, (for example a new plugin), you also have to include the following note: "I give you full irrevocable copy rights for this code, including but not limited to the right to sell, distribute, and make changes." Or use a permissive licence such as MIT, Apache, BSD, or Mozilla lincenses, with a disclaimer that it only applies to *your* code/plugin. Mercurial --------- Mercurial is a free, distributed source control management tool. We currently support version 4.5.3 (the one in Ubuntu-18 LTS) Windows: https://www.mercurial-scm.org/release/windows/Mercurial-4.5.3-x64.exe Linux: https://www.mercurial-scm.org/release/mercurial-4.5.3.tar.gz Follow the install instructions. Make sure hg is added to "PATH" ! Get the jzedit source code -------------------------- Clone the project: cd my-projects (where you want to place the files) hg clone https://hg.webtigerteam.com/repo/jzedit/ Mercurial commands: ------------------- # Clone the repository/folder $ hg clone https://hg.webtigerteam.com/repo/jzedit/ JZedit-new-feature # Make sure you are up to date $ hg pull # Make changes and commit $ hg ci -m "my changes" # See latest changeset(s) $ hg log -l 10 # Export the changeset(s) $ hg export 3 > change3.diff $ hg export 4 > change4.diff # replace 3, 4, etc with the actual changeset # Or export changesets 123 to 150 together $ hg export 123:150 > changes.txt Importing (notes to self) ------------------------- Guide from: https://www.mercurial-scm.org/guide # First clone the repository/folder to have an integration sandbox $ hg clone project integration $ cd integration $ hg import change3.diff $ hg import change4.diff # Test changes ... If you like them, pull the changes into the main repository $ cd ../project $ hg pull ../integration Support and maintenance ----------------------- If your code patches are added to the software, they will receive maintenance, meaning they will not break in future releases. This does not however mean your code will last forever. It can for example be deleted, for the following, but not limited to, these reasons: obsolete'ness, performance issues or replacements. Tests ----- You can increase the odds for your code not breaking by having tests. EDITOR.addTest(function myTest(callback) { // For example, open a new file, run private function, or EDITOR.mock() keyboard input return callback(true); // Test succeeded return callback(false); // Test failed throw new Error(""); // Test failed } If the test is inlined put the following comment before the test(s): // TEST-CODE-START And the following code after the tests // TEST-CODE-END If the tests are in seperate file(s), place them in the client/tests/ folder and add them to index.htm somwhere between and Documentation ------------- If you are a developer, you should look up what methods do by reading_the_source_code. 😄 Feel free to comment your code with reasons, as to why you choose to implement it that way, and why it's useful, and notes about performance optimizations. Do not write what the code does in the comments, the code should be self explainable, except for large public methods - where you should have a brief description of what it does.