All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	George Dunlap <george.dunlap@citrix.com>
Subject: [PATCH 3/5] SUPPORT.md, support matrix: Treat commentary before status as description
Date: Thu, 12 Apr 2018 19:26:41 +0100	[thread overview]
Message-ID: <1523557603-22218-4-git-send-email-ian.jackson@eu.citrix.com> (raw)
In-Reply-To: <1523557603-22218-1-git-send-email-ian.jackson@eu.citrix.com>

Running text in feature sections in the markdown document currently
might be (i) a caveat, qualifying or clarifying the support statement
(ii) a plain description of the feature.

Caveats can be version-specific and deserve the [*] annotation in the
relevant feature matrix cell.  They must link to SUPPORT.html for the
specific version.

Descriptions are not version specific.  In that case the [*]
annotation is visusal noise.  Rather, it is better to make a hyperlink
out of the text which is being expanded on.  The hyperlink can point
to any appropriate version.

There is a question about how to notate this distinction in
SUPPORT.md.  After IRL discussion with George and Lars I propose that
we should put text which helps describe a feature (ie, which expands
on a section heading) after the heading but before the Status
indications; whereas, caveats and supplementary information about
the actual status, should follow the Status block.

This patch implements this distinction in the support matrix
generator.  Only paragraphs containing _only_ italic content count as
descriptive; anything else is treated as a caveat.

In the code:

 * Add a new entry to RealSect, HasDescription

 * When parsing, track whether we are before or after the first Status
   block in a new variable $has_feature.

 * In ri_Para, set HasDescription set to the input document index
   when we encounter text before the first feature.

 * When writing a `heading' (ie, the table cell for a feature name)
   look for HasDescription and make an appropriate hyperlink.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 docs/parse-support-md | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/docs/parse-support-md b/docs/parse-support-md
index 6953930..653d216 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -35,6 +35,7 @@ our $toplevel_sectlist = new_sectlist();
 # $sectlist->{KEY}{Key} = KEY
 # $sectlist->{KEY}{RealSect} = containing real section in @insections, so
 # $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para
+# $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para
 # $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
 # A $sectnode represents a single section from the original markdown
 # document.  Its subsections are in Children.
@@ -58,8 +59,10 @@ our @insections;
 # these next are only defined for real sections, not Status elements
 # $insections[]{Anchor} = string
 # $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this
+# $insections[]{HasDescription} VI, likewise
 
 our $had_unknown;
+our $had_feature;
 # adding new variable ?  it must be reset in r_toplevel
 
 #---------- parsing ----------
@@ -78,13 +81,20 @@ sub ri_Header {
          Anchor => $id,
          Headline => $hl,
          HasCaveat => [],
+         HasDescription => undef,
         };
 #print STDERR Dumper(\@insections);
+    $had_feature = 0;
 }
 
 sub ri_Para {
-    if (@insections) {
-        $insections[$#insections]{HasCaveat}[$version_index] = 1;
+    return unless @insections;
+    my $insection = $insections[$#insections];
+
+    if ($had_feature) {
+        $insection->{HasCaveat}[$version_index] = 1;
+    } else {
+        $insection->{HasDescription} //= $version_index;
     }
 };
 
@@ -92,6 +102,8 @@ sub parse_feature_entry ($) {
     my ($value) = @_;
     die unless @insections;
 
+    $had_feature = 1;
+
     my $sectnode;
     my $realsect;
     foreach my $s (@insections) {
@@ -183,6 +195,7 @@ sub r_toplevel ($) {
 
     @insections = ();
     $had_unknown = undef;
+    $had_feature = undef;
 
     foreach my $e (@$i) {
         next unless ref $e eq 'ARRAY';
@@ -346,7 +359,14 @@ sub write_output_row ($) {
         $span->('col', $maxdepth - $heading->{Depth} + 1)
             if !%{ $heading->{Children} };
         o(' align="left">');
+        my $end_a = '';
+        my $desc_i = $heading->{RealSect}{HasDescription};
+        if (defined $desc_i) {
+            o(docref_a $desc_i, $heading->{RealSect});
+            $end_a= '</a>';
+        }
         o($heading->{Headline});
+        o($end_a);
         o('</th>');
     }
     if (%{ $sectnode->{Children} }) {
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2018-04-12 18:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 18:26 [PATCH 0/5] SUPPORT.md: Distinguish descriptions from caveats Ian Jackson
2018-04-12 18:26 ` [PATCH 1/5] docs/parse-support-md: internals: Introduce docref_a Ian Jackson
2018-04-12 18:26 ` [PATCH 2/5] docs/parse-support-md: internals: Rename HasText to HasCaveat Ian Jackson
2018-04-12 18:26 ` Ian Jackson [this message]
2018-04-12 18:26 ` [PATCH 4/5] SUPPORT.md: Move descriptions up before Status info Ian Jackson
2018-04-13 11:31   ` Lars Kurth
2018-04-17 13:22     ` Ian Jackson
2018-04-17 15:49       ` Lars Kurth
2018-04-12 18:26 ` [PATCH 5/5] SUPPORT.md: Document the new text ordering rule Ian Jackson
2018-04-13 10:14   ` Lars Kurth
2018-04-13 10:31     ` Ian Jackson
2018-04-13 11:58       ` Lars Kurth
2018-04-12 18:29 ` [PATCH 0/5] SUPPORT.md: Distinguish descriptions from caveats Ian Jackson
2018-04-13  7:56   ` Lars Kurth
2018-04-13  4:37 ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1523557603-22218-4-git-send-email-ian.jackson@eu.citrix.com \
    --to=ian.jackson@eu.citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jgross@suse.com \
    --cc=lars.kurth@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.