On +2019-12-03 15:12:32 +0100, Ricardo Wurmus wrote:
>
> Konrad Hinsen <konrad.hin...@fastmail.net> writes:
>
> >> Could this discussion be saved in the cookbook for instance? I'd like
> >> to have this kind of discussion on the approach of guix and ideas
> >> behind it somewhere more accessible than the ML archive. Does it make
> >> sense?
> >
> > I think it makes sense to archive summaries of such discussions. I am
> > less convinced that the cookbook is the right place, because design
> > principles are pretty much the opposite of what I'd expect in a
> > cookbook. But I don't see any better place and multiplying the parts of
> > the documentation isn't great either. So... I am undecided ;-)
>
I would like to see useful info and tested guix (and related) usage examples
accumulate in a knowledge base for easy searching and extraction, however it's
named.
I regularly snip out examples from developer postings as grist for my personal
how-to notes, but that doesn't help others, and no common resource grows.
I think as much as possible ought to be automated, therefore I am proposing
... (well, sketching out half-baked proposal ideas :) ...
that some sort of delimiting syntax be defined to make automated extraction
and re-presentation of search results easy and effective.
I think the mailing list archives could serve as a knowledgebase if
desirable posting content in our emails were delimited with a MIME-inspired
extension
of the established: "--8<---------------cut
here---------------start------------->8---"
delimiter.
When a thread comes to an agreed conclusion, it should not be hard to wrap a few
paragraphs in appropriate delimiters. Maybe use rc-n versioning in leadup?
I would suggest making delimited text unique too, by leveraging some prefix
characters
of base32 of content, along with some identifying info. Side benefit: big search
engines will find them for you, wherever copies wind up.
In fact, if we adopted real MIME multipart delimiters with the final one ending
with
"--" appended, it would open many possibilities (and probably tap into lots of
existing parsing tools).
But guix-specifically, for guile processing of text with mime-delimited
sections,
maybe someone --( I tried some time ago, but got no sa-tis-faction ;-/ )--
could make a guile module that could be imported to define a reader macro e.g.
like #--"boundary" which would chew through input and convert
it into a list of (header . content) pairs until the final "\n--boundary--" is
encountered.
Think of it as a super-quote that can quote anything, even broken quote syntax
from other
languages and of course unbalanced quoting and bracketing from lispy languages.
Hm. maybe a special #L language switch to do the parsing?
Anyway, both the header and the content of the macro output pair would be
string,
since I am just sketching a way to quote and identify desirable text in emails
and media already rendered as text (though of course lots can be done with the
raw email).
This would serve as a way to quote "foreign" language source for use
embedded in guile code. You could quote make files and bash scripts and
whatever.
I am working on something that incorporates very similar functionality, but I
offer
this misleading mish-mosh so you won't die holding your breath :)
--proposed sketch for mime reader macro
Comment: part 1: reader macro usage example
(define mime-stuff #--"ad lib"
garbage up to first delimiter is first header like rfc0822
--ad lib
first header
first content after blank line
no newline
--ad lib
content with default header
content ends with newline
--ad lib--
;; reader macro exits, normal reader resumes
)
--proposed sketch for mime reader macro
Comment: part 2: net effect of reader macro
Comment: just out of my head, totally untested, just to get the idea out
;; so the above reader macro incantation becomes equivalent
;; in result as if this had been written instead
(define mime-stuff '(\
(" garbage up to first delimiter is first header like rfc0822" . "") \
("first header" . "first content after blank line\nno newline") \
("" . "content with default header\ncontent ends with newline\n" ))
)
--proposed sketch for mime reader macro--
see (proposal) below for another way of tagging snippets ;-)
--8<---------------cut here---------------start------------->8---
Comment: The immeadiatly above typical guix snippet delimiter
might be a legal MIME delimiter, even though it's not paired with the
identical line with "--" appended to form the ending delimiter.
Comment: per rfc0822 the first lines after the starting delimiter constitute
a header, terminated by a blank line. Header lines may be folded
by breaking linear whitespace to a new line starting with at least one linear
white space char, like these two Comments: lines.
So this line is the first content line, following the blank line.
This is still content, including blank lines, up to the final delimiter.
--8<----(proposal)-----------cut here---------------start------------->8---
This is nested and tagged as "proposal"
I think using the existing guix delimiter style, we could add tags and headers
designed
to make extraction of cookbook (knowledge-base?) materials from posts and
archives
automatable, generating nice snippets with footnoted urls and attributions etc
from email headers.
--8<----(proposal)-----------cut here---------------end--------------->8---
--8<----(code contribution: untested)-----------cut
here---------------start------------->8---
Comment: bash invocation of guile.
guile -c $'(display "I am a code snippet")(newline)'
--8<----(code contribution: untested)-----------cut
here---------------end--------------->8---
--8<----(possible markup for extraction)-----------cut
here---------------start------------->8---
Comment: would X-Content-Type: dangerous?;
be bad here? Not sure of the rules. Email should just encapsulate what I
write, so
we should be able to process as we wish with custom tools, IWT
┌────────────────────────────────────────────────┐
│ not sure boxes are a good idea │
├────────────────────────────────────────────────┤
│ > We can rename the cookbook to make it fit ;) │
└────────────────────────────────────────────────┘
>
+-------------------------------------------------------------------------+
| not sure boxes are a good idea -- ascii safer? |
+-------------------------------------------------------------------------+
| > It was a placeholder name, because we all agreed for some time that a |
| > “document” like that would be useful and that it shouldn’t be a wiki. |
| > Beyond that we really didn’t have any plans. I went ahead and |
| > started it to enable collaboration on this resource — whatever it may |
| > become eventually. |
+-------------------------------------------------------------------------+
--8<----(possible markup for extraction)-----------cut
here---------------end--------------->8---
HTH trigger some ideas :)
Here comes the final delimiter, guix style, not real mime terminal delim,
recognized by having skipped paired "--8<----(something ..." delims as well as
plain.
--8<---------------cut here---------------end--------------->8---
--
Regards,
Bengt Richter
