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, pgf@foxharp.boston.ma.us (arlington, ma, where it's 49.3 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers