-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 24 Sep 2013 19:49:33 +0200 hasufell <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I wonder if it would make any sense to take the effort to convert > markdown docs to html format before installing them. Converting them to HTML format is useful for people whom do not want to use a Markdown viewer and would benefit from reading them in HTML format, as opposed to text mangled with formatting constructs. Do we want to cover this by an USE flag or apply the conversion for every package based on a present implementation? What if someone decides to switch between both? Do we want to keep the original Markdown file installed as well or would we prune it after conversion? > I see two possibilities: > > 1. Create one or two eutils functions like > "domd": will go through all viable implementations like > markdown/markdown_py/Markdown.pl, convert the file and dohtml it. Is > no impelementation installed on the system it will fall back to plain > dodoc. Treating files as Markdown sounds like a good start. > Optionally we could provide "md_depend" (like DEPEND="$(md_depend)") > to ensure that at least one implementation is present (might be useful > for very huge docs that are easier to read as html). No idea if such construct is the right way; I generally don't like this when other already implemented approaches exist, like using a virtual. Why wouldn't a virtual suffice? > 2. Introduce something like virtual/markdown... unfortunately the > "markdown" name is already reserved by app-text/discount, so I don't > really know how that would work out. And the supported arguments might > differ... A virtual for converters sounds better to me than $(md_depend); it spares out making eutils more complex, having to inherit eutils and having the dependencies where one would not expect them. (Do we want a virtual for viewers too?) > This is low priority, so if this is going to take more then little > work, I'll probably lose interest. It's a small change you want to see; it'll take little time if we go for implementing just what is really necessary, the KISS principle. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSQe92AAoJEJWyH81tNOV9+7kIAIMJVjDElGCbvib0v8YiFI7X IKygjcTosHvim9tjN78ShXn+1RvCyPeDZVEGU4+tQ3mYOiHe/mOm5QC6N/tN/ZOy +Vl42Xfwd6QGmObuJHgsMcpPQmjx3GUDKSIq0j3tZfx6MSVz9/QWtXV+h+7ZZo/W jj/lLhc0BQ5ryf+aoB/poutANoiPL0QzxTOpPZ4v/MqY8SUN/Pv7V27kdPdgYzut HkxvWUmpA+Vy8483X8IQPVQxaITv0e+O9v0Zjh0n5yc14qxx1ChlzIN2rfntky8J JHJRwN6gsUhC6eZdxoOUgkOUlRi523tlAEp7on4b0WmBpNSAS/aF14x8Oaxi/kQ= =ejC9 -----END PGP SIGNATURE-----
