Proposal for Collaboration

[Entomy]

This is not something I have come to easily. However, it is something I beleive to overall be in the best interest for the community, and each other.

Let's cover hard facts and intended outcome first, and then my intentions after.

At the time this extension was formally announced and uploaded to the marketplace, there were already four Ada extensions in existence, at least that I'm aware of. Two of these were already on the marketplace, the oldest seeming to belong to Alessandro Del Sole, as well as my own. The other two that I'm aware of haven't been uploaded to the marketplace, but belong to Yuta Tomino (sp?) and Luke Guest.

Despite Ada being quite heavily used in certain industries, Ada's FOSS community is small. Extremely small. This kind of fragmentation isn't doing any good, and does more to hurt each other than to drive anything forward.

So now use and growth for the marketplace extensions:

• Del Sole's
  • 3,524 installs
  • Averaging 2.53 installs per day
• Mine (not including separate snippets extension)
  • 7,383 installs
  • Averaging 10.24 installs per day
• Yours
  • 312 installs
  • Averaging 3.00 installs per day

I've overwhelmingly focused on the syntax classifier, as it's closest to the expertise I've spent a decade and a half developing. I haven't had any desire nor time required to implement an LSP. While the initial implementation was created while also learning how VS Code does classification, it came out decently well, and was able to classify more precisely than even GPS, just with certain limitations imposed by the engine the classifier uses. More recently I've been made aware of ways to work with and work around those limitations to get near close to the EBNF definitions, and handle line breaks and other limitations much more robustly. I'll get back to this later.

Yours, on the other hand, does have LSP support. But also far from great classification.

What I'm proposing is that the two projects get combined. Your LSP, my syntax classifier.

This would have a number of benefits, not including the few related to my intentions, which will be covered later.

1. Reduced fragmentation of tooling. As stated, this doesn't do the community any good. It splits resources in an already small community.
2. Reduced fragmentation of community. The subset of Ada programmers who are also VS Code users is even smaller. Fragmenting this community causes even more problems. The bizarre thing is, for highly utilized languages like C and C++, there's only one language extension in the marketplace (until you hit the back pages; wouldn't recommend that in general), with a number of related extensions adding in features on top, not recreating the extension.
3. Your team can focus more on LSP development. I shouldn't need to explain this, right? It reduces fragmentation of resources within your own team.
4. My knowledge of Regex and VS Code behavior/quirks. I've given your team a few sophisticated Regex examples to replace some very basic ones your team has provided. Regex is tricky, and VS Code's flavor is no where near a common one, with a lot of unexpected behaviors if you're coming at it expecting it to behave like PCRE or JSRE.

So now my intentions, since this is admittedly quite an unusual situation, especially as I'm the author of the more popular and still faster growing extension, yet coming to you.

I'm copypastaing this, since I've already written it out elsewhere, and the explanation given there is close enough to appropriate for here that you'll figure it out.

As mentioned when I was elaborating my concerns, I have sensory integration/processing issues, which are highly comorbid with autism spectrum disorders. To be specific and formal, I have both Sensory Modulation Disorder and Synesthesia. Because these aren't widely known, I'll provide a basic explanation of them.

SMD's are a highly specific spectrum of sensory disorders where sensory stimuli are overprocessed, underproccessed, or insatiably craved. A very widely known form of this with ASD is the comfort that "weight" on the body can provide. Overprocessing can manifest as extreme reactions to a stimulus, and underprocessing can manifest as a lack of reaction to a stimulus. I both overprocess and underprocess. I do not have any SMD issues specifically related to computers, although some are generic enough that they can still present. Certain tactile stimuli are extremely overprocessed, to the point of certain fabrics making me nauseous and causing a spike in blood pressure. There is no consistency or pattern in how this happens. I generally just have to encounter it and avoid it from then on.

Synesthesia on the other hand, is where a sensory stimulus crosses cognitive pathways. This typically is another sensory pathway, although there are observed cases of it crossing into other non-sensory cognitive pathways (as happens to me sometimes). This is very hard to explain for people who've never experienced it, but basically, certain sensory stimuli cause additional sensations or responses that are not appropriate. The most common type, which I do not have, but is simple to explain, is chromagrapheme synesthesia, whereby graphemes (letters in English) are associated with colors and will be colorized regardless of their printed/displayed color.

