Re: [PATCH] Add $socket_timeout configuration option.

[egbert.]

On Wed, Aug 19, 2015 at 06:30:51PM -0700, Kevin J. McCarthy wrote:
> Hi Allen!
> 
> Thanks for your favorable feedback on the new patch.  Have you had a
> chance to test it for a while?

I’ve been testing it for about a day now :) But I will now be using it daily 
and I’ll let you know if anything goes haywire.

> […]

> > * It’s good that you expanded this to include write sockets as well. But I 
> > really think that the write timeout and the read timeout should be separate 
> > config vars. For me, for example, I will have the read timeout set to 
> > something low (5 or 10 seconds). But if I’m sending an email with a large 
> > attachment, or on a slow connection, I want it to be something like 1 
> > minute 
> > or even 2.
> 
> The timeout isn't for the entire upload/download, it's for each
> individual read/write operation.  At least in smtp.c mutt is generally
> using buffer sizes of 1K.  Additionally, in gnutls (from what I remember
> poking in the code), a partial read/write will return the data and won't
> set an error.  So you would only have to be concerned if no data at all
> was received or sent during the timeout interval.
> 
> Based on that behavior, I don't think exposing settings for each would
> be helpful.  (And mutt already has plenty of settings...)

I do still think there should be two values – but after giving it some 
thought I have a different suggestion than what I wrote above.

I know mutt has a lot of settings but whoever doesn’t want to set them will 
of course be provided with a default. And mutt is after all for tweakers 
isn’t it?

(And I do realise it’s not about the time it takes to send/receive an entire 
email, just the small bits of data which are passed about in the sockets).

Most people don’t realise (and I didn’t until I looked at it closely) that 
when mutt is idling, it is actually communicating pretty intensively. (With 
IMAP, in any case). So we can have one config var for ‘socket timeout on 
idle’. This is to solve the hanging mutt problem which people (like me) are 
complaining about when you pack up your laptop and go somewhere else. And, 
it can be the same value for read and write.

The default of 30 secs is ok. Tweakers will want to decrease this number (I 
have it set to 10 secs, which works great for me).

Then, when you are sending or receiving mail, the timeout should be set to a 
second, larger value. Something like ‘socket timeout on data’.

This is so that when you’re on a shaky connection, downloading a large email 
or sending one, and praying for that attachment to get through, it will be 
really frustrating if it keeps giving up after 10 or even 30 seconds.

Thoughts?

Grts. Allen

mutt: Updated Russian translation.

[Brendan Cully]

changeset: 6484:b3c095648df6
user:  Vsevolod Volkov 
date:  Thu Aug 20 11:18:05 2015 -0700
link:  http://dev.mutt.org/hg/mutt/rev/b3c095648df6

Updated Russian translation.

diffs (truncated from 3055 to 950 lines):

diff -r 83760f05bb46 -r b3c095648df6 po/ru.po
--- a/po/ru.po  Wed Aug 19 09:41:49 2015 -0700
+++ b/po/ru.po  Thu Aug 20 11:18:05 2015 -0700
@@ -10,10 +10,10 @@
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: mutt-1.5.23\n"
+"Project-Id-Version: mutt-1.5.24\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2014-03-12 09:18-0700\n"
-"PO-Revision-Date: 2014-03-13 13:06+0200\n"
+"POT-Creation-Date: 2015-08-20 19:46+0300\n"
+"PO-Revision-Date: 2014-08-20 20:06+0300\n"
 "Last-Translator: mutt...@woe.spb.ru\n"
 "Language-Team: mutt...@woe.spb.ru\n"
 "Language: ru\n"
@@ -36,11 +36,11 @@
 msgid "Exit"
 msgstr "Выход"
 
-#: addrbook.c:38 curs_main.c:406 pager.c:1538 postpone.c:42
+#: addrbook.c:38 curs_main.c:483 pager.c:1538 postpone.c:42
 msgid "Del"
 msgstr "Удалить"
 
-#: addrbook.c:39 curs_main.c:407 postpone.c:43
+#: addrbook.c:39 curs_main.c:484 postpone.c:43
 msgid "Undel"
 msgstr "Восстановить"
 
@@ -49,8 +49,8 @@
 msgstr "Выбрать"
 
 #. __STRCAT_CHECKED__
-#: addrbook.c:41 browser.c:49 compose.c:96 crypt-gpgme.c:3866 curs_main.c:412
-#: mutt_ssl.c:1034 mutt_ssl_gnutls.c:904 pager.c:1630 pgpkey.c:522
+#: addrbook.c:41 browser.c:49 compose.c:96 crypt-gpgme.c:3989 curs_main.c:489
+#: mutt_ssl.c:1045 mutt_ssl_gnutls.c:1003 pager.c:1630 pgpkey.c:522
 #: postpone.c:44 query.c:53 recvattach.c:57 smime.c:425
 msgid "Help"
 msgstr "Помощь"
@@ -121,8 +121,8 @@
 msgid "Mailcap compose entry requires %%s"
 msgstr "Указанный в mailcap способ создания требует наличия параметра %%s"
 
-#: attach.c:134 attach.c:266 commands.c:223 compose.c:1175 curs_lib.c:180
-#: curs_lib.c:551
+#: attach.c:134 attach.c:266 commands.c:223 compose.c:1195 curs_lib.c:182
+#: curs_lib.c:555
 #, c-format
 msgid "Error running \"%s\"!"
 msgstr "Ошибка выполнения \"%s\"!"
@@ -188,8 +188,8 @@
 msgid "---Attachment: %s"
 msgstr "---Вложение: %s"
 
-#: attach.c:631 attach.c:663 attach.c:958 attach.c:1016 handler.c:1360
-#: pgpkey.c:570 pgpkey.c:759
+#: attach.c:631 attach.c:663 attach.c:958 attach.c:1016 handler.c:1362
+#: pgpkey.c:571 pgpkey.c:760
 msgid "Can't create filter"
 msgstr "Не удалось создать фильтр"
 
@@ -303,61 +303,61 @@
 msgid "Error trying to view file"
 msgstr "Ошибка при попытке просмотра файла"
 
-#: buffy.c:487
+#: buffy.c:504
 msgid "New mail in "
 msgstr "Новая почта в "
 
-#: color.c:326
+#: color.c:327
 #, c-format
 msgid "%s: color not supported by term"
 msgstr "%s: цвет не поддерживается терминалом"
 
-#: color.c:332
+#: color.c:333
 #, c-format
 msgid "%s: no such color"
 msgstr "%s: нет такого цвета"
 
-#: color.c:378 color.c:584 color.c:595
+#: color.c:379 color.c:585 color.c:596
 #, c-format
 msgid "%s: no such object"
 msgstr "%s: нет такого объекта"
 
-#: color.c:391
+#: color.c:392
 #, c-format
 msgid "%s: command valid only for index, body, header objects"
 msgstr "%s: команда доступна только для индекса, заголовка и тела письма"
 
-#: color.c:399
+#: color.c:400
 #, c-format
 msgid "%s: too few arguments"
 msgstr "%s: слишком мало аргументов"
 
-#: color.c:572
+#: color.c:573
 msgid "Missing arguments."
 msgstr "Необходимые аргументы отсутствуют."
 
-#: color.c:611 color.c:622
+#: color.c:612 color.c:623
 msgid "color: too few arguments"
 msgstr "color: слишком мало аргументов"
 
-#: color.c:645
+#: color.c:646
 msgid "mono: too few arguments"
 msgstr "mono: слишком мало аргументов"
 
-#: color.c:665
+#: color.c:666
 #, c-format
 msgid "%s: no such attribute"
 msgstr "%s: нет такого атрибута"
 
-#: color.c:705 hook.c:69 hook.c:77 keymap.c:906
+#: color.c:706 hook.c:69 hook.c:77 keymap.c:908
 msgid "too few arguments"
 msgstr "слишком мало аргументов"
 
-#: color.c:714 hook.c:83
+#: color.c:715 hook.c:83
 msgid "too many arguments"
 msgstr "слишком много аргументов"
 
-#: color.c:730
+#: color.c:731
 msgid "default colors not supported"
 msgstr "цвета по умолчанию не поддерживаются"
 
@@ -587,7 +587,7 @@
 msgid "Abort"
 msgstr "Прервать"
 
-#: compose.c:94 compose.c:660
+#: compose.c:94 compose.c:680
 msgid "Attach file"
 msgstr "Вложить файл"
 
@@ -627,266 +627,274 @@
 msgid " (S/MIME)"
 msgstr " (S/MIME)"
 
-#: compose.c:150 compose.c:154
+#: compose.c:145
+msgid " (OppEnc mode)"
+msgstr " (режим OppEnc)"
+
+#: compose.c:153 compose.c:157
 msgid " sign as: "
 msgstr "подпись как: "
 
-#: compose.c:150 compose.c:154
+#: compose.c:153 compose.c:157
 msgid ""
 msgstr "<по умолчанию>"
 
-#: compose.c:162
+#: compose.c:165
 msgid "Encrypt with: "
 msgstr "Зашифровать: "
 
-#: compose.c:215
+#: compose.c:218
 #, c-format
 msgid "%s [#%d] no longer exists!"
 msgstr "%s [#%d] уже не существует!"
 
-#: compose.c:223
+#: compose.c:226
 #, c-format
 msgid "%s [#%d] modified. Update encoding?"
 msgstr "%s [#%d] изменен.  Обновить кодировку?"
 
-#: compose.c:266
+#: compose.c:269
 msgid "-- Attachme

Re: [PATCH] Add $socket_timeout configuration option.

[Kevin J. McCarthy]

egbert. wrote:
> So we can have one config var for ‘socket timeout on idle’. This
> is to solve the hanging mutt problem which people (like me) are
> complaining about when you pack up your laptop and go somewhere
> else. And, it can be the same value for read and write.

> Then, when you are sending or receiving mail, the timeout should be set to a 
> second, larger value. Something like ‘socket timeout on data’.

I'd suggest we try to get this current simple solution in first, and see
what happens.  It may be that you're right and a one-config-option
solution doesn't work well, but I'd like to see what kind of feedback we
get across all mutt-users.

(That's just me though, maybe one of the other developers has feedback.)

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt


signature.asc
Description: PGP signature

Re: [PATCH] Add $socket_timeout configuration option.

[egbert.]

On Thu, Aug 20, 2015 at 11:29:32AM -0700, Kevin J. McCarthy wrote:
> egbert. wrote:
> > So we can have one config var for ‘socket timeout on idle’. This
> > is to solve the hanging mutt problem which people (like me) are
> > complaining about when you pack up your laptop and go somewhere
> > else. And, it can be the same value for read and write.
> 
> > Then, when you are sending or receiving mail, the timeout should be set to 
> > a 
> > second, larger value. Something like ‘socket timeout on data’.
> 
> I'd suggest we try to get this current simple solution in first, and see
> what happens.  It may be that you're right and a one-config-option
> solution doesn't work well, but I'd like to see what kind of feedback we
> get across all mutt-users.

Ok. For myself, I can keep two muttrc’s around. Or, do :set socket_timeout = 
 from within mutt when I want to adjust it – only I’ll have to 
try and figure out a way to make it rerun the init code.

Grts. Allen

Re: Add $socket_timeout configuration option.

[arnt]

I implemented something similar for another client and disagree 
viciously ;) The proper timeout depends in the network, and asking the 
user is a cop-out.


I am currently on vacation at a farm in Italy, very 
nice and not just because of the free wlan, but the configuration of 
the network here is not a user matter. You do not want to reconfigure 
mutt to go on vacation. (Or perhaps you do, but let us pretend you 
don't.)


A much better approach is to count seconds of connection 
idleness, and after a few tens of seconds to mark the connection as 
unreliable. When using an unreliable connection, the first command must 
be a noop with a strict timeout.


Arnt

Re: Overlong lines

[Vincent Lefevre]

[Moved to mutt-dev]

On 2015-08-19 09:49:15 -0700, Kevin J. McCarthy wrote:
> Petr Pisar wrote:
> > While translating the messages I noticed some messages exceed 80 columns. 
> > For
> > example:
> > 
> > #: smime.c:2064
> > msgid ""
> > "S/MIME (e)ncrypt, (s)ign, encrypt (w)ith, sign (a)s, (b)oth, (c)lear, or 
> > (o)ppenc mode? "
> 
> Ah.  Yes, that's my fault with the oppenc patch.
> 
> > What will happen if a terminal has 80 columns? Will the query message be
> > truncated, wrapped? What if a redraw is requested with ^L. Or does mutt
> > require some minimal terminal size?
> 
> I believe the message will be truncated.  Fortunately this particular
> message doesn't occur by default (they have to toggle off oppenc mode
> first).
> 
> > I tried to shorten all my translations to fit into 80 colums, so I'm curious
> > if somebody is concerned? If mutt is going to deal with it, I'd like to see
> > expanding the status line into more lines in some automatic fashion. That
> > would allow me to avoid abbreviations that make the message uggly and more
> > difficult to understand.
> 
> I'll put that on my todo list to look into.  Thank you for bringing this
> up.  For now, just do the best you can to keep it under 80, but I would
> say now-a-days if we go a few characters over it is still okay. :-)

Even if we have larger screens (which tends actually to be the
opposite with smartphones), this doesn't mean that the terminals
will be wider. I prefer to keep 80-column terminals but having
more windows visible at the same time. I sometimes enlarge some
terminals, but I dislike being forced to do that.

But as I said 11 years ago[*]:

I think that a 1-line menu is a bad idea (this is even worse in
French). Also, one should also take into account that terminals
can have fewer than 80 columns (e.g. that could be PDAs).

BTW, the sort menu should also be reconsidered IMHO, though there
are no security issues there.

[*] http://marc.info/?l=mutt-dev&m=109178946210060

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Preparing for a new release

