[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Clearing `cur' Message.
From: |
Ralph Corderoy |
Subject: |
Re: [Nmh-workers] Clearing `cur' Message. |
Date: |
Sun, 14 Oct 2012 16:39:08 +0100 |
Hi David,
> > How does one clear `cur' for a folder? It can be set with `folder
> > 42' though the mandatory line of output is annoying.
>
> I just redirect the output to /dev/null.
Me too, in the expectation it contains just that one line.
> There is a folder -noprint, currently undocumented. All it does now
> is allow output of the folder stack while suppressing other output.
> Maybe change it to suppress all output?
I don't notice a difference.
$ folder -noprint .
inbox+ has 6312 messages (1-7075); cur=7075; (others).
I think unless -push/-pop/-list is given then printsw++ causes -noprint
to be ignored?
> > When there is no current message, e.g. after `rmm', ~/.mh_sequences
> > still contains the old value and mark still lists it. For a new
> > folder, there is no .mh_sequences but once one's created it seems
> > cur never leaves it. If I delete the `cur:' line from .mh_sequences
> > then all seems well; mark still lists it but it's empty. Is that a
> > valid workaround?
>
> That could cause confusion if there was nothing else in .mh_sequences:
>
> /*
> * If no mh-sequences file is defined, or if a mh-sequences file
> * is defined but empty (*mh_seq == '\0'), then pretend folder
> * is readonly. This will force all sequences to be private.
> */
> if (mh_seq == NULL || *mh_seq == '\0')
> set_readonly (mp);
Isn't that testing the profile entry that defines the name of the
sequences file?
> The workaround for now would be to set cur: to something that isn't a
> message. `mhpath new` will give you one, but as a full path. "cur:
> 0" seems to work.
Using `mhpath new's number would make cur be valid again should
something create that number. :-) I agree seq_init() seems to silently
ignore any sequence where m_atoi() returns <= 0.
if ((j = m_atoi (*ap)) > 0) {
This suggests `cur: 0' is fine, as is `cur: foo' as m_atoi() returns 0
on any non-digit. Not that I'm suggesting `foo'.
> But we really should come up with an interface to do that. folder
> -clearmessage? Or folder -clear, but that seems like it should clear
> the current folder, too.
Perhaps have mark work on it as it already partially does. `mark -seq
cur -delete all'.
Cheers, Ralph.