This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: multistring.el
- To: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>
- Subject: Re: multistring.el
- From: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Date: 17 Jan 2000 10:41:36 -0800
- Cc: mstachow at alum dot mit dot edu, guile at sourceware dot cygnus dot com
- References: <E12A3CR-0006IS-00@mdj.nada.kth.se>
Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> --Multipart_Mon_Jan_17_04:51:27_2000-1
> Content-Type: text/plain; charset=US-ASCII
>
> Sorry for being so late---I've had other stuff to work on during the
> weekend.
>
> Please test the code and comment upon its behaviour.
>
> Load the file beneath, place yourself on a string to convert, then use
> C-c d to pack a string and C-u C-c d to unpack it.
>
> Before starting to convert all docstrings, I'd like us to decide how
> to treat docstrings which has some amount of internal formatting.
>
> E.g., how are we to indicate the following formatting to Guile:
>
> "@example
> (logtest j k) @equiv{} (not (zero? (logand j k)))
>
> (logtest #b0100 #b1011) @result{} #f
> (logtest #b0100 #b0111) @result{} #t
> @end example"
>
> The Emacs packing/unpacking of course only uses the information which
> is provided in the string. E.g., packing gives:
>
> "@example "
> "(logtest j k) @equiv{} (not (zero? (logand j k)))\n"
> "(logtest #b0100 #b1011) @result{} #f "
> "(logtest #b0100 #b0111) @result{} #t "
> "@end example"
>
> Note how formatting information has been lost here...
If we use SGML DocBook inside docstrings, this is not as much of an
issue because ws is not important to the mechanical tools (but it can be
essential to the human reader looking at raw docstrings, though ideally
that won't need to happen very often).
Is TeXInfo line-based? I.e., would those missing newlines cause it
trouble?
I still like the other formatting style better... IIRC, Maciej's main
argument for multi-string-literal-juxtaposition instead of \n\ was that
the latter is hard to type. With suitable emacs code, the \n\ is not
going to be typed.
While I, too, believe that storing unformatted text is better in the
long run, leaving the formatting to the display medium, it's easy enough
for tools to replace \n with spaces and then proceed re-line-breaking as
appropriate. In short, I think it's better to preserve line-breaks in
the literal string.
Greg