From: Peter C. McCluskey (pcm@rahul.net)
Date: Tue Sep 14 1999 - 12:50:13 CDT
Daniel.Stenberg@frontec.se (Daniel Stenberg) writes:
>> I currently have about 1700 lines of code in new modules devoted to the
>> linkquotes option
>
>Wow, that's a lot of code. Could you take a moment to describe the
>functionality of that feature? With a focus on implementation issues and
>details.
I'll try to do that by Friday at the latest.
>> and 600 lines in a new module devoted to the showhtml == 2 option.
>
>You say that this is similar to the text2html program. In what ways does it
>differ from it? Once again, I want some internal functionality described.
I tried to port the parts of the txt2html Perl code that affect web page
bodies to C with few changes to its structure and functionality. I probably
created a few minor differences unintentionally. I didn't port:
- header and footer related features
- its links dictionary
- its regexp stuff
- its command line options for configuring it
For converting links, instead of imitating txt2html, I used a convurls
function that I enhanced from the Hypermail 1.02 version of that function.
(I haven't yet looked at the differences between it and the ConvURLs in
the current version of Hypermail.) There were probably a few other
infrequently used features that I never found time to port.
It is invoked from the printbody function with the following calls:
void init_txt2html(void); /* called before printing the message body to */
/* initialize about 20 state variables */
void txt2html(FILE *fp, const struct body *bp, const char *id,
const char *subject, int msgnum, const char *inreply, const char *dir,
bool replace_quoted, int maybe_reply); /* htmlify the line from bp; */
/* send it to fp. */
void end_txt2html(FILE *fp); /* called at end of body to output any */
/* </PRE>, </UL>, and </OL>'s needed */
The txt2html function is called if !inheader after this if statement:
if (((bp->line)[0] != '\n') && (bp->header && !set_showheaders)) {...}
and is followed by a "continue".
>Speaking of how index tables are generated, I'd prefer to avoid new static
>options. All entries of index tables could be created using some kind of
>template instead, giving maximum flexibility.
A template system sounds like it could easily be a better way to
implement some of the Critmail changes.
I would expect any good template system for index files to make the
following options of mine redundant:
{"show_dates_first", &set_show_dates_first, BFALSE, CFG_SWITCH,
"# If On, When dates are displayed in index files, put them at\n"
"# the left end of the line, making it easier (if you're not using\n"
"# the usetable option) to compare message dates by aligning them.\n"},
{"verbose_links", &set_verbose_links, BTRUE, CFG_SWITCH,
"# Set to Off if you want more concise text than normal for\n"
"# links to next and previous messages\n"},
These two options could probably be added to a template system in
slightly cleaner ways than they are implemented in Critmail:
{"ditto_dup_subjects", &set_ditto_dup_subjects, BFALSE, CFG_SWITCH,
"# Set this to On to make index files smaller by replacing\n"
"# subjects that duplicate the subject on the line above\n"
"# with a pair of quote characters.\n"},
{"show_linecount", &set_show_linecount, BFALSE, CFG_SWITCH,
"# Set this to On to display a count of the number of lines\n"
"# in the body of each message is displayed at the end of\n"
"# lines in index files.\n"},
So I will withdraw my plans to submit patches for the show_dates_first
and verbose_links options, and will postpone submitting the ditto_dup_subjects
and show_linecount options until I see how the template system develops.
The following three options create additional files which relate to
existing files in ways that don't seem like a template system would
be likely to provide means of handling, so I'm inclined to argue they
should still be added as options in setup.c:
{"monthly_index", &set_monthly_index, BFALSE, CFG_SWITCH,
"# Set this to On to create additional index files broken up\n"
"# by month. A summary.html file will provide links to all the\n"
"# monthly indices.\n"},
{"yearly_index", &set_yearly_index, BFALSE, CFG_SWITCH,
"# Set this to On to create additional index files broken up\n"
"# by year. A summary.html file will provide links to all the\n"
"# yearly indices.\n"},
{"thread_file_depth", &set_thread_file_depth, INT(0), CFG_INTEGER,
"# If nonzero, break the threads index file into multiple files,\n"
"# with the initial message of each thread in the main index file\n"
"# along with links to files containing the replies. Setting this\n"
"# to 1 creates one file for each thread that has replies, and is\n"
"# recommended for archives with over a few hundred messages.\n"
"# Setting this greater than 1 will produce multiple levels of files\n"
"# for each thread whose replies are nested by more than 1 level,\n"
"# but that is rarely useful.\n"},
>> {"verbose_links", &set_verbose_links, BTRUE, CFG_SWITCH,
>> "# Set to Off if you want more concise text than normal for\n"
>> "# links to next and previous messages\n"},
>
>What does "more concise text than normal" mean in this case?
Here's an example - concise:
* [ Next ]In reply to: Rob Jellinghaus
versus verbose:
* Next message: Dani Eder: "Re: The Singularity"
* In reply to: Rob Jellinghaus: "Re: Argument against
self-reproducing nanites, 5"
-- ------------------------------------------------------------------------ Peter McCluskey | Critmail (http://crit.org/critmail.html): http://www.rahul.net/pcm | Accept nothing less to archive your mailing list