status of the package?

[gour]

Hello, just wonder what is the status of this package?

It's not updated for quite some time and PRs are also not handled?

Vim's support is in a little better shape and I'd not like to go to Electron-based editors. Any hint what to use for writing a lot of AsciiDoc(tor) markup?

[matt-y]

@sensorflo Hi, first off thank you so much for all the hard work on adoc-mode.

I'm going to use this issue questioning the status of the project to ask you if there is anything the community of adoc-mode users here on github can do to help out with maintenance. A few (admittedly blunt - sorry!) questions: Do you need help? If so, how can we help? What can we help with? Are you looking to find a new maintainer or maybe co-maintain the project with a wider group maybe under a github organization?

Again, thank you.

[egli]

I believe I found his (@sensorflo) phone number and I sent him a text asking for the status

[xeruf]

@egli any news?

[xeruf]

I have created a new organization to take over maintainership over such packages:
https://github.com/toemacs

Feel free to write here if you are interested in supporing this effort and I can invite you :)

[egli]

@xeruf well, he responded within 30 minutes and said that he should really pick up work on this package again. I encouraged him to respond to this issue in particular. I thought I'd give him some time. But I guess it has been a month without any action even after my text, so I guess it is clear that he does not have any time.

[tarsius]

@xeruf I just saw your email from Saturday, followed the link to this repository and found this issue. I'm gonna reply here.

I was considering to create a GH Organization to create a common maintainership for these, but then found your
orphanage. Is that also in the scope of that project, or would a separate organization be better?

Yes, the Emacs orphanage is intended for cases like this (among others). "Former" maintainers might find it easier to transfer to this organization than to some motivated but mostly unknown volunteer because this organization is under the control of @purcell (of Melpa fame) and me (Magit). While this does not happen often it is a good thing that we can step in if things don't quite work out, e.g. when the volunteer also disappears after a while.

By the way, @purcell, when I make this argument, then it would help if your membership of the organization were public. 😁 If you don't mind, then you can change that here.

[purcell]

it would help if your membership of the organization were public

Done, thanks. No idea why it was set to Private.

[TobiasZawada]

@purcell @tarsius
It is time to move this package to Emacs Orphanage and to review and apply the pullrequests.
It seems that there is nothing in sight from the original author.

BTW: Does https://github.com/emacsorphanage work similar to the Melpa repo itself? I mean pull requests by any contributors and review by someone of your team?

Note, that I am forced to work with adoc instead of Orgmode at office. I already adapted texfrag to adoc to show images and LaTeX fragments as images. But, I had to start from some base. I chose adoc-mode. Maybe, that was a mistake.

If I fork my version of adoc-mode from here. What are the chances that this package will be added to Melpa? (I want to give my colleges the opportunity to use the stuff I have provided.) This option is provided only in case everything else fails.

[tarsius]

BTW: Does https://github.com/emacsorphanage work similar to the Melpa repo itself? I mean pull requests by any contributors and review by someone of your team?

