• Nicer formatting of tcl-bugs mailing list messages?

    From Torsten Berg@21:1/5 to All on Thu Sep 2 06:12:45 2021
    Hi,

    I am subscribed to the tcl-bugs mailing list and often wondered whether it could be made more readable ...

    As I see it, the content of the mailings is produced by fossil (probably from core.tcl-lang.org). They are sent to sourceforge where the actual mailing list is hosted. Sourcefore then manages send the messages to us subscribers.

    Assuming this is true, can we do something about the initial section producing the daily digest, something sourceforge is doing? It looks like this:

    ---------------
    Send Tcl-Bugs mailing list submissions to
    tcl-bugs@lists.sourceforge.net

    To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/tcl-bugs
    or, via email, send a message with subject or body 'help' to
    tcl-bugs-request@lists.sourceforge.net

    You can reach the person managing the list at
    tcl-bugs-owner@lists.sourceforge.net

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of Tcl-Bugs digest..."
    Today's Topics:

    1. [Tcl] (pooryorick) tkt (New): namespace ensemble subcommand
    name prefix matching and a subsequent error results in a
    segmentation fault (andreas.kupries@gmail.com)
    2. [Tcl] (pooryorick) com (main): Fix for [ccc448a6bfd59cbd],
    namespace ensemble subcommand name prefix matching and a
    subsequent error results in a segmentation fault
    (andreas.kupries@gmail.com)
    3. [Tcl] (pooryorick) tkt (Open): namespace ensemble subcommand
    name prefix matching and a subsequent error results in a
    segmentation fault (andreas.kupries@gmail.com)
    4. [Tk] (fvogel) com (tk_badges): Move code after input argument
    checking. (andreas.kupries@gmail.com)
    5. [Tk] (fvogel) com (tk_badges): Remove useless statements.
    (andreas.kupries@gmail.com)
    6. [Tk] (fvogel) com (tk_badges): Cosmetic changes
    (andreas.kupries@gmail.com)
    ---------------

    There is too much noise in there when the first thing that I would like to so is something along these lines:


    -------
    1. Tcl: namespace ensemble subcommand
    name prefix matching and a subsequent error results in a segmentation fault

    2. Tcl: Fix for [ccc448a6bfd59cbd]
    namespace ensemble subcommand name prefix matching and a subsequent error results in a segmentation fault

    3. Tcl: namespace ensemble subcommand
    name prefix matching and a subsequent error results in a segmentation fault

    4. Tk: Move code after input argument checking.

    5. Tk: Remove useless statements

    6. Tk: Cosmetic changes
    -------

    Can such a reformatting be done on suourceforge or not? It seems that the subject line of the original mail (coming from fossil) is used and then put into that digest section. So probably this cannot be changed anyway?

    Afterwards, the digest contains the bodies of the individual mails. These are formatted in a way that some key name (e.g. Commit, By, For, ..., Description, Changed Files, icomment) are followed by some values representing the content of the keys. This
    must be from fossil as it contains fossil "slang" (icomment, Change Fields, ...). How do you produce this format? Looking into how notifications work in fossil, I cannot see any method to produce that kind of mail. However, as it is some key-valie format,
    it should be easy to parse and thus also to be transformed and get some "markup" in order to render it in a pretty way (e.g. with HTML tags).


    This is something I am just testing on my fossil repo, where I take the message produced by fossil's notification system, feed it into a Tcl script which tries to guess some formatting and injects some HTML tags, then feeds the result into msmtp to send
    the actual notificatiomn mail:


    # remove carriage returns from msg data since tcllib mime does not handle these:
    set msg [string map {\r ""} $msg]
    # parse the message to extract the parts:
    set token [::mime::initialize -string $msg]
    set recipient [string trim [::mime::getheader $token To] <>]
    set body [::mime::getbody $token -decode]
    if {[string range [string trim $body] 0 4] eq "Forum"} {
    package require Markdown
    set body [::Markdown::convert $body]
    } else {
    set body [string map [list \n <br>] $body]
    set body [string map [list <br>== <h1> ==<br> </h1>] $body]
    }
    # these nexrt two lines are a hack since we are writing directly to the internal representation
    # of the mime package, i.e. the array behind the $token variable,
    # not using official commands (as they are not implemented (yet))
    # (the vaiable $token contains the name of an array holding the various parts of the mime)
    set [set token](content) "text/html"
    set [set token](string) $body
    set msg [::mime::buildmessage $token]
    set rc [exec /usr/local/opt/msmtp/bin/msmtp --account=ionos -t $recipient << $msg]
    mime::finalize $token


    It would be great if we could do something similar to the mail coming over the tcl-bugs mailing list.

    Torsten

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Torsten Berg@21:1/5 to Torsten Berg on Sun Sep 12 03:22:16 2021
    No idea, no-one? Is the procedure to produce the messages not even documented anywhere?

    On Thursday, September 2, 2021 at 3:12:47 PM UTC+2, Torsten Berg wrote:
    Hi,

    I am subscribed to the tcl-bugs mailing list and often wondered whether it could be made more readable ...


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Donal K. Fellows@21:1/5 to Torsten Berg on Sat Sep 18 01:24:58 2021
    On Sunday, 12 September 2021 at 11:22:17 UTC+1, Torsten Berg wrote:
    Is the procedure to produce the messages not even documented anywhere?

    The basic message generation is run by Andreas Kupries. The generation of the digests is done by mailman as part of the service that runs the mailing list.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)