dev-python/docutils provides an emacs major-mode for editing rst-files called rst-mode.el in ${S}/tools/editors/emacs/. I put together an ebuild based on docutils-0.3.5.ebuild that installs rst-mode.el as well as rst-html.el and restructuredtext.el (and 50docutils-gentoo.el) /usr/share/emacs/site-lisp/rst-mode using the emacs-common eclass. I will attach the complete modified ebuild (and a patch for those of you who like that) and $FILESDIR/50docutils-gentoo.el. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 44165 [details] modified docutils ebuild
Created attachment 44166 [details] emacs site-lisp file
Created attachment 44167 [details, diff] patch that shows the changes made to the docutils ebuild
does elisp-common require emacs? if it does, then i'm not keen on this idea. i'd rather it be in a seperate ebuild simply because i don't want people merging docutils and having to merge the emacs beast.
The eclass itself does not DEPEND/RDEPEND on emacs, but it invokes emacs in elisp_compile() and elisp_comp(). However, none of these are called directly or indirectly in my patch. I definitely see your point. Unfortunately I don't have access to a gentoo without emacs, but I'll see what I can do and test it further on a non-emacs box.
I could find a non-emacs box for me to test this on, however I have tested it with and without "emacs" in USE and with the emacs binary renamed to emacs.old without any problems. The modified ebuild does not call any functions from the emacs/elisp-eclass if the emacs-flag is not set, so it shouldn't cause any problems. Anyway, I would really like to see rst-mode in portage, be it in this package or somewhere else, but it's no problem to keep on using my own docutils ebuild if necessary.
I second this request and recommend that it's merged with bug #95875 requesting an ebuild for docutils 0.3.9
This seems to be in 0.3.7 and up, which is the latest stable on everything with a stable version except for ppc-macos. Closing.