Re: An idea

[Hans Hagen <pragma@wxs.nl>]

Nikolai Weibull wrote:

>That’s just horrendous.  The ‘n’ attribute on ‘line’ is useless (and why
>are empty lines unnumbered?).  You can just as easily use XSLT’s
><number/> to get that effect:
>  
>
if i remember right it has to to with the fact that while editing 
inserted lines were treated different (sub numbers and such) so n is not 
om forehand something going up in steps of 1; it's more a status thing

>Furthermore, the ‘n’ attribute on ‘t’ is equally useless.  How am I to
>know what “3” stands for when converting?
>  
>
in scite that's related to styles which have numbers (no symbolic names)

>Finally, what’s the reason for having ‘s’?  It just complicates matters
>immensely:
>
>  <xsl:template match="scite:s">
>    <xsl:call-template name="print-spaces">
>      <xsl:with-param name="n" select="@n"/>
>    </xsl:call-template>
>  </xsl:template>
>  
>
having access to spaces (without the need to xslt the file) can be handy 
if you want to treat them special (e.g. visualize them); keep in mind 
that in xml mode we don't have active character trickery available

actually, it's one of the reasons why i dislike cdata being used for 
verbose content instead of tagged content

<lines>
<line>...</line>
</lines>

is easier to interface to certain typesetting things

btw, when we process xml here, i often have to preprocess the files 
(using ruby and regexps) just in order to add some detail that permits 
proper typesetting

>  <xsl:template name="print-spaces">
>    <xsl:param name="n"/>
>    <xsl:if test="number($n) > 0">
>      <xsl:text> </xsl:text>
>      <xsl:call-template name="print-spaces">
>        <xsl:with-param name="n" select="number($n) - 1"/>
>      </xsl:call-template>
>    </xsl:if>
>  </xsl:template>
>
>The problem is that the ‘n’ attribute has a default of 1, but as there’s
>no way to express default values for attributes in Relax-NG (and there’s
>no schema at the bogus url http://www.scintila.org/scite.rng) we’d have
>to hack it even more.
>
>Could you enlighten me on the merits of having a tag for representing
>(sequences of) whitespace?
>  
>
as said, in order to be able to treat them kind of special

btw, it's all configurable:

export.xml.collapse.spaces=1
export.xml.collapse.lines=1

so .. it's just what i needed (at that time) which was an alternative 
for the latex output mode that i could not use

>Here’s a suggestion for a better grammar:
>
>ID.datatype = xsd:ID
>LanguageCode.datatype = xsd:language
>
>id.attrib = attribute id { ID.datatype }?
>xmlbase.attrib = attribute xml:base { text }?
>Core.attrib = id.attrib, xmlbase.attrib
>lang.attrib = attribute xml:lang { LanguageCode.datatype }?
>I18n.attrib = lang.attrib
>Common.attrib = Core.attrib, I18n.attrib
>
>start = file | line | segment | whitespace
>
>file = element file { file.attlist, file.content }
>file.attlist = Common.attrib, attribute path { text }, attribute type { text }
>file.content = line*
>
>line = element line { line.attlist, line.content }
>line.attlist = Common.attrib
>line.content = (segment | whitespace)*
>
>segment = element segment { segment.attlist, text }
>segment.attlist = Common.attrib, attribute type { text }
>
>whitespace = element whitespace { whitespace.attlist, empty }
>whitespace.attlist = Common.attrib
>
>I’m sure that there are things missing and that it can be improved
>further, but it’s a good start in my opinion.
>
>What I can’t decide is whether to write things like
>
><line>
>  <segment type="type">int</segment><whitespace/><segment type="normal">a;</segment>
></line>
>
>or
>
><line>
>  <type>int</type><whitespace/><normal>a;</normal>
></line>
>
>The first scheme is easier to extend with more types, if we don’t
>validate the value of segment’s ‘type’ attribute (if we do, then both
>schemes are equally “easy” to extend), but the second scheme has the
>benefit that as much validation as possible can go into the schema and
>can thus ease translation.
>
>I envision that the XSLT ConTeXt-converter for this scheme would have
>code in one of these two formats:
>
><xsl:template match="segment">
>  \highlight[<xsl:value-of select="@type"/>]{<xsl:value-of select="."/>}
></xsl:template>
>
>or
>
><xsl:template match="type|normal|comment|...">
>  \highlight[<xsl:value-of select="local-name(.)"/>]{<xsl:value-of select="."/>}
></xsl:template>
>
>I really don’t know what I prefer.  The first means that only the source
>and destination need to worry about dealing with new types (the
>stylesheet can be used unchanged).
>  
>
it depends a bit on what an editor can provide; the scite xml output is 
rather connected to its lexer, and since each lexer is different there 
is no strict relationship between a number and e.g. a type. As a result, 
stylesheets need to have that kind of (conversion) knowledge.

it's not clear to me how you want to use these code snippets

- if you're going to copy them into your tex document, i'd leave them in 
xml format, i.e. have a mixed tex/xml doc (no need for conversion since 
we're dealing with rather simple xml->tex mapping sthat can be done by 
context itself)
- if you keep them in the source file, you need a way to filter them 
into your main text document (this is what i do when i nedd to document 
for stylesheets and such: i filter the pieces i needed while typesetting)

>>about an article ... it would be interesting to combine thsi with a kind 
>>of literate programming
>>    
>>
>
>Yes, that’s true.  I used a simple hack to my code written in literate
>programming into my master’s thesis.  It worked quite well actually.
>I’m sure that this could be combined with the method I used there.
>  
>
so how does this work?

some text

[reference to code snippet]

some more text

where you merge in the code snippets before processing?

>  
>
>>(if cweb would produce better output then it may have become a  bit
>>more popular)
>>    
>>
>
>Yes.  I see three problems with CWEB:
>
>1.  The syntax is too complicated
>2.  The output is not great
>3.  The input isn’t compilable in the source programming language
>
>What my literate programming system did was allow for embedding comments
>in the source instead of the other way around (much like how ConTeXt
>sources are documented).  This worked very well actually, especially in
>the parts of my code that were written in Ruby where one can do things
>like
>
># ¶ OK, so now that we have all the other methods done, it’s time to
># write our final method \Ruby{method}.  It will simply tie together the
># other methods found in \Ruby{Class}:
>  
>
why not

# write our final method \RubyM[Class.method].  It will simply tie together the
# other methods found in \RubyC[Class.method]:

and let that info be auto-inserted? Now you have to edit three (probably 
more) places when you change the name of the method.

>def Class.method
>  ⋮
>end
>
>(A sequence of comments where the first comment began with a pilcrow
>sign are processed as stuff to send to ConTeXt and the following code
>block (basically everything up to the next pilcrow-endowned comment) was
>set inside a verbatim environment.)
>
>Anyway, I’ve attached the Relax-NG schema that I deviced.  Tomorrow I’m
>going to work on writing an exporter that exports to this format and a
>stylesheet that transforms this to ConTeXt code.  If I have time I’ll
>also try to set up some environment for this and some generic
>preprocessing directives for texexec.
>  
>
ok

Hans