Ernst Reissner wrote:
Hello Jacob,
Reißner Ernst wrote:
[...]
All of these markup is not presentational like @table, it is content
markup, descriptive or even procedural. It allows other tools not
only to render, but to analyze and to verify.
I also strongly disagree that this kind of markup
Hello Jacob,
Reißner Ernst wrote:
[...]
All of these markup is not presentational like @table, it is content
markup, descriptive or even procedural. It allows other tools not
only to render, but to analyze and to verify.
I also strongly disagree that this kind of markup is really language
spe
Reißner Ernst wrote:
[...]
All of these markup is not presentational like @table, it is content markup, descriptive or even procedural.
It allows other tools not only to render, but to analyze and to verify.
I also strongly disagree that this kind of markup is really language specific.
Parame
-Ursprüngliche Nachricht-
Von: Patrice Dumas
Gesendet: Samstag, 19. Februar 2022 15:55
An: Reißner Ernst
Cc: bug-texinfo@gnu.org; rei3...@arcor.de
Betreff: Re: Feature request: api docs
On Mon, Feb 07, 2022 at 08:30:15AM +, Reißner Ernst wrote:
>
> Well, I think texinfo was used
@Gavin: who shall we work on this? Discussion in this group? Subgroup?
-Ursprüngliche Nachricht-
Von: Gavin Smith
Gesendet: Montag, 14. Februar 2022 14:22
An: Reißner Ernst
Cc: bug-texinfo@gnu.org; rei3...@arcor.de
Betreff: Re: Feature request: api docs
On Mon, Feb 14, 2022 at 01:07:5
On Mon, Feb 7, 2022 at 8:19 AM Reißner Ernst wrote:
> @Gavin Smith : the style I know is putting api docs with the code.
> This turned out to be by far safest to keep docs up to date.
> In java world, in c#, in c and c++ I think this is the accepted way to do it.
> Also in lisp and in python...
> It seems to me that what is in the numpydoc specification is somewhat too
> specific to be
> relevant for Texinfo. However, I also think that we should make sure that a
> corresponding
> formatting can be achieved, even if without some specific semantic. It seems
> to me that almost
> ev
I must correct myself: @result and @error are not usable,
Because it has also semantics and within apidocs this would be misuse.
I think @param, @return and @throws would be fine at least for functions.
The above shall be to describe sth, like so:
@return the return value is the @var{n} th prim
-Ursprüngliche Nachricht-
Von: Gavin Smith
Gesendet: Freitag, 4. Februar 2022 18:27
An: Reißner Ernst
Cc: bug-texinfo@gnu.org; rei3...@arcor.de
Betreff: Re: Feature request: api docs
CAUTION: This email originated from outside your organization. Exercise caution
when opening attachme