gmane.mail.mh-e.devel

[ mh-e-Bugs-3525175 ] Cannot forward message with double-line From

SourceForge.net — 2012-05-09T17:01:47

Bugs item #3525175, was opened at 2012-05-09 10:01
Message generated for change (Settings changed) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=3525175&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: mh-e-8.3
Status: Open
Priority: 7
Private: No
Submitted By: Bill Wohler (wohler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot forward message with double-line From

Initial Comment:
1. Place the attached message in inbox.

2. Use `f' `(mh-forward)'.

3. Observe that ": Test subject" appears at the end of the header rather than at the end of the Subject header field.

4. Even if you move ": Test subject" to the end of the Subject header field, you get the following error when you send the message:

post: no addressees
send: message not delivered to anyone

That's because the following is i

[ mh-e-Bugs-3525175 ] Cannot forward message with double-line From

SourceForge.net — 2012-05-09T17:01:25

Bugs item #3525175, was opened at 2012-05-09 10:01
Message generated for change (Tracker Item Submitted) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=3525175&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: mh-e-8.3
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Bill Wohler (wohler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot forward message with double-line From

Initial Comment:
1. Place the attached message in inbox.

2. Use `f' `(mh-forward)'.

3. Observe that ": Test subject" appears at the end of the header rather than at the end of the Subject header field.

4. Even if you move ": Test subject" to the end of the Subject header field, you get the following error when you send the message:

post: no addressees
send: message not delivered to anyone

That's bec

Re: Intermediate review for SF #1708292

Jeffrey Honig — 2012-02-22T04:30:41


Syntax tables are used by regexp call.  So yes, we would need to wrap
the re-search-forward call (and only that call).  It is necessary to
use (set-syntax-table) to change the table and (syntax-table) to get the
current one.  So the re-search-forward would need an (unwind-protect
(save-excursion)) wrapper.


After sleeping on it, I think that is best.  We can also provide a
global variable that can be set with a let as a hint.

Thanks!

Jeff

Re: Intermediate review for SF #1708292

Bill Wohler — 2012-02-22T03:37:01


Remind me how syntax tables are used programmatically. What call
specifically is the one that needs it? Is it the re-search-forward call
in mh-regexp-in-field-p? Passing a syntax-table around as an argument
has a bad smell to me also. Can you just override a local variable with
let just before it is needed?

If the syntax table is only really needed in mh-regexp-in-field-p, the
lowest-level function, then perhaps we can put the syntax table smarts
in there. That way, we don't have to pass around a syntax table, nor do
we have to figure out what syntax table we need everywhere we call
mh-modify-header-field or mh-regexp-in-field-p.

Thanks a lot for your effort on this one.

Re: Intermediate review for SF #1708292

Jeffrey Honig — 2012-02-21T05:42:29


I have this working now, but it seems a bit ugly.

For the regexp to work properly with the full set of regexp
functionality, you need to have the proper syntax table in use.  The
main case where this applies is when mh-modify-header-field makes the
above call to mh-regexp-in-field-p, it uses the ``\b'' operator which
matches the empty string at the beginning or end of a word.  

The mh-regexp-in-field-p function is also used in mh-insert-auto fields
which allows regexps specified by the user.

What is considered part of a word varies by the field:

The Fcc field takes a path name starting with '+', so all characters
that are valid as part of a path name on the local system should be
marked as word characters.

An address field (To, Cc, From), in which any character valid in an
RFC5322 is allowed.  I *think* we can get by with the values defined in
atext in section 3.2.3 of said RFC, plus ``.'' and ``< at >''.

Any other field should work with the default text-mode-syntax-table.


So, what I came up with is the

Re: Intermediate review for SF #1708292

Jeffrey Honig — 2012-02-21T01:12:11


Thanks for the review input, it is all applied.


Unfortunately I have discovered a flaw in the code and may need another
syntax-table for Fcc to fix it.  In mh-modify-header-field there is this
line:

(mh-regexp-in-field-p (concat "\\b" value "\\b") field))

This will fail for something like ``+outbox'' because of how ``+'' is
mapped in the syntax table.  I.e. ``\b+outbox\'' will not match
``+outbox'' because ``+'' is not considered part of the word.  So I'll
have to play with modifying the syntax map.

Additionally, I think that line should read:

(mh-regexp-in-field-p (concat "\\b" (regexp-quote value) "\\b") field))

Because the supplied value is not a regexp and there may be cases where
it could be interpreted as one and cause a failure.  That does not help
in the Fcc case.


Can you provide some examples?

I am also seeing some issues, namely that an alias will be expanded to
include the name as well as the address, and that will not match a bare
address.  It may require more sophisticated parsing

[ mh-e-Bugs-3483408 ] Add completion for folder names formh-index-new-messages

SourceForge.net — 2012-02-20T18:02:37

