nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] nmh welcome message


From: David Levine
Subject: Re: [Nmh-workers] nmh welcome message
Date: Thu, 29 Sep 2016 11:03:26 -0400

Oliver wrote:

> I like to have a different current folder in different terminals so in
> my .zshrc, I do:
>   export MHCONTEXT=/tmp/context.$$
> I've also got aliases which point it to /dev/null to prevent folder
> changes, e.g:
>   alias new='MHCONTEXT=/dev/null flist +inbox +nmh-workers +....
>
> So I'm sorry for being a pain but I'm concerned that the message
> will get repeated with my non-standard usage.

How about suppressing all of them with something like a "Welcome: disable"
profile component?

> Perhaps if the context file comes from $MHCONTEXT, it could only
> print the message if the context file already has a Version: reference
> where the version is old.

OK.

> Also, it looks like you're just doing strcmp on the version. So
> what happens for someone with an NFS shared home where the nmh
> versions are out of sync between different client systems. They'll
> get a welcome message every time they switch between their NFS
> client systems, right? It might be better to limit it to cases where
> the version number is actually newer.

But I'd like to be notified if a new version is backed out.  So I
think that suppression is the way to go in this case.

> If I remember correctly, there's already something printed if
> .mh_profile is missing. Have you checked how it interacts with that.

That's a fatal error, and it happens before the nmh version check.

> I notice that install-mh is also in the exception list.

That's because install-mh prints the message unconditionally.

> Another slight concern I have is with the exceptions being checked by using
> strcmp on invo_name because links to nmh commands is maybe not that
> uncommon to get different keys for ~/.mh_profile.

Instead of using invo_name, we could put a key in each program, so
it'll work no matter how it's called.  (The key would probably be an
additional parameter to nmh_init()).

> As a final point, should it be easier for packagers to customise the
> message?

I don't think so.  The message is completely nmh specific.  Packagers
can add with a postinstall, if that's supported.  Or a patch, if not.
I'd be willing to add something here if there's demand, but I just
don't expect it.

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]