The recent problems that have been sticking around is related to a very specific stimulus: my mouse moving over the mousepad. I'm not sure what the specific thing is, whether it's about the sound or texture or whatever. I haven't been able to figure it out. Other mousepads still trigger it, although I don't have another mouse to test with. Some days are better than others, with some not effecting me at all. But it's been bad enough that I can't reasonably maintain use of a mouse for more than few basic operations every hour most days. On one of the particularly bad days, the required mouse use I had to engage in (for something unrelated, but it's the effect that's important), the combination of synesthesia and overprocessing was enough that I had to go mute for the remainder of the day, and completely isolate myself; at the time I hadn't seen my girlfriend in two weeks and that was the day we had planned to do something.

Due to accessibility concerns and difficulties with VS Code, I've recently been rendered largely unable to use it. By contrast, use of other tooling hasn't been anywhere near effected, and I've had no problem continuously developing other things. Despite being made aware of ways to considerably enhance the classifier to work around limitations of VS Code, I've only been able to partially do the rework. Just shy of a month ago, the problems mentioned in the copypasta had grown bad enough to render continued development of anything in VS Code too problematic.

[reznikmm]

Hi @Entomy I'm glad that you proposed this collaboration. Frankly speaking, I was going to ask you to contribute your highlighter to our extension. Don't hesitate to use the Ada Language server in your extension, if you want.

[Entomy]

As I see it, there's two things that would have to be decided. One of these seems to effect the other and I'll explain when and how that's the case. If you or your team thinks of any addition factors please chime in; I'm not omniscient.

Project management

This seems to be the critical issue, as the other seemingly depends on it, or is at least effected by it.

The most obvious solution is to literally not change anything. Merging occurs somewhere with some prescribed process, and development split between repos. This requires no upfront effort, but does introduce a communication barrier and does mean that users will be confused as to where to file an issue. Furthermore, issues have to be migrated between repos when incorrectly filed. With this approach, issues can not simply be moved, and have to be recreated and tracked. It is my opinion that this is unviable long term.

Another option would be to submodule one project as a part of the other. It has very low initial effort and has clean separation of components. But it fails to solve other problems, like communication barriers and where to file issues. It also introduces a problem, however: requiring an additional step in development/packaging workflows, for updating the submodule. As neither of us seem to use submodules as part of the normal workflow, this seems like a step that's likely to be forgotten.

Yet another option is shared read/write access to each other's repos. This partially solves communication problems as well as mostly the user issue filing problem. With shared write permissions issues can be simply moved to where they should be. Merging still needs to occur somewhere however. This approach still maintains separation of components. This approach would probably work best through setting up an independent organization.

The last option I see is to pick a single repository and combine everything there. This fully solves any and all communication and issue filing problems. It does however eliminate any separation of components. This approach doesn't necessarily require an independent organization, but does require the most initial work, albeit with no increased effort long term.

Distribution

There are no licensing problems, which is convenient. I would prefer to keep the actual syntax files public domain, but as far as copyright matters go, it's very straightforward. GPL only infects at linkage/assembly time, so sources prior to that point can remain otherwise, as long as compatible. The assembled extension winds up strictly GPL, and this isn't an issue.

There is however the matter of how distribution occurs, and I don't see a clear option.

One option is to pick one of the existing extensions, and, going forward, use that as the "official" one, with everything combined.

The other option would be to deprecate the existing extensions and upload a new one with everything merged. I do not believe this is a wise decision, as it would just lead to increased fragmentation and confusion, defeating the whole point of this discussion.

As for what extension to pick as the "official" one, I'm not sure. I think it depends on a variety of factors, such as who'd be responsible for packaging/uploads? Everyone? One person? What's the upload schedule or release model look like? I don't have all the information I would need to even guess at what might work.

[reznikmm]

One requirement that we have is that AdaCore needs to maintain ownership of one extension, and be able to publish updates at our own pace.

I would prefer if you sent pull requests related to the syntax highlighter to this repo, so this extension will include your highlighter. I contribute here with pull requests too. I don’t have write access (besides creating a branch or a tag). It’s fine for me and I feel it is enough to make contributions.

After each merge the CI builds a test version of the extension and uploads it to bintray.com. It’s handy for quick testing. The way we make releases is just by setting a tag. This triggers the CI which rebuilds and uploads the extension to the MS marketplace. It’s easy to do and I can release as often as you want. The option with submodules won’t build fresh extension on each commit as I understand it.

Let us know if the pull requests approach works for you.