[news.software.b] Patch to do semi-truncation of the references line

brad@looking.on.ca (Brad Templeton) (11/20/89)

I urge you all to apply the patch posted here that gives a 2K (or larger)
buffer for the NEWSHEADER interpretation in rn.

Here is another patch to the code that does the %R expansion.  It is a kludge,
but it gets the job done.  If a references chain is too long, it deletes
elements off the end, leaving the immediate parent.  Deleted items are
replaced with a 'dummy' message ID of <nn@DEL.> where nn is a count of
deleted ids.  You can have more than one of these if you have to, but
this patch will combine 'em.

As far as I know, the <nn@DEL.> won't break anything currently out there,
although code that pruned such a tree could prune all such trees because
this will not be a unique ID.  If anybody knows of code that this would
break, let me know, and we will make  the @DEL.> ids unique in some way.

This kludge works by assuming that %R is at the end of the expansion.
That means you should update NEWSHEADER to put it at the end.

I use the following in config.h:
#   define NEWSHEADER "Newsgroups: %F\nSubject: Re: %S\nSummary: \nFollowup-To: \nDistribution: %D\nOrganization: %o\nKeywords: %[keywords]\nReferences: %R\n\n"

Note that if you increase the intrp buffer for followups to 2K, you may
never end up using this code, unless chains get very long.  Later I might
put together some code to do this a little fancier.  I decided it was
better to delete from the end rather than the front after the root, as
important nodes are more likely to be close to the root.  Of course that's
not always true.   Sigh.

Note that the dummy ID ends in a dot.  I figure no real site name ends in
dot, so this is a good syntax for special message-ids.


*** old/intrp.c
--- intrp.c
**************
*** 697,702
  			*scrbuf = '\0';
  		    if (!artid_buf)
  			artid_buf = fetchlines(art,MESSID_LINE);
  		    if (artid_buf[0] == '<')
  			safecat(scrbuf,artid_buf,sizeof(scrbuf));
  		    else {
--- 697,740 -----
  			*scrbuf = '\0';
  		    if (!artid_buf)
  			artid_buf = fetchlines(art,MESSID_LINE);
+ 		    /* Remove stuff from scrbuf to be sure the final id
+ 		       fits.  The number 20 is a safety buffer, including
+ 		       room for the 'DEL.' dummy entries, and only
+ 		       works if you change the NEWSHEADER environment
+ 		       variable to put the %R at or near the end of the
+ 		       followup header.  Use 150 if you don't change
+ 		       NEWSHEADER in your config.h.
+ 		       This is a KLUDGE */
+ 		    {
+ 		     int lsofar, artilen;	/* lengths of strings */
+ 		     char *backp;		/* back pointer in scrbuf */
+ 		     int delcount;		/* count deleted IDs */
+ 		     lsofar = strlen(scrbuf);
+ 		     artilen = strlen(artid_buf);
+ 
+ 		     delcount = 0;
+ 		     /* loop back to find room */
+ 		     while( destsize - lsofar - artilen < 20 &&
+ 					(backp = rindex( scrbuf, ' ' ))){
+ 			*backp = 0;
+ 			/* get count from other deletions! */
+ 			if( strncmp( backp+4, "@DEL.>", 6 ) == 0 )
+ 				delcount += atoi( backp+2 );
+ 			 else
+ 				delcount++;	/* count number deleted */
+ 			lsofar = backp-scrbuf;	/* adjust length */
+ 		     }
+ 		     /* if we never made it, use just the parent! */
+ 		     if( backp == (char *)0 && delcount > 0 ) {
+ 			*scrbuf = '\0';
+ 			delcount++;
+ 		     }
+ 		     if( delcount ) {
+ 		        char dcstring[16];	/* plenty of room for number */
+ 		     	sprintf(dcstring, "<%02d@DEL.>", delcount);
+ 		     	safecat(scrbuf,dcstring,sizeof(scrbuf));
+ 		     }
+ 		    }	/* end mini-scope for locals */
  		    if (artid_buf[0] == '<')
  			safecat(scrbuf,artid_buf,sizeof(scrbuf));
  		    else {
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

tneff@bfmny0.UU.NET (Tom Neff) (11/21/89)

I object to a patch being posted before a consensus is reached on
what the behavior ought to be.

-- 
"Nature loves a vacuum.  Digital    \O@/    Tom Neff
  doesn't." -- DEC sales letter     /@O\    tneff@bfmny0.UU.NET

brad@looking.on.ca (Brad Templeton) (11/21/89)

Well, I deliberately made that patch a simple inline insertion of code,
so it's easy to replace with something else.  In addition, I discovered
long ago that nothing on USENET ever gets solved through discussion.
It only gets solved by coding.  And I like to code, so I coded!

As I noted, the best solution is to put in the other patch that expands
the intrp buffer, so that you never need to delete IDs.

NTW, Tom, why is it that all your messages have blank Followup-to: lines
in them?  That screws up rn.  Is that deliberate, so nobody will
follow-up?
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473

jmm@eci386.uucp (John Macdonald) (11/23/89)

In article <14936@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
>I object to a patch being posted before a consensus is reached on
>what the behavior ought to be.

Unless a question is very simple, the easiest way to analyse a problem
is to try a few possible answers and then use the experience gained to
determine the *right* answer.  What is wrong in posting a patch that
allows people to try out a solution?  If it turns out to be wrong or
break things in a bad way, then the few people who try it will turn
it off.  If those who try it discover that it works well beyond their
wildest dreams, then it would suddenly hit the comp.sources.wanted as
"I didn't see it and now I want it, too".

Flaming somebody because they have given us free code is not an action
that I consider beneficial to the ongoing success of the net (although
it probably will not lead to the immanent demise...).
-- 
80386 - hardware demonstrating the fractal nature of warts.   | John Macdonald
EMS/LIM - software demonstrating the fractal nature of warts. |   jmm@eci386