Hello again, and a good day Norman.

Sorry for answering so late, i have looked around a bit before
i do this.  (And was out, too.)

[email protected] (Norman Ramsey) wrote:
 |Thanks to the Debian maintainers, I've migrated to S-mailx from the

Thank you.

  I am sorry for this.  It is likely also a problem of mine, it
  cannot be misunderstood that i do not have the best sentiment of
  the developer of Heirloom mailx, even if confronted with all my
  own faults.  And i suppose that the Debian maintainer of
  nail/mailx is a friend or at least acquaintance of Gunnar
  Ritter, possibly they have studied together in Freiburg,
  Germany.  So for him it likely was not a small step to switch
  from Heirloom to S- at all!

  Debian is still at v14.8.16, but he (Hilko Bengen) has not
  updated any of his ports for a while, but nothing bad seems to
  have happened to him, i looked around and have seen that his
  github account has seen some actions.  And since he also makes
  his money with all that and has been active in Debian for
  i suspect way beyond a decade i presume he simply is on vacation
  and will sooner or later follow suit.

  v14.9. took two years and brought many, many fixes and i hope
  improvements.  Not really regarding this problem of yours,
  though.

 |old "Heirloom mailx."  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'.

  2BSD Mail had *askcc*.  *askcc* and *askbcc* are standardized.
  Looking at Unix V10 mail: it offered what i thought is best, but
  does not allow reentering compose mode, which i think should be
  possible.  I.e., in compose mode there is ~c and ~b and of
  course ~h and ~p, and in v14.9.x that can even be bound to
  a key, as in

    bind compose :kf1 ~e

  or one can set *editheaders* (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 */

  [1] https://lists.sdaoden.eu/pipermail/s-mailx/2015-May/000256.html

 |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?

Ok.  I will reenable the old behaviour for v14.9.4 and release not
later than 2017-09-02/3, all right?
I will also add the confirmation mentioned above and present in
V10 Unix mailx on top of that.

Thanks for letting me take part in your work flow.
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)

Reply via email to