I've added some documentation (perldoc mhisto) and filtering features:
You may specify a comma or pipe-delimited list of address (substrings)
to be used in a regular expression to limit the set of per-sender
graphs to be printed. The switch may also be given as a negated form
Jon Steinhart wrote:
> I use these hooks to build a separate searchable database. I have a
> number
> of additional command line utilities that operate on this database.
I'm interested in trying this.
> Any of you could use these hooks to maintain a separate directory tree
Nothing too fancy, but possibly of interest/use for some:
http://pthbb.org/manual/software/MH/mhisto.pl
Generates text-based histograms of folder contents by
sender using perl's Text::BarGraph e.g;
FOLDER SPAM Thu, 20 Feb 2014 11:44:15 -0500
173 TOTAL
2014-02-13 ( 7) ##
2014-
>maybe just using URIs and having the data accessed "on demand" would solve
>this and also re duce message size.
MIME already has this. It's nice in theory, but it doesn't get used.
Among other things, it requires people to treat URIs as they're "meant to"
(permanent identifiers), and also to maint
I think the whole exercise is too limited. If we're going to really "blue sky"
an idea, lets be revolutionary.
First of all, the whole concept of email is kind of obsolete. There should be a
universal messaging protocol that allows, for example, me to send you a message
via email, and you
to r
So again, I think that the UI issues and message store issues are independent.
I'm personally much more interested in the UI issues. As I've said before,
the ability to scan/next/prev/show attachments would do it for me. This
wouldn't be too hard to add to the current UI. Oh, and the ability to
n...@dad.org writes:
> I am suggesting this exercise only for recreational purposes.
>
> Design MH, from scratch, without the constraints affecting the original
> MH design.
> Suppose, you weren't designing a system to run on a time shared PDF 1145,
> but on a
> single user, multi-core system.
Hi Ken,
> You say that the current store is inadequate. Okay, I can't really
> argue that. But ... we've got a problem here. We have a number of
> front-ends that have grown up assuming that the store isn't going to
> change.
No, this isn't nmh. This is Norm's MH-2014. :-) The other project
Hi Ken,
> > $ readlink ~/bin/mhcat
> > /usr/bin/mh/mhstore
> > $
> >
> > Don't recall where I learnt to create it, mhstore(1) here doesn't
> > mention `mhcat', but I use it quite a bit.
>
> Are you sure you don't have something in .mh_profile that makes that
> work? I don't see anythi
>$ readlink ~/bin/mhcat
>/usr/bin/mh/mhstore
>$
>
>Don't recall where I learnt to create it, mhstore(1) here doesn't
>mention `mhcat', but I use it quite a bit.
Are you sure you don't have something in .mh_profile that makes that
work? I don't see anything in the code that would make
>What you seem to be saying is that instead of an MUA where you are in
>its own shell, e.g. mail(1), you have an MUA comprised of many commands,
>scriptable with a bit of shell control-flow, but no commands outside the
>MUA's set should touch the storage.
Well, not exactly.
I guess my feeling is
>As for IMAP on the back end, forget it. MH cannot deal with immutable
>message files. It just won't fly. I looked at using the various IMAP
>annotate extensions, but the bottom line is the code would have to work
>with a plain old 3501-compliant IMAP server. It can't. And even with
>IMAP anno
jp>> ... if one has no moral objections to the GPL.
pv>i have a moral objection to the GPL.
I should perhaps clarify, if *the one undertaking the effort*
has no objection to the GPL.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.non
Hi Paul,
> i would. first, i'd adopt the messages-as-directories model norm gave,
> since it supports MIME, where our current model does not. by "support"
> i mean i want to use normal UNIX file access to work with my message
> store.
Yes. The original email should also be available, like upas's
Hi Ken,
> 1) The message store (1 file per message), instead of one file for the
>whole store.
> 2) Individual commands to perform message operations, as opposed to
>traditional monolithic MUAs.
I've stuck with MH because it's both. Either on its own may not have
kept me over the decades
Hi Ken,
> Maybe a set of primitives, like "mhcat" that would let you output a
> part of a message on stdout
Aside, I have
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit. The `s
Hi Ken,
> I dunno; to me, databases are fine for specialized things, but just
> add a level of complexity that I don't necessarily think is useful.
> Also, I'm not sure of the savings; maybe it's just me, but I rarely
> get identical copies of the same message or attachment.
I think it's just you
Hi Jeff,
> Just because you can use a lot of disk space doesn't mean you should.
> If you use a database backend for indexing the messages you detect and
> avoid duplicate copies of attachments. The actual pieces of the
> message could still exist in directories with duplicate copies linked
> in.
Hi Norm,
> Here, for example, is one stab at how messages would be stored.
> Each message would be a directory. Each component would be a file or
> directory, whose name was the component name, Each MIME part would be
> a directory.
Plan 9's filesystem that presents an email as a directory is wor
19 matches
Mail list logo
