I really like where Emacs is going recently. The speed with which new features move upstream has increased. There is a push by some developers for git to make contributions easier and even some progress towards modernizing or replacing good ol' info. That makes me confident that GNU Emacs is going to be around and that the eco-system is going to stay healthy for some time.
This is what I was alluding to but just because someone is working on something in an open source project doesn't mean it is ever going to happen. Particularly something as controversial as switching to another VCS. If you don't think this is controversial I encourage you to try it yourself with some project that is dear to you.
It's also evident if you go through any big project's mailing list in the past few years and search for git/mercurial/svn/cvs/dvcs or the like. I followed Pidgin's devel mailing list for a while. For some reason, when they switched away from SVN several years ago they switched to a very niche DVCS called monotone which, among other oddities, had such a large data format/slow clone process that they had a tarball of the database for download that you had to then use to initialize your local checkout, because actually cloning the database the normal way would take too long. I assume they chose it due to some core developers' familiarity with it or something. Later, they eventually realized this was a huge barrier to entry for new developers and there was a protracted discussion/flame war about the replacement. One guy in particular, felipec, seemed to spend days writing up long detailed posts about how hg was inferior to git, which were more or less factual, but written in a snarky/condescending tone, and the core developers never took him seriously and made it clear that his input was not welcome. It's kind of funny, that guy ended up writing a bunch of hg to git interoperability scripts ostensibly for the sake of proving git's superiority, and those are now included in git-contrib.
So, yeah, (D)VCS choice is probably a bigger holy war than editor, and getting a project to switch is quite nontrivial. Especially a lot of the projects you'd want to switch away from some poor DVCS, because they often stick to it for some non-technical reason (eg. bzr seems to be largely a GNU thing).
Reading info is fantastic, I agree. But writing it is a traumatic experience. There are also no converters to info from many of the common markdown derivatives. You cannot even reliably generate it from in-source Emacs Lisp comments which doubles the maintenance effort for most elisp code.
This is also less about the tools themselves but the mind-share they have. FOSS projects need a steady flow of new contributors to replace old ones and to get new steam. Switching to tools that are more likely to be known by a younger generation of programmers makes this easier. This applies to the git migration as well.
texinfo is pretty nice. Many GNU projects use this for their manuals. That way you can create a printed manual, an HTML manual, and an info manual from the same source.
>You cannot even reliably generate it from in-source Emacs Lisp comments which doubles the maintenance effort for most elisp code.
Good code comments do not make a good manual. A manual needs to do much more. I don't really believe in generating docs from docstrings in source code. I am surprised that you can't bootstrap a manual with the docstrings, though. That's unfortunate. I was able to do so rather easily with Guile.
I think that this new generation of programmers (which I am included in) should learn that Markdown is inadequate for large documents.
Oh, and I am in full support of the git migration.
