> 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
