>I don't understand that, I've used multiple identities, without any >particular difficulties, for a long time now (> 20 years), and MH (and >later nmh) just works as it is. That is, to say, in this area I see >no need for any changes, and consequently no need for any code to be >developed.
Well, there are really two different things here that are sort of conflated. Let me seperate them out: - Code simplification. That's what removing support for turning off draft_from is about (I have to touch that code anyway, and making it simpler would help me out). The options for controlling draft_from just make the code hairier, and I'm not even sure it makes any sense given the changes coming. So far no one has made any reasonable argument why this code should stay; I'm open to hearing some reasons, so if you want to keep this selectable it's time to speak up. - Reasonable defaults. The discussion that has been hashed out over the last month on this has resulted in the following consensus view: - All drafts have to have a From: line in them; if they don't, post will reject them. - The default components files will have From: lines in them. - There will be a configurable hierarchy as to where the default From: information will come from (see the mailing list archives). This here is the part that is requiring the majority of new code. In my view, this part has been settled; if people had objections to this, they should have made them back when this was under discussion. As you point out, nmh has let you use multiple identities for a long time now. This isn't so much about that part (although, see below), but more about being able to do it in a more logical way. But ... based on what you're saying, nothing I'm proposing is going to change how you use nmh. Well, except that post probably isn't going to generate a Sender: header anymore (not sure about this part ... I was going to wait until I get in there to figure that out). But assuming you have draft_from turned on, you probably haven't been generating a Sender header anyway. >From what I can figure out, the thing people most want to add is some >magic to have nmh choose which identity it should use, rather than needing to >be told. Personally, that is exactly what I don't want - automation >like this gets addictive, and we start to assume it always works >correctly, and so don't bother to verify it every time - but in this >area, it is almost impossible to be perfect, that way can lead to >embarrassing mistakes. I respect your opinion, but as someone who's replcomps now selects the "right" email address to use in From: headers ... man, I can't go back now (I'm lucky in that the heuristic I use is relatively simple). And I'm not the only one who would make use of this feature. But of course you are still free to use nmh in the way you use it now. >And I absolutely understand that, and for whatever my opinion as to how >you should allocate that limited time is worth, and I understand that is >not much, I'd prefer you use it in the areas where it is clear that MH >does need work, of which the most obvious is MIME handling (particularly >for replies, the rest of it might be clunky, but kind of works). As we've discussed ... fixing THAT problem is not easy. It's being worked on (slowly), but it's going to be tough. >useless to me, and should be just as useless to any true MH user. (nb: >this is not to denigrate IMAP. For people whose needs it serves, it is >just fine, it is just that those needs, and MH's requirements, aren't >compatible.) Well, people have made what I consider reasonable arguments in terms of use cases for IMAP support in nmh. Of course when nmh has IMAP support (I'm an optimist!) it shouldn't affect you in any way. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers