Future of instant-markdown-d and vim-instant-markdown?

[ashwinvis]

instant-markdown-d is a great solution to have live rendering of markdown with vim. Although you had other plans such as a rewrite to ruby, I have found very interesting solutions such as

• autoscroll to cursor position
• CSS fixes
• fixes to serve files
• Mathjax / Katex support

the fact that the community seems to be actively modifying, developing and pushing PRs is a proof of the support for instant-markdown-d.

My question to @suan is, would you come back anytime soon to maintain it? Are you leaving it for dead and there is no sense in submitting bugs, pull requests etc. any more? Would you be willing to grant more people the power over the project, so the maintainer workload is spread across more people? Or would it be best to agree on a common community-led fork?

[twidxuga]

I subscribe to all of the above. Instant Markdown is something that I use every day. Interested to see the project go forward.

[ashwinvis]

I agree. I cannot take the full responsibility as I am not well versed in JS. Perhaps it is about time we formed a Github organization so it can be all merged in one place. The question is what kind of org and who would be interested? Going through the PR list I can leave a shout out to: @Rob--W, @LeaYeh, @felixge, @euclio, @modood @twidxuga, @EnotionZ, @HaleTom, @leifdenby and many others who had contributed their bit in development (apologies if I left out anyone who is interested).

[leifdenby]

Great initiative @ashwinvis! I haven't looked at the changes I made for a long time, so I can't even remember what I changed. But I'm happy to have a look at it and make a quick summary of what has changed in my fork. I don't have time at the moment do the work in merging and organising releases unfortunately.

[suan]

Hey all! My apologies for being so unresponsive, but, yes, I would like to open up push access as these are not projects I use anymore, but users deserve better and for the project to continue to be improved and maintained.

I'm looking for one or a few maintainers to, if not take the project forward, at least be semi-responsive to pull-requests.

I'd like to be part of any larger decision (eg to switch the entire codebase's language), although given how unresponsive I have that may or may not be practical and I might be willing to relinquish that too. I'm also open to any reorganizations that would make it easier for others to maintain the project.

@ashwinvis I went through recent pull-requests, and was glad to see that you both have the most, and are the one who started this issue/initiative! As a result, I've sent you an invite to grant push access. Since @ashwinvis has stated he's not the most comfortable with JS, I'm looking for other volunteers who are willing to chip in too, esp if you're versed in NodeJS!

Finally, I'd like some help on maintaining https://github.com/suan/vim-instant-markdown too, which is actually more active in terms of issues. So please let me know if you'd be interested in helping there too! (I might start a similar issue over in that repo, to look for help)

[suan]

Further, IIRC the Ruby rewrite hit a wall due to threading (tho I'm not sure I had the best approach, and Ruby capabilities might have changed since then) I then switched tacks to attempt pure node instead, and that was more promising, although I think the markdown/syntax-highlighting libraries used resulted in a preview that's slightly different than Github's: https://github.com/suan/instant-markdown-d/compare/pura-noda

I have no plans on continuing either of these branches, but just giving the lay of the land in case anyone wants to continue them!

EDIT: Oops! Looks like @euclio's great PR #17 has removed the need for Ruby after all

[twidxuga]

I am happy to contribute as time allows, to both instant-markdown-d and vim-instant-markdown. I don't think I will be responsive enough to take the role of main/sole maintainer of the project though due to work and life commitments, and I am also not an expert in JavaScript.

With that said, I've been slowly maintaining a fork where I have most of the additional features that I use on a daily basis. These are:

1. Formula rendering - my fork uses Katex (recently upgraded to the latest 0.10.1). I am aware that there are other implementations using Mathjax. As I understand it, Mathjax is more established but slower than Katex. Perhaps the two options could be added and made configurable from init.vim/.vimrc, thought that can incur a penalty in the size of the project if we decide to add both Mathjax and Katex font sets to the project as static resources (as I've done with Katex).

2. Serving any files from the folder (and sub-folders) that contain the file being edited when :InstantMarkdown is called from neovim - note that this is different from vim's current working directory. I've added this for over a year but I see that there is at least one more recent implementations from @modood.

3. I recently incorporated @ashwinvis patch to scroll to the current editing position, with a small change to prevent edge situations where the injected tags could be visible in the rendered page (at least with Katex).

4. Generating table of contents from the first 3 levels of header tags and insert it in the document with [[TOC]]

5. Misc small fixes to a few bugs that I've found along the way, such as changing the way in which environment variables are passed from vim-instant-markdown to instant-markdown-d, which I found not to work with Neovim. I also made small changes to the frontend html/JavaScript, though a CSS makeover as proposed by @ashwinvis is an excellent idea.

Some caveats:

• I've used Neovim for at least 3 years, and as such I have not tested any of these changes with Vim 8.
• I am Linux centric, don't own a mac, and do not usually work on Windows, so I haven't tested compatibility with Windows or OSX.

[suan]

Wow, @twidxuga , looks like you’ve done a good amount of improvements on the side! As such I’ve sent invites to both of you for both this and the vim repo.

Next up is to grant you all npm release access, need to find my npm login and will do that shortly.

Regarding cases such as katex and latex, I think a good approach would be to default to what you think most users would want, but allow configuring for either. I don’t think project or Filesize is that big of an issue.

I also hear the recommendation to create a separate GitHub org and move the repos to there - will follow up on that soon

[ashwinvis]

Thank you for the enthusiasm. Github org would be nice. I have accepted the invites and if you need my email for npm you can find it on the left sidebar of https://ashwinvis.github.io

@twidxuga I am also very much interested in latex rendering so I open a new issue #56 to coordinate this.

[twidxuga]

Thank you @suan! I have also accepted the invites. If you need my email for npm, you can find it under "See contact info" in my linkedin page.

Thanks again for this great project, it's been very useful to me.

@ashwinvis, perfect, will continue latex rendering discussion on issue #56

[ashwinvis]

@suan Did you manage to find your npm account? A bugfix release would be nice.

[ashwinvis]

Pinning this issue for two reasons:

• Need to release npm packages to avoid bug reports.
• More expert node.js maintainers required to debug and understand the issues reported. If anyone is willing to contribute feel free to comment below.
• Discuss moving the repos under a github org.