Re: [Nmh-workers] hooks interface issues
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 the whole source at http://git.savannah.gnu.org/cgit/nmh.git/tree/sbr/m_getfld.c?id=a0514c9a6f41ea1b0d60553ca578312a9f3bd9ab#n620 suggests that buf will have a \n at the end of it for Unix-text-file lines but not for the last line of an ITS text file. Whether that may cause problems for any of the users of buf, I've no idea. Some fix was clearly needed to avoid storing EOF in buf but kre's right, we shouldn't be supporting Emacs's brain-damaged insistence of putting ITS text files on Unix. Too many things break with them, despite GNU's efforts, and at best we should just complain about an unterminated line and stop. POSIX says a text file is zero or more lines, each line terminated by a newline. Emacs and Stallman lost. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 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 Emacs's stupidity in this respect and how each user has to discover it, sometimes more than once. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
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 Emacs's stupidity in this respect and how each user has to discover it, sometimes more than once. A better choice in my opinion, at least if you sometimes edit non-text-files, is `(setq require-final-newline 'ask)'. Missing the last newline is about as common as editing a file that will break if you add a newline, for me (both are pretty rare occasions). //Christer -- | Hagåkersgatan 18C | Phone: Home +46 31 435203 CTH: +46 31 772 5431 | | S-431 41 Mölndal |Cell: +46 707 535757 | | Sweden| Mail: m...@chalmers.se | An NT server can be run by an idiot, and usually is. -- Tom Holub ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
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 within add-hook. The hook sets MHCONTEXT to an empty file, but doing so in an interactive shell does not let one reproduce the behavior. mark has a hidden -debug switch. Does it reveal anything different between the two cases? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
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 command you're running and whatever command is invoking the add hook. One may be wiping out the other's changes. There was a significant retooling in that code as part of the sequencing lock overhaul, so it's possible we got something wrong. Or maybe it never would have worked to begin with. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
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 Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
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 return from your add hook? There shouldn't be that many steps. Or give us more detail about what you're doing. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
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 will have a \n at the end of it for Unix-text-file lines but not for the last line of an ITS text file. Whether that may cause problems for any of the users of buf, I've no idea. I just reviewed a few and they're fine. They've been this way for a long, long time. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
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 messages
DEBUG=0
#Backup message suffix
BAK=`mhparam mimehook-bak`
SLOCAL=`mhparam mimehook-slocal`
[ $DEBUG = 1 ] echo -n Processing message $1;
if grep -q -E '^MIME' $1 ; then
[ $DEBUG = 1 ] echo ...is MIME
SRCDIR=`dirname $1`
MSG=`basename $1`
#Don't clobber main context
if [ -n $SLOCAL ]; then
export MHCONTEXT=`$SLOCAL`
[ $DEBUG = 1 ] echo slocal context $MHCONTEXT
folder -fast +$SRCDIR /dev/null
fi
for PART in `mhstore $MSG 21 | awk 'match($0,/as file .+/){print
substr($0,RSTART+8,RLENGTH)}'`; do
[ $DEBUG = 1 ] echo Processing part $PART;
#Tweak -auto name to match message number
PARTDIR=`dirname $PART`
PARTFILE=`basename $PART`
if `echo $PARTFILE | awk /^$MSG\./ { exit 1 }` ; then
NEWPART=$PARTDIR/$MSG.$PARTFILE
[ $DEBUG = 1 ] echo Renaming -auto part $PART to $NEWPART;
mv $PART $NEWPART
PART=$NEWPART
fi
mv -i $PART $SRCDIR
done
#DEFANG plain text
if [ ! -e $1.$BAK ]; then
[ $DEBUG = 1 ] echo Defanging MIME with mhfixmsg: backup in
$1.$BAK;
cp -i $1 $1.$BAK
mhfixmsg $1
fi
#Remark as unread
UNSEEN=`mhparam Unseen-Sequence`
if [ -n $UNSEEN ]; then
mark $MSG -nozero -add -seq $UNSEEN
fi
else
[ $DEBUG = 1 ] echo ...is NOT MIME
fi
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
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 `mhstore -file $FILE 21 | instead of: for PART in `mhstore $MSG 21 | And similar with mhfixmsg. When fed from files, the programs don't update sequences. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
