headers
SourceForge.net | 3 Feb 2012 02:16
Picon

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

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 by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113357&aid=3483408&group_id=13357

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Wohler | 3 Feb 2012 03:08
Picon
Picon
Gravatar

Re: Intermediate review for SF #1708292

Jeffrey Honig <jch <at> honig.net> wrote:

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

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

> +                               (case-fold-string t))

That should be case-fold-search, no?

> +                           (if (string-match field "^To$\\|^Cc$\\I^From$")

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

Otherwise, very clean.

> +(defun mh-extract-header-field ()
> +  "Extract field name and field value from the field at pointing.

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

> +Returns a list of field name and value (which may be null).
> +Leaves the pointer at the beginning of the next line."

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

Permalink | Reply | 4 comments |
headers
SourceForge.net | 20 Feb 2012 01:51
Picon

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

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

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

>Comment By: Bill Wohler (wohler)
Date: 2012-02-19 16:51

Message:
Agreed, thanks.
(Continue reading)

Permalink | Reply | 1 comment |
headers
SourceForge.net | 20 Feb 2012 19:02
Picon

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

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.

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

>Comment By: Claire Connelly (cmconnelly)
Date: 2012-02-20 10:02

Message:
I currently have about 16,000 unread messages (most of which are in folders
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Honig | 21 Feb 2012 02:12
Face

Re: Intermediate review for SF #1708292

Bill Wohler <wohler <at> newt.com> wrote:

> Jeffrey Honig <jch <at> honig.net> wrote:
> 
> > 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?
> 
> Let's wait until the request appears so we don't add to our
> customization surface area unnecessarily.
> 
> > +                               (case-fold-string t))
> 
> That should be case-fold-search, no?
> 
> > +                           (if (string-match field "^To$\\|^Cc$\\I^From$")
> 
> Shouldn't that be \\| instead of \\I?
> 
> Otherwise, very clean.
> 
> > +(defun mh-extract-header-field ()
> > +  "Extract field name and field value from the field at pointing.
> 
> Pointing? How about "Extract field name and value from the field at point."
> 
> > +Returns a list of field name and value (which may be null).
> > +Leaves the pointer at the beginning of the next line."
> 
> Delete the last line. As we discussed, we'd leave point alone, and you
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeffrey Honig | 21 Feb 2012 06:42
Face

Re: Intermediate review for SF #1708292

Jeffrey Honig <jch <at> honig.net> wrote:

> Bill Wohler <wohler <at> newt.com> wrote:
> 
> > Jeffrey Honig <jch <at> honig.net> wrote:
> > 
> > > 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?
> > 
> > Let's wait until the request appears so we don't add to our
> > customization surface area unnecessarily.
> > 
> > > +                               (case-fold-string t))
> > 
> > That should be case-fold-search, no?
> > 
> > > +                           (if (string-match field "^To$\\|^Cc$\\I^From$")
> > 
> > Shouldn't that be \\| instead of \\I?
> > 
> > Otherwise, very clean.
> > 
> > > +(defun mh-extract-header-field ()
> > > +  "Extract field name and field value from the field at pointing.
> > 
> > Pointing? How about "Extract field name and value from the field at point."
> > 
> > > +Returns a list of field name and value (which may be null).
> > > +Leaves the pointer at the beginning of the next line."
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Wohler | 22 Feb 2012 04:37
Picon
Picon
Gravatar

Re: Intermediate review for SF #1708292

Jeffrey Honig <jch <at> honig.net> wrote:

> So, what I came up with is the requirement to pass a syntax table to
> mh-regexp-in-field-p and mh-modify-header-field.  Specifying nil will
> cause mh-modify-header-field to make an assumption based on the field
> name.  Does this sound like overkill?  Maybe all we need is
> mh-modify-header-field to make a best guess?

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.

--

-- 
Bill Wohler <wohler <at> newt.com> aka <Bill.Wohler <at> nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeffrey Honig | 22 Feb 2012 05:30
Face

Re: Intermediate review for SF #1708292

Bill Wohler <wohler <at> newt.com> wrote:

> Jeffrey Honig <jch <at> honig.net> wrote:
> 
> > So, what I came up with is the requirement to pass a syntax table to
> > mh-regexp-in-field-p and mh-modify-header-field.  Specifying nil will
> > cause mh-modify-header-field to make an assumption based on the field
> > name.  Does this sound like overkill?  Maybe all we need is
> > mh-modify-header-field to make a best guess?
> 
> 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?

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.

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

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane