Handling of ";" in To: with group nameing

[Florian Lohoff]

Hi,
RFC2822 defines a possibility to put group names in To/Cc etc ... Format
is described in RFC2828 Section 3.4 Addesss Specification

"
   When it is desirable to treat several mailboxes as a single unit
   (i.e., in a distribution list), the group construct can be used.  The
   group construct allows the sender to indicate a named group of
   recipients. This is done by giving a display name for the group,
   followed by a colon, followed by a comma separated list of any number
   of mailboxes (including zero and one), and ending with a semicolon.
   Because the list of mailboxes can be empty, using the group construct
   is also a simple way to communicate to recipients that the message
   was sent to one or more named sets of recipients, without actually
   providing the individual mailbox address for each of those
   recipients.
"

Request Tracker AKA RT uses this for communicating an empty group
which looks like this and a BCC + Reply-To::

To: undisclosed-recipients:;

Which is perfectly valid. The Problem is that when i press reply-group
i get the Reply-To: address in the To and the ";" in CC.

IMHO this is mishandling of addresses in mutt.

I am using 1.5.24

Flo
-- 
Florian Lohoff f...@zz.de
  We need to self-defend - GnuPG/PGP enable your email today!


signature.asc
Description: Digital signature

Re: Problem with key bindings

[Jeffery Small]

Vincent Lefevre  writes:

>> I wrote:
>> However, none of the bindings or macros that have a ";" in them are working
>> when mutt runs.

>I have no such problem. For instance, I have:

>bindindex,pager "\e[1;3A"   previous-unread

>so that I can type Meta-Up to trigger this function.

>> Outside of mutt, on the command line I can type ^V and the key and see that
>> it is definitely issuing the proper string.

>No, this does not guarantee to give the same string because Mutt
>runs in app mode, and escape sequences can be different in this mode.
>You can check with "tack". In "tack", type n f n then try your keys.