Bugs item #3483408, was opened at 2012-02-02 17:16
Message generated for change (Comment added) made by cmconnelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=3483408&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: mh-e-8.3
Status: Open
Resolution: Accepted
Priority: 6
Private: No
Submitted By: Claire Connelly (cmconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add completion for folder names for mh-index-new-messages

Initial Comment:
I use mh-index-new-messages a lot to get access to different sets of mailboxes (which I have separated into trees), so I can get all the messages related to different tasks.  But I have to type the whole name of the enclosing folder for each group; completion would be very helpful.


----------------------------------------------------------------------

Date: 2012-02

[ mh-e-Bugs-3483408 ] Add completion for folder names formh-index-new-messages

SourceForge.net — 2012-02-20T00:51:11

Bugs item #3483408, was opened at 2012-02-02 17:16
Message generated for change (Comment added) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=3483408&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Status: Open
Private: No
Submitted By: Claire Connelly (cmconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add completion for folder names for mh-index-new-messages

Initial Comment:
I use mh-index-new-messages a lot to get access to different sets of mailboxes (which I have separated into trees), so I can get all the messages related to different tasks.  But I have to type the whole name of the enclosing folder for each group; completion would be very helpful.


----------------------------------------------------------------------

Date: 2012-02-19 16:51

Message:
Agreed, thanks.

In the meantime, simply select the

Re: Intermediate review for SF #1708292

Bill Wohler — 2012-02-03T02:08:28


Let's wait until the request appears so we don't add to our
customization surface area unnecessarily.


That should be case-fold-search, no?


Shouldn't that be \\| instead of \\I?

Otherwise, very clean.


Pointing? How about "Extract field name and value from the field at point."


Delete the last line. As we discussed, we'd leave point alone, and you
did so. Function looks good.


Good. Within function, s/headers/header-fields/.

I patched the code with my above changes and my Fcc folder is added to
the header. Nice!

I played with the To and cc fields and found that aliases or addresses
that were the same in the components file and message were duplicated.
That probably would be good to fix. Interestingly, a random string (not
an alias), that appeared in both places was not duplicated. Do you see
this?

Thanks!

p.s. Yes, I'm on a plane :-).

[ mh-e-Bugs-3483408 ] Add completion for folder names formh-index-new-messages

SourceForge.net — 2012-02-03T01:16:41

Bugs item #3483408, was opened at 2012-02-02 17:16
Message generated for change (Tracker Item Submitted) made by cmconnelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=3483408&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Claire Connelly (cmconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add completion for folder names for mh-index-new-messages

Initial Comment:
I use mh-index-new-messages a lot to get access to different sets of mailboxes (which I have separated into trees), so I can get all the messages related to different tasks.  But I have to type the whole name of the enclosing folder for each group; completion would be very helpful.


----------------------------------------------------------------------

You can respond

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-13T05:19:06

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconve

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-13T04:54:16

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by tphelps
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconv

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-09T05:45:15

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconve

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-09T05:34:28

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by tphelps
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconv

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-09T05:25:09

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconve

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-09T04:39:55

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by tphelps
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconv

Re: The first release candidate for nmh 1.4 is available!

Bill Wohler — 2012-01-07T19:46:54

The following message is a courtesy copy of an article
that has been posted to gmane.mail.nmh.devel as well.

MH-E developers: Let's investigate whether we could use "unseen" to
replace our code for `F n' (`mh-index-new-messages').

We have to be careful though as it would break our compatibility with
older versions of nmh and possibly GNU Mailutils as well.

Ken Hornstein <kenh< at >pobox.com> writes:

Re: nmh in near, medium, and far-term

Bill Wohler — 2012-01-07T19:37:46

The following message is a courtesy copy of an article
that has been posted to gmane.mail.nmh.devel as well.

Definitely agree on ditching MM_CHARSET and enabling MIME code
regardless of any locale settings.

MH-E developers: please rack your brains and the SourceForge trackers
for changes to MH that would benefit MH-E. Thanks!

Ken Hornstein <kenh< at >pobox.com> writes:

Re: Intermediate review for SF #1708292

Jeffrey Honig — 2012-01-07T03:06:59

Attached is my (almost) final diff.  Is the likelyhood that someone would
want to expand aliases in another field high enough that we should allow
customization of the regexp?

Thanks

Jeff

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-09T05:45:15

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by wohler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconve

[ mh-e-Patches-2945712 ] Postpone junk processing

SourceForge.net — 2012-01-09T05:34:28

Patches item #2945712, was opened at 2010-02-03 21:23
Message generated for change (Comment added) made by tphelps
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=313357&aid=2945712&group_id=13357

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Bazaar
Status: Open
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ted Phelps (tphelps)
Assigned to: Bill Wohler (wohler)
Summary: Postpone junk processing

Initial Comment:
The attached patch adds new marks to the mh-e folder view to flag messages as white- or black-listed, so that the training of the junk mail filter can be postponed until mh-execute-commands is invoked.  This makes the behavior more consistent with the way refile and delete are already performed, makes it possible to undo a mis-labelling and moves the potentially slow junk mail filter training operation into a less inconv