On April 5, 1999 at 17:58, Rob Nagler wrote:
How 'bout a question like: "Why aren't my links getting updated when a new
message is added?" This is what I asked when I went to look at the code.
The question is ambiguous and implies a bug (not a FAQ). What you mean
is: "Why isn't link formatting getting updated in existing archived
messages when I change the proper resources and add new messages?"
I read the manual carefully (honest!), but I didn't get the impression
that only some resources were "rewritable" while others weren't. I only
From the SUBJECTHEADER resource page:
SUBJECTHEADER defines the markup for the main subject line above the
message header of message pages. If the SUBJECTHEADER resource is
==>changed and messages already exist in the archive, the existing
==>messages will not inherit the change. Therefore, you need to be sure
about the value of SUBJECTHEADER when creating an archive.
From the HEADBODYSEP resource page:
NOTE If HEADBODYSEP is changed, the existing messages in the archive
will not get changed, even if the EDITIDX resource is on. All
new messages will contain the new setting.
Both pages are linked to from the Page Layout section.
Note, I will admit that it is hard to find things in the docs. A lot
of useful information is buried in the resource pages.
understood this in the context that you have to pass EDITIDX when you change
a resource for archived messages (not affected by the current ADD).
When I read the code, it was obvious certain sections don't get rewritten
which I incorrectly thought was a bug.
When doing ADD, for efficiency sakes, if you change a resource, it
will only apply to new/edited pages. Older versions tried to be
smart by detecting changes and re-editing all pages. However, it
was getting to cumbersome (too many resources). The EDITIDX resource
exists to apply changes to all pages. It is expensive, so it is
best that the user has to explicitly request such an action.
As for "fixed" resources, the two that are fixed (excluding the
converted message header/body) is due to historical reasons. Older
versions did not properly delineate the main subject heading and
separator markup between converted message header and body. Therefore,
they are fixed. Newer version do have comment declarations that
now delineates them, but they have remained fixed since older messages
of an archive may have been created by older versions of MHonArc.
An alternative is to use $TSLICE$. This will probably serve you better
without the need to modify code.
As I understand TSLICE, it species a fixed number of messages to go backward
and forward within the whole thread list (@TListOrder). My patch changes
the meaning of BUTTON(TNEXT/PREV) to be active only if the next/prev message
is part of a particular thread. TSLICE is a view into all threads. My
Yes it is. But I fail to see how it is not useless in your case.
It effectively shows when a thread will end, and what is the next
thread. The reader would not have to jump back to the index to
goto the next thread.
patch defines a view into only one thread. Again, I'm not asking you to
change the meaning of TNEXT/PREV, just thought you'd like to know how someone
else viewed the meaning of these and perhaps it would be nice to have new
buttons defined with the alternate meaning.
More buttons! :-)
I played with the idea that you are mentioning quite awhile ago.
I figured it was more important to have TNEXT/PREV allow complete
traversal of an archive without have to go back to the index. They
function like trn's next command when in threaded mode. If I
hit 'n' and I am at the end of a thread, trn will take me to the
Note, what you desire is not needed if threading is done explicity,
i.e. people are defining the proper reference headers in replies.
Then, the follow-up/reference links on each message page provide what
you need. I have my limits on how much effort I will put in
subject-based thread support. It will never be perfect, and it would
not be necessary if people knew how to use their MUAs properly.
One last question: In the FAQ, it says you don't need to respecify the rcfil
when adding messages. However, under the section describing majordomo usage,
it specifies the -rc flag in the list alias. Is the alias example incorrect?
No. Respecify the rcfile does not hurt anything. However, it is
redundant since resources are stored in .mhonarc.db and take more
processing time. Respecifying may be useful if frequent changes are
made to the rcfile. I am considering a resource that tells MHonArc to
save resources in .mhonarc.db to save some space and time for those
that always specify a rcfile.
Earl Hood | University of California: Irvine
ehood(_at_)medusa(_dot_)acs(_dot_)uci(_dot_)edu | Electronic
http://www.oac.uci.edu/indiv/ehood/ | Dabbler of SGML/WWW/Perl/MIME