Em Fri, 6 May 2016 18:26:10 +0200
Markus Heiser escreveu:
> Hi Mauro,
>
> Am 06.05.2016 um 13:03 schrieb Mauro Carvalho Chehab
> :
> > Yeah, it looks better, however table truncation seem to be
> > happening also on other parts, like the tables on this page:
> >
> >
> > https://return42.g
Hi Mauro,
Am 06.05.2016 um 13:03 schrieb Mauro Carvalho Chehab :
> Yeah, it looks better, however table truncation seem to be
> happening also on other parts, like the tables on this page:
>
>
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-rgb.html
>
On Fri, 06 May 2016, Markus Heiser wrote:
> Am 06.05.2016 um 17:06 schrieb Jani Nikula :
>
>> On Fri, 06 May 2016, Markus Heiser wrote:
>>> @Jonathan: what do you think? Should I prepare a patch
>>> with a basic reST (sphinx) build infrastructure, including
>>>
>>> * a folder for sphinx docs:
>>
Am 06.05.2016 um 17:06 schrieb Jani Nikula :
> On Fri, 06 May 2016, Markus Heiser wrote:
>> @Jonathan: what do you think? Should I prepare a patch
>> with a basic reST (sphinx) build infrastructure, including
>>
>> * a folder for sphinx docs:
>>
>> ./Documentation/sphinx/
>
> I'm already wor
Em Fri, 6 May 2016 18:06:49 +0300
Jani Nikula escreveu:
> On Fri, 06 May 2016, Markus Heiser wrote:
> > @Jonathan: what do you think? Should I prepare a patch
> > with a basic reST (sphinx) build infrastructure, including
> >
> > * a folder for sphinx docs:
> >
> > ./Documentation/sphinx/
>
Em Fri, 6 May 2016 16:27:21 +0200
Markus Heiser escreveu:
> Hi all, hi Jonathan,
>
> Am 06.05.2016 um 15:42 schrieb Mauro Carvalho Chehab
> :
>
> > Em Fri, 6 May 2016 15:32:35 +0200
> > Markus Heiser escreveu:
> >
> >> Hi Mauro,
> >>
> >> Am 06.05.2016 um 13:35 schrieb Mauro Carvalho Cheh
On Fri, 06 May 2016, Markus Heiser wrote:
> @Jonathan: what do you think? Should I prepare a patch
> with a basic reST (sphinx) build infrastructure, including
>
> * a folder for sphinx docs:
>
> ./Documentation/sphinx/
I'm already working on a patch series taking a different approach. I
don't
Hi all, hi Jonathan,
Am 06.05.2016 um 15:42 schrieb Mauro Carvalho Chehab :
> Em Fri, 6 May 2016 15:32:35 +0200
> Markus Heiser escreveu:
>
>> Hi Mauro,
>>
>> Am 06.05.2016 um 13:35 schrieb Mauro Carvalho Chehab
>> :
>>
>>> Markus,
>>>
>>> Em Fri, 6 May 2016 13:23:06 +0200
>>> Markus Heiser
Hi Jani,
I forget to mentioning, with a local copy of my kernel-doc script:
https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc
You could do reST markup in the source code comments and extract them.
This might be a interim workaround which helps you not to edit source
code
Hy Jani,
Am 04.05.2016 um 18:13 schrieb Jani Nikula :
>> Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :
>>
>>> I think all of this makes sense. It would be really nice to have the
>>> directives in the native sphinx language like that. I *don't* think we
>>> need to aim for that at the outs
Hi Mauro,
Am 04.05.2016 um 18:15 schrieb Mauro Carvalho Chehab :
> Em Wed, 4 May 2016 11:34:08 +0200
> Markus Heiser escreveu:
>
>> Hi all, (hi Jonathan, please take note of my offer below)
>>
>> Am 03.05.2016 um 16:31 schrieb Daniel Vetter :
>>
>>> Hi all,
>>>
>>> So sounds like moving ahea
Em Thu, 5 May 2016 07:02:10 -0600
Jonathan Corbet escreveu:
> On Wed, 4 May 2016 14:57:38 -0300
> Mauro Carvalho Chehab wrote:
>
> > Also, media documentation is not just one more documentation. It is
> > the biggest one we have, and that has more changes than any other
> > documentation under
On Wed, 4 May 2016 14:57:38 -0300
Mauro Carvalho Chehab wrote:
> Also, media documentation is not just one more documentation. It is
> the biggest one we have, and that has more changes than any other
> documentation under Documentation/DocBook:
>
> $ git lg --since 01/01/2015 ` ls *.tmpl|grep -
Em Wed, 4 May 2016 10:59:36 -0600
Jonathan Corbet escreveu:
> On Wed, 4 May 2016 13:50:35 -0300
> Mauro Carvalho Chehab wrote:
>
> > Em Wed, 4 May 2016 19:13:21 +0300
> > Jani Nikula escreveu:
> > > I think we should go for vanilla sphinx at first, to make the setup step
> > > as easy as pos
On Wed, 4 May 2016 13:50:35 -0300
Mauro Carvalho Chehab wrote:
> Em Wed, 4 May 2016 19:13:21 +0300
> Jani Nikula escreveu:
> > I think we should go for vanilla sphinx at first, to make the setup step
> > as easy as possible for everyone.
>
> Vanilla Sphinx doesn't work, as reST markup languag
Em Wed, 4 May 2016 19:13:21 +0300
Jani Nikula escreveu:
> On Wed, 04 May 2016, Markus Heiser wrote:
> > Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
> > particular with your "MARKDOWNREADY := gpu.xml" process.
> >
> > As I understood, you convert markdown to docbook within th
Em Wed, 4 May 2016 08:57:13 -0600
Jonathan Corbet escreveu:
> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter wrote:
>
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff with impunity in gpu documentations.
> >
> > Aside: If we d
On Wed, May 4, 2016 at 5:02 PM, Daniel Vetter wrote:
> On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
>> On Wed, 4 May 2016 16:18:27 +0200
>> Daniel Vetter wrote:
>>
>> > > I'd really like to converge on the markup question, so that we can start
>> > > using all the cool stuff w
Em Wed, 4 May 2016 11:34:08 +0200
Markus Heiser escreveu:
> Hi all, (hi Jonathan, please take note of my offer below)
>
> Am 03.05.2016 um 16:31 schrieb Daniel Vetter :
>
> > Hi all,
> >
> > So sounds like moving ahead with rst/sphinx is the option that should
> > allow us to address everyone'
On Wed, 04 May 2016, Markus Heiser wrote:
> Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in
> particular with your "MARKDOWNREADY := gpu.xml" process.
>
> As I understood, you convert markdown to docbook within the kernel-doc
> script using pandoc's executable? ... I don't face t
Am 04.05.2016 um 15:43 schrieb Daniel Vetter :
> On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote:
>>> On Wed, 04 May 2016, Markus Heiser wrote:
>>> I'd be *very* hesitant about adding the kind of things you do in
>>> reformat_block_rst to kernel-doc. IMO the extraction from kernel-d
On Wed, 04 May 2016, Jonathan Corbet wrote:
> The sphinx/rst approach does seem, to me, to be the right one, with the
> existing DocBook structure remaining in place for those who want/need
> it. I'm inclined toward my stuff as a base to work with, obviously :) But
> it's hackish at best and need
On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote:
> On Wed, 4 May 2016 16:18:27 +0200
> Daniel Vetter wrote:
>
> > > I'd really like to converge on the markup question, so that we can start
> > > using all the cool stuff with impunity in gpu documentations.
> >
> > Aside: If we
On Wed, 04 May 2016 16:41:50 +0300
Jani Nikula wrote:
> On Wed, 04 May 2016, Markus Heiser wrote:
> > In reST the directive might look like:
> >
> > -
> > Device Instance and Driver Handling
> > ===
> >
> > .. kernel-doc:: drivers/gpu/drm/drm_drv.c
> >:d
On Wed, 4 May 2016 16:18:27 +0200
Daniel Vetter wrote:
> > I'd really like to converge on the markup question, so that we can start
> > using all the cool stuff with impunity in gpu documentations.
>
> Aside: If we decide this now I could send in a pull request for the
> rst/sphinx kernel-doc
On Wed, May 4, 2016 at 3:43 PM, Daniel Vetter wrote:
> I'd really like to converge on the markup question, so that we can start
> using all the cool stuff with impunity in gpu documentations.
Aside: If we decide this now I could send in a pull request for the
rst/sphinx kernel-doc support still f
On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote:
> > On Wed, 04 May 2016, Markus Heiser wrote:
> > I'd be *very* hesitant about adding the kind of things you do in
> > reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc
> > comments must be as simple as possible with
On Wed, 04 May 2016, Markus Heiser wrote:
>> What do you mean by ".tmpl workflow"?
>
> Sorry for bad naming, I addressed the DOCPROC build process which builds
> the .xml files from .tmpl files ...
Yeah, I know more about this part than I care. I was just wondering what
you refer to with that in
Hi Jani,
Am 04.05.2016 um 11:58 schrieb Jani Nikula :
> On Wed, 04 May 2016, Markus Heiser wrote:
>> but I think this will not by very helpful, as long as you miss
>> a similar ".tmpl" workflow for reST documents.
>>
>> I'am working on a reST directive (named: "kernel-doc") to provide a
>> sim
On Wed, 04 May 2016, Markus Heiser wrote:
> but I think this will not by very helpful, as long as you miss
> a similar ".tmpl" workflow for reST documents.
>
> I'am working on a reST directive (named: "kernel-doc") to provide a
> similar ".tmpl" workflow within plain reST. The first step towards
Hi all, (hi Jonathan, please take note of my offer below)
Am 03.05.2016 um 16:31 schrieb Daniel Vetter :
> Hi all,
>
> So sounds like moving ahead with rst/sphinx is the option that should
> allow us to address everyone's concerns eventually? Of course the
> first one won't have it all (media se
Daniel Vetter writes:
> So sphinx/rst y/n? Jon, is that ok with you from the doc maintainer
> pov?
I think the right answer for today is to use sphinx to generate docs
From inline comments, to encourage outline docs to give it a try but to
allow doc writers to use whatever works for them.
That
Hi all,
So sounds like moving ahead with rst/sphinx is the option that should
allow us to address everyone's concerns eventually? Of course the
first one won't have it all (media seems really tricky), but I'd like
to get something awesome in this area closer to mainline. I'm stalling
on typing mor
On Tue, Apr 12, 2016 at 4:46 PM, Jonathan Corbet wrote:
> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser wrote:
>
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>> DocBook XML documentation to reST markup.
>>
>> It converts 99% of the docs well ... to gain an impres
Em Mon, 18 Apr 2016 10:10:17 +0200
Markus Heiser escreveu:
> Hi Mauro, hi kernel-doc authors,
>
> Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab
> :
>
> > Em Fri, 8 Apr 2016 17:12:27 +0200
> > Markus Heiser escreveu:
> >
> >> Hi kernel-doc authors,
> >>
> >> motivated by this MT, I
Hi Jonahtan,
Am 12.04.2016 um 17:46 schrieb Jonathan Corbet :
> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser wrote:
>
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>> DocBook XML documentation to reST markup.
>>
>> It converts 99% of the docs well ... to gai
Hi Mauro, hi kernel-doc authors,
Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab :
> Em Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser escreveu:
>
>> Hi kernel-doc authors,
>>
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>> DocBook XML documentation to reST
On Fri, 8 Apr 2016 17:12:27 +0200
Markus Heiser wrote:
> motivated by this MT, I implemented a toolchain to migrate the kernel’s
> DocBook XML documentation to reST markup.
>
> It converts 99% of the docs well ... to gain an impression how
> kernel-docs could benefit from, visit my sphkerneld
Hi Markus,
On 04/08/16 17:12, Markus Heiser wrote:
> Hi kernel-doc authors,
>
> motivated by this MT, I implemented a toolchain to migrate the kernel’s
> DocBook XML documentation to reST markup.
>
> It converts 99% of the docs well ... to gain an impression how
> kernel-docs could benefit fr
Hi kernel-doc authors,
motivated by this MT, I implemented a toolchain to migrate the kernel’s
DocBook XML documentation to reST markup.
It converts 99% of the docs well ... to gain an impression how
kernel-docs could benefit from, visit my sphkerneldoc project page
on github:
http://return
Am 10.03.2016 um 16:21 schrieb Mauro Carvalho Chehab :
> Em Thu, 10 Mar 2016 12:25:58 +0200
> Jani Nikula escreveu:
>
>> TL;DR? Skip to the last paragraph.
>>
>> On Wed, 09 Mar 2016, Mauro Carvalho Chehab wrote:
>>> I guess the conversion to asciidoc format is now in good shape,
>>> at least
Em Thu, 10 Mar 2016 12:25:58 +0200
Jani Nikula escreveu:
> TL;DR? Skip to the last paragraph.
>
> On Wed, 09 Mar 2016, Mauro Carvalho Chehab wrote:
> > I guess the conversion to asciidoc format is now in good shape,
> > at least to demonstrate that it is possible to use this format for the
> >
TL;DR? Skip to the last paragraph.
On Wed, 09 Mar 2016, Mauro Carvalho Chehab wrote:
> I guess the conversion to asciidoc format is now in good shape,
> at least to demonstrate that it is possible to use this format for the
> media docbook. Still, there are lots of broken references.
Getting re
Em Tue, 8 Mar 2016 12:39:21 -0300
Mauro Carvalho Chehab escreveu:
> Pandoc failed to fully convert it, but at least it left all the texts,
> with prevented rewriting it from scratch. This is the manual fix
> I applied to it:
>
> https://git.linuxtv.org/mchehab/asciidoc-poc.git/commit/func-
On Wed, 09 Mar 2016, Dan Allen wrote:
> On Tue, Mar 8, 2016 at 6:58 AM, Jani Nikula wrote:
>
>> I need to look into this again. Is there a specific option or directive
>> to produce split output for includes? When I tried this, the result was
>> just one big output file. (And indeed we'd need bot
Em Tue, 8 Mar 2016 10:39:22 -0300
Mauro Carvalho Chehab escreveu:
> Em Tue, 08 Mar 2016 05:13:13 -0700
> Dan Allen escreveu:
>
> > On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <
> > mche...@osg.samsung.com> wrote:
> >
> > > pandoc did a really crap job on the conversion. To co
On Tue, 08 Mar 2016, Dan Allen wrote:
> That's not entirely true. First, you can pre-split at the source level
> using includes and generate output for each of the masters. That's what I
> tend to do and it works really well since these are logical split points.
I need to look into this again. Is
Em Tue, 08 Mar 2016 05:13:13 -0700
Dan Allen escreveu:
> On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <
> mche...@osg.samsung.com> wrote:
>
> > pandoc did a really crap job on the conversion. To convert this
> > into something useful, we'll need to spend a lot of time, as it lost
> >
Em Tue, 08 Mar 2016 05:09:40 -0700
Dan Allen escreveu:
> Jani wrote:
>
> > there was no support for chunked, or split
> > to chapters, HTML, and the single page result was simply way too big.
> >
>
> That's not entirely true. First, you can pre-split at the source level
> using includes and g
Em Tue, 08 Mar 2016 11:49:35 +0200
Jani Nikula escreveu:
> On Tue, 08 Mar 2016, Dan Allen wrote:
> > One of the key goals of the Asciidoctor project is to be able to directly
> > produce a wide variety of outputs from the same source (without DocBook).
> > We've added flexibility and best practi
On Tue, 08 Mar 2016, Dan Allen wrote:
> One of the key goals of the Asciidoctor project is to be able to directly
> produce a wide variety of outputs from the same source (without DocBook).
> We've added flexibility and best practices into the syntax and matured the
> converter mechanism to bridge
On Fri, 2016-03-04 at 09:46 +0200, Jani Nikula wrote:
> […]
> If we're talking about the same asciidoctor (http://asciidoctor.org/)
> it's written in ruby but you can apparently run it in JVM using
> JRuby. Calling it Java-based is misleading.
Indeed, I was somewhat imprecise. Thanks to the work m
Em Mon, 7 Mar 2016 00:29:08 +0100
Johannes Stezenbach escreveu:
> On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> >
> > I converted one of the big tables to CSV. At least now it recognized
> > it as a table. Yet, the table was very badly formated:
> >
> > https://mc
Em Mon, 7 Mar 2016 09:48:26 +0100
Johannes Stezenbach escreveu:
> On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote:
> > On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > I converted one of the big tables to CSV. At least now it recognized
> >
On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote:
> On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> >
> > I converted one of the big tables to CSV. At least now it recognized
> > it as a table. Yet, the table was very badly formated:
> >
> > https:/
On Thu, 03 Mar 2016 16:03:14 +0200
Jani Nikula wrote:
> This stalled a bit, but the waters are still muddy...
So I've been messing with this a bit; wanted to do a proper patch posting
but I'm fried and mostly out of time for the moment.
The results I'm getting now can be seen at:
http:
On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
>
> I converted one of the big tables to CSV. At least now it recognized
> it as a table. Yet, the table was very badly formated:
>
> https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
>
> T
Em Fri, 04 Mar 2016 15:09:09 +0100
Johannes Stezenbach escreveu:
> On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote:
> >
> > 3) I tried to use a .. cssclass, as Johannes suggested, but
> > I was not able to include the CSS file. I suspect that this is
> > easy to fix, but I
On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote:
>
> 3) I tried to use a .. cssclass, as Johannes suggested, but
> I was not able to include the CSS file. I suspect that this is
> easy to fix, but I want to see if the cssclass will also work for
> the pdf output as well.
"cs
Em Fri, 04 Mar 2016 10:29:08 +0200
Jani Nikula escreveu:
> On Fri, 04 Mar 2016, Mauro Carvalho Chehab wrote:
> > Em Thu, 03 Mar 2016 15:23:23 -0800
> > Keith Packard escreveu:
> >
> >> Mauro Carvalho Chehab writes:
> >>
> >> > On my tests, Sphinix seemed too limited to format tables. Asci
On Fri, Mar 04, 2016 at 10:29:08AM +0200, Jani Nikula wrote:
> On Fri, 04 Mar 2016, Mauro Carvalho Chehab wrote:
> >
> > If, on the other hand, we decide to use RST, we'll very likely need to
> > patch it to fulfill our needs in order to add proper table support.
> > I've no idea how easy/difficul
On Fri, 04 Mar 2016, Mauro Carvalho Chehab wrote:
> Em Thu, 03 Mar 2016 15:23:23 -0800
> Keith Packard escreveu:
>
>> Mauro Carvalho Chehab writes:
>>
>> > On my tests, Sphinix seemed too limited to format tables. Asciidoc
>> > produced an output that worked better.
>>
>> Yes, asciidoc has m
On Fri, 04 Mar 2016, Russel Winder wrote:
> On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
>> 1) the python version (asciidoc) appears to have been abandoned in
>> favor of the ruby version.
>
> This is I think true, however the Java-based tool chain Asciidoctor is
> I believe the
On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
>
[…]
> However, I think asciidoc has two serious problems:
>
> 1) the python version (asciidoc) appears to have been abandoned in
> favor of the ruby version.
This is I think true, however the Java-based tool chain Asciidoctor is
I
Em Thu, 03 Mar 2016 15:23:23 -0800
Keith Packard escreveu:
> Mauro Carvalho Chehab writes:
>
> > On my tests, Sphinix seemed too limited to format tables. Asciidoc
> > produced an output that worked better.
>
> Yes, asciidoc has much more flexibility in table formatting, including
> the abil
Mauro Carvalho Chehab writes:
> On my tests, Sphinix seemed too limited to format tables. Asciidoc
> produced an output that worked better.
Yes, asciidoc has much more flexibility in table formatting, including
the ability to control text layout within cells and full control over
borders.
Howev
Em Thu, 03 Mar 2016 07:13:05 -0700
Jonathan Corbet escreveu:
> On Thu, 03 Mar 2016 16:03:14 +0200
> Jani Nikula wrote:
>
> > This stalled a bit, but the waters are still muddy...
>
> I've been dealing with real-world obnoxiousness, something which won't
> come to an immediate end, unfortunat
On Thu, Mar 3, 2016 at 4:17 PM, Jonathan Corbet wrote:
> I assume you're referring to gtk-doc? It's web page
> (http://www.gtk.org/gtk-doc/) starts by noting that it's "a bit awkward to
> setup and use"; they recommend looking at Doxygen instead. So I guess I'm
> not really sure what it offers t
On Thu, 3 Mar 2016 14:34:25 +
One Thousand Gnomes wrote:
> We only have docbook because it was the tool of choice rather a lot of
> years ago to then get useful output formats. It was just inherited when
> borrowed the original scripts from Gnome/Gtk. It's still the most
> effective way IMHO
> DocBook is a means to an end; nobody really wants DocBook itself as far
> as I can tell.
We only have docbook because it was the tool of choice rather a lot of
years ago to then get useful output formats. It was just inherited when
borrowed the original scripts from Gnome/Gtk. It's still the mo
On Thu, 03 Mar 2016 16:03:14 +0200
Jani Nikula wrote:
> This stalled a bit, but the waters are still muddy...
I've been dealing with real-world obnoxiousness, something which won't
come to an immediate end, unfortunately. But I have been taking some time
to mess with things, and hope to have so
On Sat, 13 Feb 2016, Jonathan Corbet wrote:
> So can we discuss? I'm not saying we have to use Sphinx, but, should we
> choose not to, we should do so with open eyes and good reasons for the
> course we do take. What do you all think?
This stalled a bit, but the waters are still muddy...
Is th
On Thu, Feb 18, 2016 at 2:01 PM, Jonathan Corbet wrote:
> On Thu, 18 Feb 2016 10:24:04 +0100
> Daniel Vetter wrote:
>
>> > Worth noting is that, AFAICT, in all of the proposals, including the
>> > original where kernel-doc produces docbook, this autoreferencing only
>> > works within parts proces
On Thu, 18 Feb 2016 10:44:34 -0200
Mauro Carvalho Chehab wrote:
> > > It is workable, but I guess nested tables produced a better
> > > result.
> > >
> > > I did myself a test with nested tables with asciidoc too:
> > >
> > > https://mchehab.fedorapeople.org/media-kabi-docs-test/pandoc_asciidoc/
On Thu, 18 Feb 2016 10:24:04 +0100
Daniel Vetter wrote:
> > Worth noting is that, AFAICT, in all of the proposals, including the
> > original where kernel-doc produces docbook, this autoreferencing only
> > works within parts processed by kernel-doc. Not in the template
> > documents themselves.
Em Thu, 18 Feb 2016 13:07:03 +0100
Hans Verkuil escreveu:
> On 02/18/16 13:04, Mauro Carvalho Chehab wrote:
> > Em Thu, 18 Feb 2016 13:23:37 +0200
> > Jani Nikula escreveu:
> >
> >> On Thu, 18 Feb 2016, Mauro Carvalho Chehab
> >> wrote:
> >>> For simple documents like the one produced by
On 02/18/16 13:04, Mauro Carvalho Chehab wrote:
> Em Thu, 18 Feb 2016 13:23:37 +0200
> Jani Nikula escreveu:
>
>> On Thu, 18 Feb 2016, Mauro Carvalho Chehab wrote:
>>> For simple documents like the one produced by kernel-doc, I guess
>>> all markup languages would work equally.
>>>
>>> The probl
Em Thu, 18 Feb 2016 13:23:37 +0200
Jani Nikula escreveu:
> On Thu, 18 Feb 2016, Mauro Carvalho Chehab wrote:
> > For simple documents like the one produced by kernel-doc, I guess
> > all markup languages would work equally.
> >
> > The problem is for complex documents like the media kAPI one, wh
On Thu, 18 Feb 2016, Mauro Carvalho Chehab wrote:
> For simple documents like the one produced by kernel-doc, I guess
> all markup languages would work equally.
>
> The problem is for complex documents like the media kAPI one, where
> the document was written to produce a book. So, it uses some co
Em Thu, 18 Feb 2016 10:24:04 +0100
Daniel Vetter escreveu:
> On Thu, Feb 18, 2016 at 10:11 AM, Jani Nikula wrote:
> > On Thu, 18 Feb 2016, Daniel Vetter wrote:
> >> On Wed, Feb 17, 2016 at 11:14 PM, Jonathan Corbet wrote:
> >>> On Sun, 14 Feb 2016 13:27:04 +0100
> >>> Daniel Vetter wrote:
On Thu, Feb 18, 2016 at 10:11 AM, Jani Nikula wrote:
> On Thu, 18 Feb 2016, Daniel Vetter wrote:
>> On Wed, Feb 17, 2016 at 11:14 PM, Jonathan Corbet wrote:
>>> On Sun, 14 Feb 2016 13:27:04 +0100
>>> Daniel Vetter wrote:
>>>
One concern/open I have for pro/cons are the hyperlinks from kern
On Thu, 18 Feb 2016, Daniel Vetter wrote:
> On Wed, Feb 17, 2016 at 11:14 PM, Jonathan Corbet wrote:
>> On Sun, 14 Feb 2016 13:27:04 +0100
>> Daniel Vetter wrote:
>>
>>> One concern/open I have for pro/cons are the hyperlinks from kerneldoc
>>> comments. Currently we have the postproc hack, iirc
On Wed, Feb 17, 2016 at 11:14 PM, Jonathan Corbet wrote:
> On Sun, 14 Feb 2016 13:27:04 +0100
> Daniel Vetter wrote:
>
>> One concern/open I have for pro/cons are the hyperlinks from kerneldoc
>> comments. Currently we have the postproc hack, iirc Jani's patches
>> generated links native when ext
On Sun, 14 Feb 2016 13:27:04 +0100
Daniel Vetter wrote:
> One concern/open I have for pro/cons are the hyperlinks from kerneldoc
> comments. Currently we have the postproc hack, iirc Jani's patches
> generated links native when extracting the kerneldoc. What's the
> solution with spinx?
So I've
Jonathan Corbet writes:
> Indeed, I doubt many people want the DocBook itself.
Might be nice to actually have a set of requirements before anyone tries
to select a suitable system then :-)
Here's my current set:
asciidocsphinx
htmlvia docbook native
native (kin
On Tue, 16 Feb 2016 11:13:29 -0800
Keith Packard wrote:
> https://github.com/HolgerPeters/sphinxcontrib-docbook
>
> which appears to provide docbook output for sphinx, but I haven't tested
> this at all.
Yup, that's the one I found, the one that says "Very much work in
progress". It look
Jani Nikula writes:
> However I didn't think Sphinx could produce docbook, and a quick search
> doesn't convince me otherwise. Do you have some links to back this up?
> Would the lack of docbook be a showstopper? (Of course, the pandoc
> swiss-army knife can handle rst->docbook if needed.)
A qui
On Tue, 16 Feb 2016, Jonathan Corbet wrote:
> Whether this is a show-stopper is indeed a good question. I doubt many
> people wanted the DocBook for its own sake, it's a matter of where you
> can go from there. But yes, it would be good to be sure on this point.
So the question is, are HTML, la
On Tue, 16 Feb 2016 10:25:49 +0200
Jani Nikula wrote:
> However I didn't think Sphinx could produce docbook, and a quick search
> doesn't convince me otherwise. Do you have some links to back this up?
Somehow I was really sure of it, but I'm not finding it now. There is an
extension out there,
On Sat, 13 Feb 2016, Jonathan Corbet wrote:
> So can we discuss? I'm not saying we have to use Sphinx, but, should we
> choose not to, we should do so with open eyes and good reasons for the
> course we do take. What do you all think?
FWIW I was in favor of reStructuredText to begin with, but d
Daniel Vetter writes:
> The other one is graphs - Keith showed me some neat stuff that
> asciidoc can do, and I definitely wanted to integrate something like
> that as a follow-up into the kerneldoc toolchain. Often a diagram is a
> lot more helpful than lots of words. Can sphinx gives us that to
On Sun, Feb 14, 2016 at 1:57 AM, Keith Packard wrote:
> Jonathan Corbet writes:
>
>> Asciidoc is a credible solution to the formatted documentation problem,
>> but it's not the only such; I'd like to be sure that we pick the right
>> one. I worry that asciidoc seems to be aimed mostly at small d
Jonathan Corbet writes:
> Asciidoc is a credible solution to the formatted documentation problem,
> but it's not the only such; I'd like to be sure that we pick the right
> one. I worry that asciidoc seems to be aimed mostly at small documents,
> and that the project itself seems a little lifele
So I fear you all are going to hate me for this...
Asciidoc is a credible solution to the formatted documentation problem,
but it's not the only such; I'd like to be sure that we pick the right
one. I worry that asciidoc seems to be aimed mostly at small documents,
and that the project itself see
94 matches
Mail list logo
