Re: [Nmh-workers] MH-W intro/help request

[Erich Boleyn]

[Whoops, sent this from the wrong email address before... resent]

Ralph Corderoy writes:

> > Is there any way I can completely avoid the giant folder check?  I
> > can't think of why it is being done time after time for simple program
> > invokations that, for example, refer to a specifically enumerated
> > message.
> 
> I do not have `unseen-sequence' set in .mh_profile, so it does not need
> updating.
...
> Since .mh_sequences is first read and then written to, it looks like the
> "make it match reality" code runs every time.  I agree, when `42' is
> explicitly given, and there's no unseen sequence that might need
> updating, .mh_sequences could be skipped entirely.  When `42' is
> omitted, then .mh_sequences needs reading to get `cur', but it need not
> be written, leaving detritus in sequences to be cleaned up by a later
> command that cares.  In both cases, the getdents() aren't needed.
> 
> BTW, getdents() is also impacted by ,314 and friends that clutter a mail
> folder.  On a busy, unpacked, +inbox, they can grow many.

Hmm.

[Note: I've also seen a bunch of other responses on this overall topic
 "do we have to do all this work all the time"]

Let me describe the scenario I'm expecting to see a little more, and
it might elucidate some angles.

Essentially for each major "page" or "view" used, we would expect to
see 1 or 2 commands that represent the major "task" the user is
performing, but then MH-W ends up needing to do from a few to even
many more to display to or interact with the end-user.

Let me show 2 example scenarios:
  1)  "scan view"
    1.1 The "pick" command (which I've optimized out if your list
        is just a message list).
    1.2 The "scan" comand.
    1.3 The "mark -list -sequence ..." command to get the list of
        messages marked via the "unseen" sequence, for colorization.

    NOTE: Since MH-W already has to qualify messages in any sequence
        returned, there is no point in anything but the raw sequence
        listing.

  2)  "message view"
    1.1 MH-W needs to start by looking at what is in the message
        via "mhlist", it would do this normally to update the "cur"
        or whatever else needs updating.
    1.2 MH-W makes several calls to "scan" with formats to extract
        header fields.
    1.3 Extract each of the components needed to display the message.
        This could be from 1 to many, for example for inlined images
        in an HTML email.

So, the result of all of this is that I'm forming a model which suggests
maybe I should ask if we could have ... I'm not sure what to call it ...
a "-nocheck" switch which would not need to check the folder nor
update any sequences, and would be allowed to simply fail if you tried
to use a relative or sequence-based message ID.

Examples of what I'm asking for:
  1)  "show -nocheck 150"
     Would blindly access message 150, would not update "cur" or any
     other sequence.

  2)  "mhlist -nocheck <options> 150"
     Would operate on message 150 with, again, no update of "cur" or
     any other sequence.

  3)  "mark -list -nocheck -sequence ..."
     Would give the list in the raw form without needing to do anything.


To summarize, my interest in making these faster isn't so much for the
*single* invokation case, but the fact that MH-W may have to call them
many to even 10+ times in various combinations for one percieved result
for the end-user (the "message view" is the big poster child for this).
... Not that various Hacker-types would mind having a faster mechanism
when they know what they are doing to access email in stupendously
large folders...

It is straightforward to have each of the MH-W pages have at least one
activity which would update cur/the sequences, but having it done 10
times in a row seems excessive/wasteful and as I've demonstrated above
could be prohibitive.

How does this sound?


--
    Erich Stefan Boleyn     <address@hidden>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"