Re: Issues with literate programming DSSSL Script

Subject: Re: Issues with literate programming DSSSL Script
From: MARK.WROTH@xxxxxxxxxxx (Wroth, Mark)
Date: Thu, 23 Dec 1999 08:22:35 -0800
Brandon Ibach <bibach@xxxxxxxxxxxxxx> continued the discussion of handling
special characters (in the context of literate programming) 

BI> Quoting Wroth, Mark <MARK.WROTH@xxxxxxxxxxx>:
BI> > BI>    Keep in mind that the whole document is, essentially, parsed
BI> > BI> DSSSL processing begins.  So, just because you "skip" a section of
BI> > BI> document in your DSSSL script doesn't mean that it won't get
BI> > 
BI> > And I think I understand that the "bothersome" translations are
happening in
BI> > the parser, not in the DSSSL engine itself. Generally usually, a very
BI> > helpful thing, as it removes all sorts of special cases from the DSSSL
BI> > 
BI>    Actually, the translations that you refer to are happening on the
BI> *other* end of the line.  They are being done by the SGML backend as
BI> it writes the FOT out.  This is why we can defeat them with the
BI> formatting-instruction.  If you look at jade/TransformFOTBuilder.cxx,
BI> line 550 (or so), in the [Open]Jade source, you'll see the loop that
BI> writes out characters, and the special treatment of &, < and >.

and continues with some discussion of what the code he provided is doing,
which I have trimmed in this post.

BI> > >From a user perspective, it certainly would be nice to not have to
BI> > relatively common symbols.  Failing to properly escape the significant
BI> > punctuation (usually an "@") is one of the more common LP processor
BI> > I make, and that's with a punctuation mark that's not real common in
BI> > languages I write.
BI> > 
BI>    As far as writing by hand, I guess it's just something to get used
BI> to.  Any language has things like this that you need to learn.  I
BI> wrote C for years, faithfully surrounding my strings with
BI> double-quotes, only to have to learn to use single-quotes, instead,
BI> when I started doing a lot of SQL.  And every now and then, I throw
BI> myself a real curve ball when Postscript makes me use parens for
BI> strings. :)

That's essentially why I was willing to declare victory when I was able to
set up entities &lt;, &gt;, and &amp; that got the desired characters into
the output; all literate programming systems have this basic problem
(usually on the character "@", since that's what Knuth chose in the original

BI>    Of course, if your user is using a decent text editor (like vi :),
BI> you could set up key mappings to make this easier.  For instance, map
BI> &, < and > to insert the appropriate entity references, and map some
BI> other keys to allow the user to generate tags and entity references
BI> (where they'd need the actual characters).  Just a possibility... :)

I think this is a pretty straightforward extension to sgml-mode in emacs, as
well.  I'm trying to make this system generally useful, but I am the only
specific candidate user :-).

At some point, I'd love to design/specify or maybe even build a good
literate programming editor; something that lends itself to putting literate
programming into an integrated development environment.  Emacs
customizations can go part of the way (maybe more -- I'm by no means an
emacs guru).  But that's a problem *way* beyond anything I've even thought
of seriously tackling.

By the way, I discovered a serious flaw in the implementation I thought was
adequate (and which may possibly show up on the OpenJade site as a
commenting draft).  It fails to deal correctly with nested scrap references,
a fact which caused me some head scratching about how various modes work.
The (now working) redesign involved breaking up the functions of header and
continuation scraps into two different element types. While I think I could
have come up with a way to make the original DTD work, this provides a much
cleaner and enforceable syntax in the input file.  So I think it's an
overall improvement.

 DSSSList info and archive:

Current Thread