Re: [Nmh-workers] Clearing `cur' Message.

[Ralph Corderoy]

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.