>For instance, on the commande line (or in cooked mode), the left arrow
>yields ^[[D, but in app mode (e.g. in tack), it yields ^[OD.

I installed tack(1).  When pressing the keypad keys I get (for example):

^[[20;2~(kf21)
^[[1;5P (kf25)

as well as the expected result for all other keys.  All of these keys with
';' in them work without problem in every other program I use, such as
vim(1) and my nn(1) news reader.

>> All key assignments without a ';' in them work fine and all that
>> include a ';' fail.

>You can try to type the individual keys like Esc [ 2 0 ; 2 ~ to
>see if these key assignments actually work. If they work, then this
>is because the special key does not give the sequence you expect.

I tried this for quite some time with different key combinations.  It
almost always fails with mutt reporting:  "Key is not bound.  Press '?' for
help."

However, every once in a while, these manually entered sequences DO work!
They might work two or three times in a row and then stop working again.  I
have tested over and over and I cannot find any sequence of actions that
will reproduce the condition where they start or stop working.  I have
never yet seen a case where the actual keypad key worked.

Remember that mutt is reporting that these sequences are properly defined
in its internal tables.

Does any of this shed additional light on what might be wrong.  I'm
perplexed by the fact that the manual entry very occasionally works.  This
seems very odd.

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

mutt-friendly vim settings?

[James]

All,

I know this borders being a vim question, but I was hoping for some
clarification on why my emails look strange on some clients.

As a software developer I use vim every day without issue; here are
the relevant settings that may be causing my heartache:

" autocomment, set formatoptions
"
" t = autowrap to textwidth
" c = autowrap to textwidth, add comment leader
" r = auto-comment after 
" o = auto-comment with 'o' or 'O'
" q = allow formating of comments with 'gq'
" l = don't format existing lines
" n = format numbered lists
" 2 = auto-indent based on second line of paragraph
" 1 = don't break lines after a one-letter word; break before
set formatoptions=tcroqln21
set textwidth=78

With this, my code generally wraps at textwidth.

I had not noticed until recently but when viewing my sent emails via
my iPhone mail app, my messages are appearing strangely formatted.
Here's an example:

-->8--

Hi Friend,

So the plan is to carpool on Sunday to Vegas, then on Wednesday back
to the 
office?

--8<--

I suspect the erroneous linebreak is because vim is force wrapping the text.

Is the answer to not wrap at all? It would be nice to see my emails
wrap _visually_, even if the message itself is _not_ wrapping under
the hood.

I don't see this wordwrap problem when viewing the emails in Outlook
or the Outlook Web App (yuck!).

Any thoughts on how to best configure vim for my use case?

Cheers!

Re: Status flag Old on new mails

[Tomas Nordin]

On Thu, Jan 14, 2016 at 03:15:32AM +0100, Simon Ruderich wrote:
> On Wed, Jan 13, 2016 at 11:14:27PM +0100, Tomas Nordin wrote:
> > Hi Mutters
> >
> > I have two accounts. On one of them the mails that are new to me (not
> > read) get the status flag N, as in New. On the other, new mails get the
> > status flag O, as in Old.
> >
> > This is slightly confusing to me. What am I doing wrong?
> 
> Did you disable the $mark_old option in one of the accounts?

No

> Regards
> Simon
> -- 
> + privacy is necessary
> + using gnupg http://gnupg.org
> + public key id: 0x92FEFDB7E44C32F9

Re: Problem with key bindings

[Jeffery Small]

The post below was supposed to go to the mutt-dev list but accidentally got
posted to mutt-users.  (Don't ask!)

Anyway, for those following along, with the help of Vincent Lefevre and
Ian Collier, the answer turned out to be that the troublesome keys were
actually defined in the xterm terminfo definition as function keys.  Once
the escape sequences in the .muttrc file were replaced with  through
, the keys were then recognized within mutt.  So the problem has been
solved.

Thanks to everyone who responded.  All the ideas were helpful in getting me
to a solution.

Regards,
--
Jeff


Jeffery Small  writes:

>Vincent Lefevre  writes:

>>> I wrote:
>>> However, none of the bindings or macros that have a ";" in them are working
>>> when mutt runs.

>>I have no such problem. For instance, I have:

>>bindindex,pager "\e[1;3A"   previous-unread

>>so that I can type Meta-Up to trigger this function.

>>> Outside of mutt, on the command line I can type ^V and the key and see that
>>> it is definitely issuing the proper string.

>>No, this does not guarantee to give the same string because Mutt
>>runs in app mode, and escape sequences can be different in this mode.
>>You can check with "tack". In "tack", type n f n then try your keys.

>>For instance, on the commande line (or in cooked mode), the left arrow
>>yields ^[[D, but in app mode (e.g. in tack), it yields ^[OD.

>I installed tack(1).  When pressing the keypad keys I get (for example):

>^[[20;2~(kf21)
>^[[1;5P (kf25)

>as well as the expected result for all other keys.  All of these keys with
>';' in them work without problem in every other program I use, such as
>vim(1) and my nn(1) news reader.

>>> All key assignments without a ';' in them work fine and all that
>>> include a ';' fail.

>>You can try to type the individual keys like Esc [ 2 0 ; 2 ~ to
>>see if these key assignments actually work. If they work, then this
>>is because the special key does not give the sequence you expect.

>I tried this for quite some time with different key combinations.  It
>almost always fails with mutt reporting:  "Key is not bound.  Press '?' for
>help."

>However, every once in a while, these manually entered sequences DO work!
>They might work two or three times in a row and then stop working again.  I
>have tested over and over and I cannot find any sequence of actions that
>will reproduce the condition where they start or stop working.  I have
>never yet seen a case where the actual keypad key worked.

>Remember that mutt is reporting that these sequences are properly defined
>in its internal tables.

>Does any of this shed additional light on what might be wrong.  I'm
>perplexed by the fact that the manual entry very occasionally works.  This
>seems very odd.

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

Re: mutt-friendly vim settings?

[Cameron Simpson]

On 14Jan2016 16:23, James  wrote:

I know this borders being a vim question, but I was hoping for some
clarification on why my emails look strange on some clients.


Sound llike you want format=flowed, of which there has been some recent 
discussion. This message is so formatted. Examine it on your iPhone etc.


The essence of this format is that (a) you fold text lines somewhere suitable 
for common fixed-width dumb paging of the text (i.e. <80 columns, typically 72 
or so) so that non-format-flowed readers are happy and (b) you mark all lines 
which are not the end of the paragraph as reflowable by leaving a trailing 
space on the end (flowed-aware readers can then reflow the paragraph to fit the 
display - mutt and the iPhone both do this).


I set mutt's $editor variable to my "vim-flowed" script, which invokes vim with 
useful settings, specificly "set formatoptions=waqj". See:


 https://bitbucket.org/cameron_simpson/css/src/tip/bin/vim-flowed

You may want to use this directly or to integrate these with your normal 
options for purposes of retaining your finger feel.



As a software developer I use vim every day without issue; here are
the relevant settings that may be causing my heartache:

" autocomment, set formatoptions
"
" t = autowrap to textwidth
" c = autowrap to textwidth, add comment leader
" r = auto-comment after 
" o = auto-comment with 'o' or 'O'
" q = allow formating of comments with 'gq'
" l = don't format existing lines
" n = format numbered lists
" 2 = auto-indent based on second line of paragraph
" 1 = don't break lines after a one-letter word; break before
set formatoptions=tcroqln21
set textwidth=78


Thanks for these - I'll read them and see if they can improve my crude vim 
environment.


Cheers,
Cameron Simpson 

Re: mutt-friendly vim settings?

[Cameron Simpson]

On 15Jan2016 09:20, Cameron Simpson  wrote:

On 14Jan2016 16:23, James  wrote:

I know this borders being a vim question, but I was hoping for some
clarification on why my emails look strange on some clients.


Sound llike you want format=flowed, of which there has been some 
recent discussion. This message is so formatted. Examine it on your 
iPhone etc.


Oh yes, in addition to my vim settings I use these mutt settings:

 set reflow_text=yes
 set reflow_wrap=-4
 set text_flowed=yes

Also have a read of RFC3676 which covers this:

 http://tools.ietf.org/rfcmarkup?doc=3676

Cheers,
Cameron Simpson 

The essence of this format is that (a) you fold text lines somewhere 
suitable for common fixed-width dumb paging of the text (i.e. <80 
columns, typically 72 or so) so that non-format-flowed readers are 
happy and (b) you mark all lines which are not the end of the 
paragraph as reflowable by leaving a trailing space on the end 
(flowed-aware readers can then reflow the paragraph to fit the display 
- mutt and the iPhone both do this).


I set mutt's $editor variable to my "vim-flowed" script, which invokes 
vim with useful settings, specificly "set formatoptions=waqj". See:


https://bitbucket.org/cameron_simpson/css/src/tip/bin/vim-flowed

You may want to use this directly or to integrate these with your 
normal options for purposes of retaining your finger feel.



As a software developer I use vim every day without issue; here are
the relevant settings that may be causing my heartache:

" autocomment, set formatoptions
"
" t = autowrap to textwidth
" c = autowrap to textwidth, add comment leader
" r = auto-comment after 
" o = auto-comment with 'o' or 'O'
" q = allow formating of comments with 'gq'
" l = don't format existing lines
" n = format numbered lists
" 2 = auto-indent based on second line of paragraph
" 1 = don't break lines after a one-letter word; break before
set formatoptions=tcroqln21
set textwidth=78


Thanks for these - I'll read them and see if they can improve my crude 
vim environment.


Cheers,
Cameron Simpson 


--

Re: Status flag Old on new mails

[Simon Ruderich]

On Thu, Jan 14, 2016 at 11:15:38PM +0100, Tomas Nordin wrote:
> On Thu, Jan 14, 2016 at 03:15:32AM +0100, Simon Ruderich wrote:
>> On Wed, Jan 13, 2016 at 11:14:27PM +0100, Tomas Nordin wrote:
>>> Hi Mutters
>>>
>>> I have two accounts. On one of them the mails that are new to me (not
>>> read) get the status flag N, as in New. On the other, new mails get the
>>> status flag O, as in Old.
>>>
>>> This is slightly confusing to me. What am I doing wrong?

Any other differences in the setup of those accounts?

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature