Ken Hornstein writes:
Big request (the one I have only a poor workaround for):
I need a feature in the MIME support (or just help if I'm totally
confused). I have for the life of me not been able to figure out
how to get "Content-IDs" listed. We really need those to be able
to display inline images in email. The "mhlist" program will list
the file names or if something is marked as "inline", but not the
content-id itself, which is how the HTML in the email identifies
which picture or other thing is inlined in the proper location.
I know David pointed you to -debug which will show the Content-ID (something
I didn't know) but to me that suggests we need a more generic mechanism,
as we are starting to have more programs that are interested in parsing the
mhlist output. That says to me we should make that stuff available via
mh-format(5).
I was pondering a reply to his email. I'm glad there exists a way
(and will take advantage of it while shaking things out), but as a
general rule I'd like whatever mechanisms I'm using to be robust
and expected to continue to work in the reasonable future... so
yeah a more generic/known lasting mechanism would be nice.
Hm, it seems like "mark" using it's existing message arguments to generate
an intersection of the current sequence would do what you want. E.g.,
% mark 7 8 21 -sequence unseen list
Would only return message numbers that were out of the list and also part
of unseen. But that might be hard to implement in "mark". Does this
not work for you?
% pick unseen <pick arguments>
As remarked by another email in this thread, there were hints that "mark"
could do what I want (intersection of a message list and a sequence), but
alas it turned out not to work and I finally understood that, at least
right now, any reference to a sequence is treated as a message list, so
you can't list messages *in* a sequence.
What I use now is "mark -list -sequence unseen", which returns compressed
lists of messages (i.e. "1-5,7-8" instead of "1 2 3 4 5 7 8"). Parsing
this to intersect it with my pick output is relatively fast, though it
is of course ineligant compared to getting *just* the list you want. It
is also surprisingly slow (like 1/7th of a second to get this vs. other
MH programs which run 10x or more faster). I don't really understand why
it is so slow, since it is a near character-for-character copy of the
one line that the .mh_sequences file has in it. If it wasn't so very
slow compared to the other MH programs, I probably would not have even
brought it up for now.
I tried using "pick ...", but it of course doesn't do what you expect
if your pick was just a message list like "last:40", and just "pick
unseen" can produce mountainous output, all the individual numbers
are listed one by one. If you have a very large email box with
many unread (say 100K+ emails), then it can be upwards of 1 MB *just*
to get the unseen sequence numbers.
The whole point of this is being able to get the list of unseen messages
in a larger result you *already have*, so as to colorize/shade the
scan results for simple user consumption. Usually not more than 40-50
or so total in the larger result.
Having to list the entire sequence as individual numbers just seems
quite wasteful, and it could be unintuitively slow.
I also very much do not want to, say, produce another sequence as
the output, since, at least so far, MH-W is essentially stateless and
you can have any number of email windows showing any number of things
in any sequence, and it all works properly. I.e. it passes whatever
selection parameters (folder, message lists, etc.) to each command,
it extracts components of messages to standard output for inclusion
into the web page, inline images are done using "Data URIs" so they
don't have to call back to the webserver, etc.
So, having the MH-W framework itself using any temporary files or
lists is a show-stopper for me at this time.
Of course, you as the user can decide to create sequences, read them,
etc. because you are asking for it, and it will not violate your
expectation.
--
Erich Stefan Boleyn <erich@uruk.org> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers