> Debian is still at v14.8.16, but he (Hilko Bengen) has not > updated any of his ports for a while, ...
This sort of thing is a frequent problem with Debian. The latest upload was January 2017 which is not too bad. > v14.9. took two years and brought many, many fixes and i hope > improvements. I can ask for an update. Worst case, if we are able to resolve my issue, I can do a "non-maintainer upload" to a private Debian repo. > |I'm a little disconcerted to see that the > |meaning of askcc and askbcc has changed. In the old version, "ask" > |meant "always ask." In version 14.8.16, which I have now, "ask" means > |"ask only if empty." This default is not good for me, and I submit > |that it is not good for others. Consider the failure modes: > | > | - In the old behavior, I get an opportunity to edit a cc: list even > | if I don't want to edit it. No animals are harmed. > | > | - In the new behavior, I have no opportunity to edit a nonempty cc: > | list, and I send the mail with the wrong cc: list. I have already > | done this several times. > > I am sorry for the latter. I can offer no possibility to work > around this for v14.8.16! > > I think i have changed it because it only matters in interactive > compose mode, and then -- i think i have asked the ML for > feedback before doing that? Ah, no, i just have mentioned in an > otherwise cryptic message, oh dear, not worth looking at [1] -- > you have been interactive. > > I would not do it like that at all. I think the best would be, > in interactive mode, once compose mode is left, to always print > a summary of the envelope headers, maybe even with the subject, > and ask for send-confirmation. The same summary you have seen > (unless *editalong* is set) on compose mode entry when some kind > of `reply' is going on, not when you come in from the command > line or via `mail'. I'm having trouble understanding your scenario---partly because I don't have the vocabulary, for which I apologize. I guess I am imagining something along the lines of what happens when I do ~h, which I really want only when I ask for it, not on every send. Having to confirm every send is not always a good plan: confirmation becomes a reflex action and so just lengthens the workflow. > 2BSD Mail had *askcc*. *askcc* and *askbcc* are standardized. > Looking at Unix V10 mail: it offered what i thought is best, Which was? > but does not allow reentering compose mode, which i think should > be possible. I love the idea of being able to reenter compose mode while in the middle of responding to *askcc* or *askbcc*. But I think this idea is orthogonal to my issue. > or one can set *editheaders* *editheaders* is extremely civilized and is an excellent default. But again, I think it and *editalong* are orthogonal to my issue. (now a /etc/s-nail.rc default) and > *editalong* or F1 and it is all there right away, then confirm > again before sending. But, on the other hand, in the other window > i just have read in V10 mailx's collect.c: > > if (hp->h_subject == NOSTR && value("asksub")) > c |= GSUBJECT; > /* adb: due to popular demand, these were moved to the end of the letter > * adb: if (hp->h_cc == NOSTR && value("askcc")) > * adb: c |= GCC; > * adb: if (hp->h_bcc == NOSTR && value("askbcc")) > * adb: c |= GBCC; > * adb */ Here's what I'm seeing from Heirloom mailx, sendout.c line 981: if (value("interactive") != NULL) { if (((value("bsdcompat") || value("askatend")) && (value("askcc") != NULL || value("askbcc") != NULL)) || value("askattach") != NULL || value("asksign") != NULL) { if (value("askcc") != NULL) grabh(hp, GCC, 1); if (value("askbcc") != NULL) grabh(hp, GBCC, 1); if (value("askattach") != NULL) hp->h_attach = edit_attachments(hp->h_attach); if (value("asksign") != NULL) dosign = yorn("Sign this message (y/n)? "); } else { printf(catgets(catd, CATSET, 183, "EOT\n")); fflush(stdout); } } You'll see that when *askatend* and *askcc* are set, it asks for Cc: regardless of the current value of hp->h_cc. This is the behavior I am hoping for. > |I would like Steffen to consider whether reversion to the old behavior > |might be a good idea. If not, I am going to beg for an option that > |means "really, really ask, even if the list is nonempty." > > You mean if during development of the discussion it becomes useful > or interesting to extend the list of participants, and ~h or ~p > need activity and disturb the precious flow of thoughts and are > later easily forgotten, which once was catched by the barrier(s) > that *askb?cc* represented? I agree that ~h definitely disturbs the flow of thoughts; I use it rarely. The workflow I have in mind is a little different, which is after the message is fully composed, to be forced to consider whether recipients ought to be added to the cc: list. Or even more important, *removed* from the cc: list. I want to be forced to consider this question (and only this question) on every send. > Ok. I will reenable the old behaviour for v14.9.4 and release not > later than 2017-09-02/3, all right? Sounds great! At that time I will be insanely busy (school about to start), but assuming I can get a Debian package built, I will try to beta test it for you. Norman