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).
Well ... good question.
Let's take, for example, the selection module. For a refresh for people
have forgotten, this is the "module" that decides what MIME parts are going
to be display/stored/whatever.
How will this work from a UI perspective? In the specific case of 'show'
(let's go on the assumption that 'mhshow' is going away), mhl is really
doing the hard work. So mhl will feed some default options to to selection
module; to replicate what is there now, it will probably assume a default
of text, inline parts only. Options like -part and -type will override that
default. Also, options to override the default preferences for multipart/
alternative would go here (forgive me, I've been busy and haven't had a
chance to digest recent discussion here). I have no idea what the internal
API would look like, but I don't think that matters now.
So in terms of UI, that would remain the same. But that opens up some
additional options. For example, we could allow a shell script or other
external program to be invoked by the selection module. It could make
decisions if a part should be displayed. Or even better, a Lua script
could be run to make that decision (I pray that we do NOT have a mh-format
script run here).
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
No ... I think that's the wrong level. mhl deals with one or more FILES
that are complete messages; not MIME parts. Looking at the original MH
design, it is clear to me that really show (and by extension, mhshow)
should not be parsing the message at all. So yeah, a bunch of code in
show.c goes away (and mhshow goes in the trash can). But mhl.c gets
more complicated. Well, a fair amount of complexity will move into
the nmh library. And I'm assuming we can get rid of things like bell
support.
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.
Yeah, that's what I'm hoping; unfortunately, user configuration is
going to change a lot. We can probably bridge some of it with some
compatibility options, and we might need to provide some kind of tool
to help people migrate. And I would like to stress that this is all
preliminary; I am completely open to design changes. Feedback is
welcome and appreciated here.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers