Hi David,
When you say the file was not new-line terminated, which file? If
it was your .mh_profile ... I guess that's the fault of m_getfld().
Good catch. Fixed.
My quick skim of
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=a0514c9a6f41ea1b0d60553ca578312a9f3bd9abcontext=12
with
In message 20140225120259.d11791f...@orac.inputplus.co.uk, Ralph Corderoy wri
tes:
Any Emacs user that doesn't use `(setq require-final-newline t)' in
their .emacs or similar and has to suffer because of it has made their
bed... :-) The number of wasted hours I've seen over the years due to
Jerrad wrote:
In trying patch the last few nits in MIME-hooks, I seem to uncovered an
odd issue with mark. Despite the default behavior being to not zero a
sequence on -add, mark is clearing the sequence, even when -nozero is
explicitly given.
However I only see this behavior from mark
Initial .mh_sequences
cur: 15
pseq: 1-17
unseen: 15-17
Called in mime-add-hook if Unseen-Sequence is defined
mark 18 -nozero -add -seq unseen +/home/user/Mail/folder
Final .mh_sequences
cur: 18
pseq: 18
unseen: 18
Hm. I suspect there may be an interaction between the mark
The only difference is ctxpath, which is to be expected since MHCONTEXT
is set in one instance. I've also unsuccessfully tried a workaround of
copying the sequence to another, then using mark -seq unseen tmpseq $MSGNUM
___
Nmh-workers mailing list
The only difference is ctxpath, which is to be expected since
MHCONTEXT is set in one instance. I've also unsuccessfully tried a
workaround of copying the sequence to another, then using mark -seq
unseen tmpseq $MSGNUM
Ken's theory seems most likely. Can you step through in a debugger
after
Ralph wrote:
My quick skim of
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=a0514c9a6f41ea1b0d60553ca
578312a9f3bd9abcontext=12
with the whole source at
http://git.savannah.gnu.org/cgit/nmh.git/tree/sbr/m_getfld.c?id=a0514c9a6f41e
a1b0d60553ca578312a9f3bd9ab#n620
suggests that buf
I suppose I could try, but I've not used a C debugger
Hmm, on a hunch I just discovered that somehow the call to mhstore
in mime-add-hook's for loop is the trigger... of course that's the
raison d'etre of the script :-/
Hopefully it's not too hard to follow:
#!/bin/sh
VERSION=0.05
#Diagnostic
Jerrad wrote:
Hmm, on a hunch I just discovered that somehow the call to mhstore
in mime-add-hook's for loop is the trigger... of course that's the
raison d'etre of the script :-/
Try feeding mhstore from a file instead of a message, something like:
FILE=`mhpath $MSG`
for PART in
