Support (status) for Asciidoc(tor)

[polyglot-jones]

replace the original (now dead) one one Package Control (I guess we’ll have to come up with some fancy name for it).

First off, we’ll drop the “3” from the name. If you’re into alliteration, then perhaps AsciiDoc-Accelerator? I have an organization account on GitHub (https://github.com/gruntwurk “A mix of open-source tools for automating the “grunt work” of development.”) that I would be happy to have host it, and give you full admin privileges. I created it separate from my personal account for exactly this reason, so I wouldn’t have to be the only one in control.

[OdatNurd]

I really wish the original Asciidoctor package wouldn’t have gone stale as it has, for all these forks in the wild are unlikely to ever replace that package — partly due the fact that (unlike VSCode Marketplace) Package Control requires unique package names.

For what it’s worth, it should be possible to swap one repo for another in the package entry in PC and keep the name, presuming that the functionality remains equivalent-ish (i.e. you can’t swap a package in that is vastly different than what it’s replacing).

[tajmone]

For what it’s worth, it should be possible to swap one repo for another in the package entry in PC and keep the name,

But I wouldn’t want to do that, after all the original package was the work of its author. I really think that the problem should be solved by changing the way PC works, i.e. by allowing same-named packages by different authors, which would closer mimic how repository works. The whole idea of forking open source projects is that end users are free to chose an original product or its forks, but the current limitation of unique package names is not making things easy in that direction.

[tajmone]

First off, we’ll drop the “3” from the name. If you’re into alliteration

I had just addressed you on this in the repository Discussions! Before doing that there are some considerations to take into account, from the problems that might arise in renaming the repository, to the fact that switching to ST4 features in the syntax might break the package for its current users who didn’t migrate to ST4 and are still using ST3 (and I have no idea how many people are currently using it). Breaking the package for them wouldn’t be nice, especially without warnings.

I would be happy to have host it, and give you full admin privileges. I created it separate from my personal account for exactly this reason, so I wouldn’t have to be the only one in control.

I don’t have any problems moving the repository elsewhere, but this would make sense if by doing so we manage to blend the efforts of various people who have been working on the ADoc package. Having seen a number of forks of the original repository, I believe that multiple users are trying to revive that package, each their own ways. It would be a good idea to follow up and see which of these forks has been breaking through the original problems, and see if we could join forces into a new common repository, instead of working as individuals.

Although this might require an initial effort in order to merge all the various changes into a consistent repository, it might be well worth the effort, if after that we have a working product which is maintained by more collaborators. This should also accelerate the package development, and we might have a stable product sooner than if working separately.

Your offer is appealing, for it would be easier for individual maintainers to move their work to an independently hosted repository, like yours which is connected to an account especially devised for team work.

See if you can find at least two other developers who’ve been updating the original package to ST3/4 and have somehow advanced it, then we can start to coordinate efforts on how to integrate all the different changes, define a workflow and strategy, etc.