Re: lynx-dev Patch for mailcap viewer order

[Klaus Weide]

On Fri, 15 Jan 1999 address@hidden wrote:
> In a recent note, Klaus Weide said:
> > 
> > * Lynx was using the wrong precedence for entries within a mailcap
> >   (relative to other entries from the same file): RFC 1524 says
> 
> Thanks.  I've whined about this on this list a couple times;
> merely because it was inconsistent with metamail -- I didn't
> know it contravened a RFC.
> 
> >   Maybe it should be made configurable whether Lynx's traditional
> >   precedence or the new one is used; currently there is just a #define
> >   in HTInit.c which could be changed to revert to traditional behavior.
> > 
> I'd vote "no".  It's merely instituting a perpetual enticement to
> users to create mailcap files which may work with Lynx, but will
> fail with other MIME lients.

I thought there might be institutions with carefully crafted mailcap
fails relying on the old behavior.  Well we'll see if anyone complains.

> >   PRIVATE int HTLoadTypesConfigFile ARGS1(
> >     char *,         fn)
> >   {
> > !     int result = 0;
> > !     HTList * saved = HTPresentations;
> > ! 
> > !     if (reverse_mailcap) {                /* temporarily hide existing 
> > list */
> > !   HTPresentations = NULL;
> > !     }
> > ! 
> > !     result = ProcessMailcapFile(fn);
> > ! 
> > !     if (reverse_mailcap) {
> > !   if (result && HTPresentations) {
> > !       HTList_reverse(HTPresentations);
> > !       HTList_appendList(HTPresentations, saved);
> > !       FREE(saved);
> > !   } else {
> > !       HTPresentations = saved;
> > !   }
> > !     }
> > !     return result;
> >   }
> >   
> But bear with my reviewer's comments:

Reviews always welcome :)

> I'd urge that the utilities HTList_reverse and HTList_appendList
> be made tolerant of empty lists, so the caller may be freed of the
> burden of treating them as special cases.  If this is done, the
> code above simplifies to the more intuitive:
> 
> >   PRIVATE int HTLoadTypesConfigFile ARGS1(
> >     char *,         fn)
> >   {
> > !     int result = 0;
> > !     HTList * saved = HTPresentations;
> > ! 
> > !   HTPresentations = NULL;         /* temporarily hide existing list */
> > ! 
> > !     result = ProcessMailcapFile(fn);
> > ! 
> > !     if (reverse_mailcap) 
> > !       HTList_reverse(HTPresentations);
> > !   
> > !     HTList_appendList(HTPresentations, saved);
> > !   FREE(saved);
> > !     return result;
> >   }

That should already be possible, if you make one change: replace

   HTPresentations = NULL;

with

   HTPresentations = HTList_new();

to make sure there always is a list to append to.
The thing with HTLists is that an empty one is different from a NULL
list.  It's already the case with the existing HTList functions that
the caller has to create a new list before he can add something to
it, so I don't see a point in making the new functions more general than
that.

My code has the (very small) advantage to not modify the list structures
at all if not necessary, so on balance I don't see enough incentive to
change it; but feel free to submit a patch so that Tom may include it.


    Klaus