Norman Ramsey <[email protected]> wrote:
|> 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.
A-ha. Well, this would be tremendous, as i personally really feel
a bit displaced in, at and with Debian. I have only used it once,
with Debian Woody (3.0 i think), coming from some years of RedHat,
and was then very happy once i have switched to FreeBSD. And now
they even use systemd. You know, Void, CRUX or Alpine Linux as
well as ArchLinux and KaOS, they all have a single simple text
file to maintain the package. Others only need a Makefile.
I feel much more comfortable in such an environment.
|>|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.
No no, i thought more about dumping the content of To:, Cc: and
Bcc:, maybe plus Subject:, followed by a "Send this message? "
confirmation. Unix V10 mailx has (in an optional branch)
puthead(hp, stdout, GTO|GCC|GBCC);
printf("Send? [yes] ");
if (fgets(ans, sizeof(ans), stdin) && ans[0] && tolower(ans[0]) != 'y')
goto dead;
which is a bit drastical; reentering compose mode as an option
would be nice.
|Having to confirm every send is not always a good plan: confirmation
|becomes a reflex action and so just lengthens the workflow.
Hm, well i always proof read the entire letter, it takes a long
time to write one. It will be a single keypress.
|> 2BSD Mail had *askcc*. *askcc* and *askbcc* are standardized.
|> Looking at Unix V10 mail: it offered what i thought is best,
|
|Which was?
As above.
|> 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.
It would be a different workflow. Instead of using the series of
three (four with subject) *ask** variables there will be the
To/Cc/Bcc overview with a single prompt Send/Discard/Recompose,
and in the latter case there is ~h or ~e (with *editheaders*) at
your fingertips.
| (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:
...
|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.
This has been committed to [master] and [stable/..] already as
[5cd0f50d] (Restore historical behaviour of *askb?cc* (Norman
Ramsey)).
|>|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.
It is there again.
|> 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.
Well i hope beta testing is not needed no more for v14.9. ;)
Ciao.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
