Create a repository to store custom languages JSON

[Curculigo]

Not good enough to be in .h/.cpp, but make it available for other people to help and improve it before you consider it to be good enough to convert into .h/.cpp and include in eepp source tree. This is the idea.

[SpartanJ]

We could use the ecode repository since it currently only holds some tools. I have no problem adding languages, color schemes, etc. The only thing that it's not convincing for me is to store incomplete language definitions, if they exists they can go to the main repo (even if they are not perfect), and if they're really bad they shouldn't be shared with other users, so it's kinda not very useful.

[Curculigo]

The .h/.cpp will trigger CI builds. To be accepted into the repository, the JSON needs to be fairly complete. I'm not proposing a repository to store draft JSON.

[SpartanJ]

Any change in the repository triggers a CI rebuild, even a readme file, CI builds do not know if the change affects code or not, it just rebuilds on every commit (this is how they work, it's not a limitation of the CI build).

If the JSON would be fairly complete, we should just add them natively. Anyway, I'm not opposed to using the main ecode repo to store useful stuff, I just think that languages definitions are always welcomed to be part of the application package.

[Curculigo]

Any change in the repository triggers a CI rebuild, even a readme file, CI builds do not know if the change affects code or not, it just rebuilds on every commit (this is how they work, it's not a limitation of the CI build).

I know. This is why I asked for another repository not eepp.

[SpartanJ]

I think ecode official repo will suffice, given that it's currently used for documentation and tools. So that's already settled. Now we just need to wait for some collaborations.

[Curculigo]

Please correct me if I'm wrong. But I think any push into the ecode repository will also trigger the CI:

https://github.com/SpartanJ/ecode/blob/main/.github/workflows/ecode-release.yml

[SpartanJ]

No, it only triggers on tags push with an specific pattern, and also can be triggered manually with a default workflow setup:

on:
  push:
    tags:
      - ecode-[0-9]+.*

  workflow_dispatch:
    inputs:
      version:
        description: Release Version
        default: ecode-0.6.3
        required: true

CI files can be configured to trigger on many different constraints, eepp does trigger on each push on develop branch for example:

on:
  push:
    branches:
      - 'develop'

CI is very flexible.