>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
