Re: order of sending mail and saving to fcc

2019-06-10 Thread Nicolas Rachinsky
* "Kevin J. McCarthy"  [2019-06-04 09:44 -0700]:
> On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:
> > Does anybody know the reason of this change?
> 
> The most recent discussion on mutt-dev was
> .  The issue is
> contentious, and there are arguments on both sides.

Thank you for the reference.

> In this case, the comments by active developers seemed to be in consensus
> that prompting if Fcc fails afterwards is a reasonable compromise.

Ok, so I will replace $sendmail by something that saves the mail
first, since not having a local copy of a sent mail (for an easily
avoidable reason) is just not acceptable here. :(

have a nice day
Nicolas


Re: order of sending mail and saving to fcc

2019-06-10 Thread Nicolas Rachinsky
* Jack M  [2019-06-04 10:20 -0500]:
> On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > The other one (mail sent, but no local copy)
> 
> Why would this situation would ever occur?

A power failure at the wrong moment. A crash at the wrong moment. ...

These things tend to happen only at wrong moments.

HAND
Nicolas


Re: order of sending mail and saving to fcc

2019-06-10 Thread Nicolas Rachinsky
* Francesco Ariis  [2019-06-04 19:52 +0200]:
> Hello Grant,
> 
> On Tue, Jun 04, 2019 at 04:46:50PM -, Grant Edwards wrote:
> > On 2019-06-04, Jack M  wrote:
> > 
> > > The reason (or *a* reason) is that the old way led to the following
> > > situation: Fcc first, then try to send, something weird happens, but
> > > the user has no idea whether the mail was actually sent or not
> > 
> > How could the user not know? If the send fails, mutt prints an error
> > message and stays on the message compose screen.  It's pretty
> > obvious...
> 
> I have the bad habit of pressing 'q' (exit to menu) after sending.
> Also terminal corruption or similar events: you can't be sure whether
> the message was actually sent.

With the new order this behaviour might lead to a sent mail without
a local copy. If you miss the failure to send, you might as well
miss the failure to fcc.

HAND
Nicolas


Re: order of sending mail and saving to fcc

2019-06-10 Thread Felix Finch

On 20190604, Jack M wrote:

The other one (mail sent, but no local copy)


Why would this situation would ever occur?


As other(s) have mentioned, power failure, cat jumping on keyboard.  I have 
also had sends hang seemingly forever, and the only way forward is tokill the 
tmux session.  Then I have no Fcc copy.  I can root around /tmp to find the 
message, but I shouldn''t have to.

For me, the difference is that having extra Fcc copies is nowhere near as bad 
as not having any.

Another factor is that the Fcc is much less likely to fail than the send.

Perhaps a compromise is to Fcc as a draft file first, then send, then move the 
draft Fcc file to its permanent location.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o


Re: order of sending mail and saving to fcc

2019-06-10 Thread Felix Finch

On 20190610, Felix Finch wrote:

Perhaps a compromise is to Fcc as a draft file first, then send, then move the 
draft Fcc file to its permanent location.


Not so clever with IMAP draft files.  It would have to be a special local file, 
and mutt would have to look for it on start.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o


Re: order of sending mail and saving to fcc

2019-06-10 Thread Ben Boeckel
On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:
> As other(s) have mentioned, power failure, cat jumping on keyboard.  I
> have also had sends hang seemingly forever, and the only way forward
> is tokill the tmux session.  Then I have no Fcc copy.  I can root
> around /tmp to find the message, but I shouldn''t have to.

Doe mutt do the right fsync dance for power failure anyways? How would a
cat jumping on the keyboard possibly a failure mode *anyone* can *plan*
for? (I've had mine swat the power strip switch before which is at least
intersecting with other failure modes.)

Killing the tmux session seems overkill. You couldn't kill just the
pane holding mutt? Tmux being completely unresponsive sounds like either
a sendmail or tmux bug.

> For me, the difference is that having extra Fcc copies is nowhere near
> as bad as not having any.

If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!

--Ben


Re: order of sending mail and saving to fcc

2019-06-10 Thread Felix Finch

On 20190610, Ben Boeckel wrote:

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:

As other(s) have mentioned, power failure, cat jumping on keyboard.  I
have also had sends hang seemingly forever, and the only way forward
is tokill the tmux session.  Then I have no Fcc copy.  I can root
around /tmp to find the message, but I shouldn''t have to.


Doe mutt do the right fsync dance for power failure anyways? How would a
cat jumping on the keyboard possibly a failure mode *anyone* can *plan*
for? (I've had mine swat the power strip switch before which is at least
intersecting with other failure modes.)


Cat could hit 'q' and then you will have neither Fcc nor send copy.


Killing the tmux session seems overkill. You couldn't kill just the
pane holding mutt? Tmux being completely unresponsive sounds like either
a sendmail or tmux bug.


Of course this is what I meant.  And when ^C and ^\ do nothing, I consider it
time to kill the tmux session / pane.  I suppose I could open a new terminal
session, in tmux (because tmux is still responding), and killall mutt, but the
distinction is insignificant.


For me, the difference is that having extra Fcc copies is nowhere near
as bad as not having any.



If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!


If it is paranoid to consider the ramifications of a change, then the
implementors of said change were also paranoid.

Please be less snarky and more serious.  You do your arguments no favors.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o


When using mutt with mailto: From and Fcc are holding wrong values

2019-06-10 Thread Martin
Hello everyone,
I'm using mutt on Debian with several accounts and Firefox as a
browser. When I click on a mailto: link it opens a new terminal with
mutt and from all I see it does pick up my muttrc correctly, but the
new email has "Fcc:" as ~/sent and "From" as myuser
.

Same happens when I start it like:
mutt mailto:f...@bar.net?subject=foo

Also tried to pass one of my accounts with the -f flag.
I would expect mutt to select the first or any of my accounts to use
for the Sent-folder and From-Address.

Can you give me advice how to use one of my regular accounts for
composing emails via mailto links?

Mutt 1.10.1 (2018-07-13)
System: Linux 4.19.0-5-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Best regards,
Martin