To an extend. I do look at new pull-requests (there aren't many) but I usually do not try to resolve existing pull-requests and issues.

(Github recently added to ability to add a readme to an organization's front-page and I will likely soon use that as an opportunity to clarify a few things.)

You are maintaining some packages of your own, so I think you are qualified to become the sole maintainer. Depending on how committed you are, we should create the fork under your account or the orphanage. I.e., if you switched jobs, would you continue to main this package? Nowadays I prefer if adopted repositories live with the new maintainer instead of in the orphanage, but if maintainership is bound to change again, then the orphanage is still a better choice.

[TobiasZawada]

Hi @tarsius,
Thanks for the offer to accept me as maintainer of the package.
The problem I am facing right now is that I am new to Asciidoc.
I can solve some of the problems that are Elisp related but I am certainly not the first choice when it comes to problems that are related to the processing of Asciidoc. It would be better if someone experienced in both, Elisp and Asciidoc could take over.

The doc of Asciidoc is so large that it will take me some time to become familiar with it.

[tarsius]

In that case I think it is best if I fork to the orphanage and add you as a maintainer there. Does that sound good?

[TobiasZawada]

Sounds very good. Thx.

[psaris]

if this is going to move, it should arguably go to an asciidoc related repo. three options include:
https://github.com/asciidoc
https://github.com/asciidoctor
https://github.com/asciidoc-py

[TobiasZawada]

@psaris

1. On https://github.com/asciidoc there is only one depricated repo for VI.
2. https://github.com/asciidoctor is primarily for the program Asciidoctor. But there is also asciidoctor-vscode. So maybe that is the right place. Do you have developper status there?
3. https://github.com/asciidoc-py What is the relation to Python?

[tarsius]

if this is going to move, it should arguably go to an asciidoc related repo [organization account]

Moving to an account like emacs-asciidoc would be best, if that existed or the maintainers of multiple asciidoc-related emacs packages were interested in joining forces. But that does not appear to be the case.

The mentioned organizations do not seem suitable to me.

[tarsius]

Repository created and invitation sent.

[psaris]

@TobiasZawada

the asciidoc parser was originally written in python 2. the developer stopped maintaining it and asciidoctor was written in ruby to continue the work. the asciidoc standard expanded beyond the python version and it was marked as legacy. since then, the python asciidoc project has been ported to python 3 and there are plans to add support for the new syntax. the https://github.com/asciidoc site is planned for the syntax itself and not for any specific implementation.

[tarsius]

For now the fork lives at https://github.com/emacsorphanage/adoc-mode. I have updated Melpa and the Emacsmirror accordingly. We can still move it later.

@TobiasZawada I recommend you open an issue in the new repository, which lists all issues and pull-requests from the old repository like so:

- [ ] https://github.com/sensorflo/adoc-mode/issues/38

Resulting in:

• status of the package? #38

[TobiasZawada]

@tarsius There is no issue tab there at https://github.com/emacsorphanage/adoc-mode. I did also not find an issue option on the settings page https://github.com/emacsorphanage/adoc-mode/settings. In the meantime, I have incorporated all but one of the pull requests. The pull request #41 about the Emacs27 update is a draft. I adopted only some of the changes from there.

Meanwhile I 've created the wiki-page https://github.com/emacsorphanage/adoc-mode/wiki/Adopted-issues-and-pull-requests-from-Sensorflo

[tarsius]

I've enabled issues.

Meanwhile I 've created the wiki-page https://github.com/emacsorphanage/adoc-mode/wiki/Adopted-issues-and-pull-requests-from-Sensorflo

Now that I've enabled issues, you should move that there. That's where people are going to look for it. Most at least; maybe don't delete the wiki page completely and just replace the list with a link to the tracker issue.

In the meantime, I have incorporated all but one of the pull requests. #41 is a draft. I adopted only some of the changes from there.

I've you don't intend to incorporate any more changes, then you should probably "close" it, with a tick mark, anyway.

[bbatsov]

@tarsius I'm an adoc-mode user myself, so if you need more maintainers - count me it. I love AsciiDoc, but the support for Emacs can definitely use some improvements.

[TobiasZawada]

I'm an adoc-mode user myself, so if you need more maintainers - count me it. I love AsciiDoc, but the support for Emacs can definitely use some improvements.

@bbatsov
Hi, welcome to the club.
Up to now I've only done some bug fixes.
Even if you are not subscribed yet you can already contribute through pull requests.
I guess, we would need some priorities and some planning for improving adoc-mode.el before any coding.

What are the top priorities for you?

Note, that I already have some code highlighting via polymode.el working locally. But, that does not work as smoothly as that one of Orgmode. Sometimes one has noticeable lag in highlighting and sometimes the highlighting gets messed up.
So I do not really want to make the interface part of adoc-mode.

For some things it would be great to make the Org-stuff available for Asciidoc. But, that is quite some work since very many things in Orgmode are hardcoded w.r.t. the syntax specification at Worg.

And one has to be aware that the development will diverge with the next Org-version.

[bbatsov]

What are the top priorities for you?

Ideally I'd get the syntax highlighting to handle everything markdown-mode can - all the modern AsciiDoctor syntax, code blocks, etc. Some preview functionality would be awesome as well (perhaps using the built-in Emacs browser to simplify things).

I'd also remove the dependency to that markup-faces package or whatever it was called.

[bbatsov]

As a final comment here I'll mention that the new canonical fork now lives here https://github.com/bbatsov/adoc-mode and people can track releases here https://github.com/bbatsov/adoc-mode/releases

The MELPA packages are now being built from the fork and soon I'll submit the package to NonGNU ELPA as well.