Re: various Lout requests made by Mark Summerfield

[Jeff Kingston]

Dear Mark,

I've been going through your emails while preparing the next release
of Lout.  I've sorted everything out except for the weird problem
with inter-line gaps.  My responses follow.

I will be away for a few days.  When I return I will work on
the only other major thing to be done for the next release,
which is incorporating Ludovic's user style stuff.

* import @BasicSetup def @QC right address@hidden pipe{x}{}}

  This does actually call for all occurrences of x in the body of @QC to
  be replaced by the actual parameter, so when you see all occurrences
  of x in your program text being replaced by your pipe command, Lout
  is doing what it should.  In general, it's good for filters to be
  able to spit out Lout symbols that are subsequently interpreted as
  such by Lout.
  
  The fault, then, lies in prg2lout, which should enclose in quotes
  every scrap of program text that it ever outputs, since it's to be
  treated verbatim.  However I have not changed prg2lout since the
  workaround (replace x with a longer name, as you found) is so
  simple and there may be places where unquoted prg2lout output is
  useful; I'm not sure.

* Ellipsis symbols in Python texts.  I've fixed this by adding a ...
  token to Python, and ensuring that tokens with dots get enclosed in
  double quotes.  This may have some effect in some other languages.

* Style changes in concatenation operator lengths, as in

      A |{{Crystal Base 9p} @Font 4f} B

  I've fixed this.  It may still go wrong in obscure cases, I'm not
  sure (the code is horrible), but this and most cases should work now.

* Excessive inter-line gaps when using "lines @Break".  I've looked at
  this and I agree it looks like a bug.  I've sent you a separate email
  asking for a complete test that I can unpack and run.

* A command which runs a pipe and includes its output verbatim, as in
  your hypothetical example
  
     @Verbatim pipe{"my command that does it"}{}

  See the forthcoming @Pipe, @PipeVerbatim, and @PipeRawVerbatim symbols,
  documented in the Verbatim section of Chapter 2 of the User's Guide.

* Missing running header above figure.  I believe that Lout is behaving
  reasonably here, because on odd-numbered pages you have asked for the
  current section number and title to be displayed (see @RunningOddTop
  in file book.lout), but there is no current section at the top of
  that page.  It is true that a section starts lower down, and also
  true that if the figure was not there Lout would use that section as
  the basis of the running title.  But I don't think it's unreasonable
  to not print a section number and title if there is no section at
  the top of the page.

  A good way to work around this would be to make a new section, called
  "Introduction" or something, out of most of your introductory text.

  There is a fun way to investigate this issue.  In file dsf the body
  of the @Runner symbol (around line 934) is usually @Null, but if you
  replace the @Null by, say,
  
      red @Colour "(@Runner:"@MajorTitle":"@MinorTitle")"

  you get to see all the runners inserted by Lout.  Running headers
  and footers are based on the first runner following the top of
  their page.  @Figure and @Table insert a runner which duplicates
  the previous runner, so that when they appear alone at the end of
  a chapter a suitable runner appears with them.  This runner is
  hiding the section runner lower down the page in your example.

* Suggestion for a quartercircle shape for @Diag.  I have not done
  this since I feel it's a bit specialized.  It's easy to get it
  by making your own node outline, as you know.

* Suggestion for an arrowhead that looks like -->| in @Diag.  I
  have done this, in such a way that when two of these arrows meet
  from opposite directions their bars overstrike, as you suggested.

* No space follows a TryAfterLine figure that ends up at the top
  of the page.  I see you have @TopGap { 0c } in one of your
  setup files, and I suspect this is why you have no space there.
  Let's keep talking if resetting @TopGap to a more usual value
  does not fix the problem, or if it causes other problems.

Jeff