1 |
On Wed, 25 Sep 2013 11:27:50 +1200 |
2 |
Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
|
4 |
> On 25 September 2013 10:30, Tom Wijsman <TomWij@g.o> wrote: |
5 |
> |
6 |
> > If I want to browse all documentation with a browser, just going to |
7 |
> > something like file:///usr/share/doc and read them all in the same |
8 |
> > style (using an extension like Stylebot or so); then it would be |
9 |
> > neat if Gentoo could bring them down to the same format to me, |
10 |
> > instead of that I would need to do local conversion or use multiple |
11 |
> > viewers for what could be in one canonical place. |
12 |
> > |
13 |
> |
14 |
> |
15 |
> How about doing it "Out of band" by a yet-to-exist gentoo tool that |
16 |
> can create a format to the users liking on demand? |
17 |
> |
18 |
> I mean, whatever way you look at it, such a tool *MUST* exist to |
19 |
> simply format the markdown to X-Format anyway. |
20 |
|
21 |
That sounds like a converter. |
22 |
|
23 |
> So why do this during ebuild phases? Why not have a tool that handles |
24 |
> this? |
25 |
|
26 |
Because we are discussing conversion in an ebuild context. |
27 |
|
28 |
> This greatly simplifies the problem that will transpire if we want to |
29 |
> support more than one markdown standard, namely, an increased bulk of |
30 |
> dependencies. |
31 |
|
32 |
The existence of a tool does not exclude that an ebuild cannot use it; |
33 |
so, I agree with your paragraph but that doesn't necessarily mean we can |
34 |
apply this in an ebuild context. |
35 |
|
36 |
> As to identifying what standard to use for a given markdown document, |
37 |
> I feel trying to do that automatically will result in sorrow, as will |
38 |
> trying to develop one tool that handles all formats in the same |
39 |
> document. |
40 |
|
41 |
Yes, automatic detection and applying a whole conversion based on that |
42 |
detection would be bad; writing something that only deals with the |
43 |
common elements, would be more neat. |
44 |
|
45 |
The question being whether we want to focus on the original Markdown or |
46 |
the GitHub Flavored Markdown to base ourselves on. |
47 |
|
48 |
> I think maybe we could support a metafile of some description in the |
49 |
> doc/<$pn-$pv>/ directory that describes a list of documents and the |
50 |
> relevant format decoder to use for that document. |
51 |
|
52 |
Why does documentation generation and/or conversion so suddenly be done |
53 |
by the user? it needlessly complicates things, especially since the |
54 |
user now has to store those generated or converted in a separate |
55 |
location; this is not the way it has been done and I don't understand |
56 |
why we need any change in that. |
57 |
|
58 |
The maintainer could specify the format in the ebuild; for bugs where |
59 |
it has found to be of a different format, this is an easy fix. |
60 |
|
61 |
> This approach means we can do this for more than just markdown |
62 |
> documents, and we can have support of extension-free files that |
63 |
> happen to be in RST format instead, or ascii-doc, or whatever, ie: |
64 |
|
65 |
This is no longer a discussion with regard to Markdown; but a whole |
66 |
topic on its own, at least if you want to be pursue consistency it |
67 |
might be worth bringing this up its own thread (or at least change the |
68 |
subject to denote it is no longer about Markdown in specific). |
69 |
|
70 |
> and then any of our tools can translate on demand to the format |
71 |
> needed: |
72 |
> |
73 |
> ^ could even be hooked to discover formats.meta and run the content |
74 |
> through a ANSI formatter to translate bold indications into escape |
75 |
> codes. |
76 |
|
77 |
My browser can't; so, I'll need conversion. |
78 |
|
79 |
> And the same tool could be used as a backend for whatever web-browser |
80 |
> centric documentation viewer we provide to render the files as html, |
81 |
> or even do things like |
82 |
|
83 |
What kind of backend would this be? A web server daemon? |
84 |
|
85 |
> gentoo-fm $PATH/README.md --formatter pdf > /tmp/doc.pdf && okular |
86 |
> /tmp/doc.pdf |
87 |
> |
88 |
> In the event somebody wants to read a simple markdown document as PDF. |
89 |
|
90 |
But why should we go through hard hoops to read something simple? |
91 |
|
92 |
Why not just have it installed and opened in the format the user wants? |
93 |
|
94 |
> ( This also has the benefits of not necessarily adding a large amount |
95 |
> of cruft to doc/ for people who don't need the documentation, and |
96 |
> means they wont have to rebuild the package *JUST* to get |
97 |
> documentation in a different format ) |
98 |
|
99 |
That doesn't happen as these are controlled with USE flags; eg, USE=pdf. |
100 |
|
101 |
If we plan on introducing more documentation formats, we might want to |
102 |
introduce an USE expand to make it easier for the user to configure; |
103 |
instead of the local USE flags we are using now. |
104 |
|
105 |
> TL;DR - We can provide a tool, it doesn't have to be locked in to the |
106 |
> ebuild phase to be useful, |
107 |
|
108 |
Tools used by ebuilds and eclasses can usually be used outside that |
109 |
context as well; it isn't really locked, and its usefulness doesn't |
110 |
change depending on where it is used. It's rather what the addition of |
111 |
the context you place it in that matters here. |
112 |
|
113 |
> and could be more useful to be seperate of ebuild systems, |
114 |
|
115 |
Perhaps it could be, but I don't see why; it feels less handy to do. |
116 |
|
117 |
> with ebuild systems only providing minimal amounts of |
118 |
> context to help a tool know how to process the document. |
119 |
|
120 |
If you put the tool in the context of the user, maintainers will not |
121 |
really be aware of or contributing to the context; eg. formats.meta. |
122 |
This would put the format responsibility in the hands of the user... |
123 |
|
124 |
Whereas if it was in an ebuild, it could be a matter of changing `domd |
125 |
README.md` to `domd -gfm README.md` (or if gfm defaults, to `domd -orig |
126 |
README.md`). No separate file, barely any extra characters; easy to fix. |
127 |
|
128 |
And as a result, documentation files in the format that the user wants. |
129 |
|
130 |
"Here, format X you don't like." --> "Which format would you like?" |
131 |
|
132 |
-- |
133 |
With kind regards, |
134 |
|
135 |
Tom Wijsman (TomWij) |
136 |
Gentoo Developer |
137 |
|
138 |
E-mail address : TomWij@g.o |
139 |
GPG Public Key : 6D34E57D |
140 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |