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 before BI> > BI> DSSSL processing begins. So, just because you "skip" a section of the BI> > BI> document in your DSSSL script doesn't mean that it won't get parsed. 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 code. 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 "escape" BI> > relatively common symbols. Failing to properly escape the significant BI> > punctuation (usually an "@") is one of the more common LP processor mistakes BI> > I make, and that's with a punctuation mark that's not real common in the 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 <, >, and & 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 WEB). 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: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Issues with literate programmin, Brandon Ibach | Thread | Re: Issues with literate programmin, Brandon Ibach |
Re: images, notations, backends, Matthias Clasen | Date | Re: Issues with literate programmin, Brandon Ibach |
Month |