Does the project builder support non-ez80 / non-ti targets too? just wondering.

Nope, it does not at the moment. However, modularity was one of the strong design goals, so that support for multiple targets - not just multiple toolchains for a given target, which is already in production for the TI-eZ80 native code module - can be added at some point.

Quote

Also, an idea might be integration to some kind of versioning like overleaf does. (You can edit LaTeX and host the project on github.)

Indeed. In fact, this particular item is already part of the wish list, alongside project import The ability to export projects out of the PB infrastructure allows users to perform manual commits into whichever (D)SCM they see fit, but it's obviously more cumbersome than a direct integration into e.g. Github.

I hope this project will start supporting prizm soon. It Will be nice to have everything compiled online and fix vram issues for new fx-cg50 as well as allow to use two sets of icons one for old black backgrounds and another for white new one - it will attract more developers too. Thanks for working on this project

Ctrl-Click (or Cmd-Click on mac) on toolchain functions/defines etc. will open up the corresponding documentation line on GitHub

Trailing whitespaces are now trimmed on save

clang-provided warnings (as well as errors and diagnostics) are now shown inline, updated on each save and file switchingOther sources of warnings (ZDS, cppcheck) are still displayed, and have their name on the right.

Code re-indent feature available at the click of a button at the top-right of the editor

Improved:

More optimal sorting of the autocompletion items

Finer file permissions in the backend

Better security checks on #include statements

Stricter clang warning flags when using llvm-eZ80

The backend toolchain is now just the same as on github with a (very) small patch to apply

Between yesterday and today, I spent about a dozer hours on making the backend architecture of modules more generic, splitting in several layers what's specific and what's generic for the server-side processing things. I've also completed the DBHelper SQLite backend implementation (untested though!), if people are interested in it someday.

Anyway, it's becoming easier and easier to handle/add several modules in the Project Builder (even though I could still generify some more layers in the front-end, for instance a "front-end for a module using CodeMirror").

An overview of the general architecture according to PHPStorm, not showing fields/methods/etc. (we don't see what uses what, too bad ):

I finally did the rebase (well, I wrote a script to do it...) from the private repo to public repo, since early July.There are only 2 files left not yet published, basically Here are the 102 commits pushed: https://git.io/vF9hb

(And thanks to those who contributed to some of those commits, directly or indirectly, especially Mateo, Jacobly, Runer112, Lionel.)