Eric Abrahamsen writes: > Lars Ingebrigtsen writes: > >> Eric Abrahamsen writes: >> >>>> Xref: reader01.eternal-september.org foo.bar:2523 gnu.emacs.help:57603 zot.bar:3242 >> >> [...] >> >>> Slowly, slowly, I'm getting this done. I'm still a bit confused here, >>> though. The xref elements look like they're not supposed to have spaces >>> in them, but the existing code does this: >>> >>> (insert "Xref: " sysname " " group ":") >>> (princ article (current-buffer)) >>> >>> Which leaves a space between sysname and group. >> >> I'm not quite sure I understand the question? The sysname is just a >> part of the syntax of the Xref header and isn't used for anything by >> Gnus, as far as I know. So there has to be a space? It's certainly not >> part of the group name. > > TBH I only just went and read the RFC for this -- something I'd been > trying to avoid! > >>> You say the existing xrefs should be left as they are, but the code adds >>> "prefix" to them. Should this be added unconditionally? >> >> Uhm... I think so? But I'm not sure. > > Looking over the code again, I think it's best to only add if the prefix > isn't already there. > >>> Here's the new version of the function, operating on a header struct. >>> Does this look right to you? >>> >>> Thanks, >>> Eric >>> >>> (defun nnvirtual-update-xref-header (header group prefix sysname) >>> "Add xref to component GROUP to HEADER. >>> Also add a server PREFIX any existing xref lines." >>> (let ((bits (split-string (mail-header-xref header) >>> nil t "[[:blank:]]")) >>> (art-no (mail-header-number header))) >>> (setq bits >>> (mapcar (lambda (bit) >>> (concat prefix bit)) >>> bits)) >>> (setf (mail-header-xref header) >>> (mapconcat #'identity >>> (cons (format "%s %s:%d" >>> sysname group art-no) >>> bits) >>> " ")))) >> >> I think so. The body of the let form is perhaps more easily expressed >> as >> >> (setf (mail-header-xref header) >> (concat (format "%s %s:%d " sysname group art-no) >> (mapconcat (lambda (bit) >> (concat prefix bit)) >> bits " "))) >> >> ? > > Sure, this was just my halfway-there muddle. > > I've cleaned this branch, squashed it, and am preparing to test for a > while. I'm attaching the full diff in case anyone wants to read it :) > > A net removal of 562 lines with, I hope, no change in behavior. I revisit this every few months, and have to completely relearn all the code each time. With any luck that means that I've looked over these diffs sufficiently to have caught more bugs. At any rate, I think this is finally ready to go. Eric