[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] show message number scrolls off terminal?

From: Paul Fox
Subject: Re: [Nmh-workers] show message number scrolls off terminal?
Date: Sun, 08 Feb 2015 08:32:13 -0500

ken wrote:
 > > > Contrary to it's name, "show"'s job isn't really to display a message;
 > > > it's to SELECT one or more messages for display.  Hence the reason
 > > > "next" and "prev" are really links to "show".  Once messages have been
 > > > selected, it's really supposed to be your showproc's job to display the
 > > > message, and the default showproc is mhl.  This suggests to me not that
 > > > we should switch show over to mhshow, but really make mhl MIME-aware.
 > > > Then show would get the relevant switches for things like MIME part
 > > > selection (which would end up being passed down to mhl) and mhshow would
 > > > go away.  Well, we'd keep a link around for it, but really, mhshow would
 > > > just become show.
 > >
 > >okay.  i'll have to think about that some.
 > As a corollary, I have no objections to people improving show/mhshow.  I'm
 > just trying to explain what I think the long-term vision should be.
 > You can see some of my thoughts on a "new MIME" architecture here:
 > http://lists.nongnu.org/archive/html/nmh-workers/2014-07/msg00058.html

thanks for that reminder link.

what missing (besides work estimates ;-) is mention of how all that
might affect the current UI, and the current list of MH facilities.
i'm sure you're hoping most of it can be done "under the covers", and
much of it can, but i we should also be thinking of the visible parts
(as with lyndon's lua explorations).

show's invocation of mhl is an example of this.  isn't the whole
notion of "showproc" vs.  "showmimeproc" a bit artificial these days? 
if there were an entry (similar to) this in mhn.defaults, then
couldn't a bunch of code in show.c just go away?
    mhshow-show-text/plain: mhl %F
(i haven't tried this, because i have on need for mhl on body parts, but
it seems like something like that should work.)

to make a change like that would affect a lot of documentation, and
might affect a lot of people's configs.  but it might also clean up
the overall architecture appreciably.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]