[Vincent Lefevre]

On 2015-08-20 07:49:11 +0200, Christian Brabandt wrote:
> Am 2015-08-19 23:34, schrieb Kevin J. McCarthy:
> >>2) I don't know for how long we have been running mutt with the trash
> >>folder patch. It looks quite clean to me. So would you consider
> >>integrating this patch upstream?

FYI, I had been using it between 2005-02 and 2006-10 on my IMAP
mailbox, without any problem. I stopped using it just because
this was also saving spam to the trash folder. But I have still
the patch applied (just with "unset trash"), and this doesn't
cause any problem.

> >I haven't ever taken a look at that patch, so I'd have to look at it
> >more closely.  I haven't had any problem just using:
> >  folder-hook . 'macro index,pager d "=INBOX.Trash"'
> >  folder-hook =INBOX\.Trash 'macro index,pager d '
> >  folder-hook '=INBOX\.Junk Mail' 'macro index,pager d '
> >
> >The wiki used to say that didn't work with tagged messages, but that's no
> >longer true.  Also, it keeps me from moving spam to my trash when
> >deleted.
> 
> I have been using that approach for long enough, that I know it can cause
> several annoyances. First, while I appreciate the flexibility of
> folder-hooks
> (and use them myself for several different purposes), I don't think it
> is reasonable, to have every user invent their own, to make use of a trash
> folder.
> 
> Second, you would probably have to add some 
>  tags, to make this work properly with tagged messages. This adds
> to
> the burden that every user has to invent their own solution.
> 
> Third, if you press 'd' on a message, later undelete the message
> and even later delete the message one more time, you will end up with
> many copies of the same message in your trash folder
> 
> Fourth, does not work with  and similar functions.

I agree with everything.

> Fifth, http://cedricduval.free.fr/mutt/patches/#trash also mentions
>The folder history doesn't clutter up with unwanted trash entries.
> 
> (I am not sure, what is meant with this one)

In "=INBOX.Trash", the "=INBOX.Trash" will be
saved to the history, and it is not possible to temporarily disable
the history (e.g. for such macros). So, indeed, this would be very
annoying.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Preparing for a new release

[Vincent Lefevre]

On 2015-08-21 01:33:10 +0200, Vincent Lefevre wrote:
> On 2015-08-20 07:49:11 +0200, Christian Brabandt wrote:
> > Fifth, http://cedricduval.free.fr/mutt/patches/#trash also mentions
> >The folder history doesn't clutter up with unwanted trash entries.
> > 
> > (I am not sure, what is meant with this one)
> 
> In "=INBOX.Trash", the "=INBOX.Trash" will be
> saved to the history, and it is not possible to temporarily disable
> the history (e.g. for such macros). So, indeed, this would be very
> annoying.

In a similar way, I have:

macro   index   \CA "~A\r" "limit to all"

and each time I use this macro, ~A is written to the history.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Preparing for a new release

[Kevin J. McCarthy]

Vincent Lefevre wrote:
> > Fifth, http://cedricduval.free.fr/mutt/patches/#trash also mentions
> >The folder history doesn't clutter up with unwanted trash entries.
> > 
> > (I am not sure, what is meant with this one)
> 
> In "=INBOX.Trash", the "=INBOX.Trash" will be
> saved to the history, and it is not possible to temporarily disable
> the history (e.g. for such macros). So, indeed, this would be very
> annoying.

I believe adding a leading space will keep it from being added to
history:
 " =INBOX.Trash"

However, I hear all the points made, so will give the patch a serious
look.  Do you know if there is any particular reason it hasn't been
committed before?

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA
http://www.8t8.us/configs/gpg-key-transition-statement.txt


signature.asc
Description: PGP signature

Re: Preparing for a new release

[Will Yardley]

On Fri, Aug 21, 2015 at 01:33:10AM +0200, Vincent Lefevre wrote:
> On 2015-08-20 07:49:11 +0200, Christian Brabandt wrote:
> > Am 2015-08-19 23:34, schrieb Kevin J. McCarthy:
> > >>2) I don't know for how long we have been running mutt with the trash
> > >>folder patch. It looks quite clean to me. So would you consider
> > >>integrating this patch upstream?
> 
> FYI, I had been using it between 2005-02 and 2006-10 on my IMAP
> mailbox, without any problem. I stopped using it just because
> this was also saving spam to the trash folder. But I have still
> the patch applied (just with "unset trash"), and this doesn't
> cause any problem.

I've been using some variant of a trash folder patch (the Cedric Duval
one) since before 2003 continuously.

I much prefer it to the macro approach for various reasons mentioned,
and it's a feature I think a lot of people expect these days.

w