Re: [Nmh-workers] mhshow display bug

[Paul Fox]

david wrote:
 > part       text/plain                1253
 > Paul F. wrote:
 > 
 > > david wrote:
 > >  > 
 > >  > Same for me.  Your profile entry, Paul, looks like it works
 > >  > properly for me.  I even inserted "tr '[a-z]' '[A-Z]'" in the
 > 
 > tr 'a-z' 'A-Z'
 > 
 > > do you have -concat set?  the breakage is happening for me in
 > > show_text, where buffer is set to either a display program ("%lless
 > > %F") or not ("%l") based on concatsw.  i'm in the latter case, so
 > > when i later get into parse_display_string, the "%l" is consumed, and
 > > then there's nothing left of buffer to plug into ct->c_termproc.
 > 
 > The %l just changes internal state, it doesn't contain anything
 > that gets displayed.  And I thought the problem was that the
 > %s from your mhshow-charset profile entry in was begin dropped,
 > botching the display string.

i probably confused things last night with my InitText() red herring.

the %s isn't getting dropped -- it's getting expanded to an empty
string.  i.e., at this point, at the end of parse_display_string():

        snprintf (buffer, buflen, ct->c_termproc, term);

the value of term is an empty string, and the value of ct->c_termproc
is this:

        %s | /usr/bin/iconv -f ISO-8859-1 -t UTF-8 | less

term is an empty string because the only thing in cp at the start of
parse_display_string() (cp is expanded to buffer, which is in turn
copied to term) is "%l".  the %l that gets consumed along the way, as
you say, creating no output.

continuing back, the reason cp contains just "%l" at the start of
parse_display_string() is this snippet, in show_text():
        if (concatsw)
            snprintf(buffer, sizeof(buffer), "%%l");
        else
            snprintf (buffer, sizeof(buffer), "%%l%s %%F", progsw ? progsw :
                      moreproc && *moreproc ? moreproc : DEFAULT_PAGER);

if the concatsw test weren't there, then cp would be "%lless %F", which
is the command that should eventually be expanded into the %s in my
configured display filter.

 > > having now given this all of 5 minutes of thought, i'd say that
 > > the conditional in show_text should go away.  whether concatsw
 > > is set or not, it should always be okay to run the user's charset
 > > converter.
 > 
 > I had been testing without setting -noconcat.  -concat is the
 > default.  I just tried with -noconcat and get exactly the same
 > behavior.

so if this is working for you, there's something else different
between our setups.

i have this in .mh_profile (and everything works if i get rid of it):
    mhshow-charset-iso-8859-1: %s | /usr/bin/iconv -f ISO-8859-1 -t UTF-8 | less
and the bug is reproducible if that and a "Path:" line, are the only
two lines in my .mh_profile.

the message i'm looking at has this content type:
    Content-Type: text/plain; charset="iso-8859-1"
simply changing "us-ascii" to "iso-8859-1" in your message (that i'm
replying to) reproduces the problem.

paul
----------------------
 paul fox, address@hidden (arlington, ma, where it's 49.3 degrees)