`call-process-region' bug?

I use the `w3m' emacs integration package, together with w3mmee(1), to render HTML to text under XEmacs. Rather, I have just started to, after using w3m(1) to do so previously. I use XEmacs "21.5 (beta16) \"celeriac\" (+CVS-20031124) XEmacs Lucid" under Linux. In doing this, I found that w3mmee(1) wouldn't give any output from the HTML rendering, which w3m(1) did. This was ... odd. I traced through the code and found out why. The w3m.el package uses the function `call-process-region' with the DELETE argument set to true. When this call is made, `point' is *not* at `point-min' in the work buffer. The region passed is the full buffer, though. The code for `call-process-region' is: (let ((s (and deletep (copy-marker start t))) (e (and deletep (copy-marker end)))) (let ((retval (apply #'call-process program (list (current-buffer) start end) buffer displayp args))) ;; If start and end were the same originally, s will be beyond e now (if (and deletep (> e s)) (delete-region s e)) retval))) The 's' marker is, as far as I can tell, expected to move when the output is inserted. Unfortunately, as (point) is not (point-min), the output is inserted *after* 's' but before 'e'. The net result of this is that /all/ the content is removed, not just the old content. I have worked around this by modifying the w3m.el package to call `(goto-char (point-min))' before calling `call-process-region', but this feels like a work-around to code that does not do what is expected. Is this intentional? I suspect that this works by chance, rather than design, for most callers. Would the correct fix be to put point at the marker 's' in the `call-process-region' code? Daniel -- Never stop questioning -- curiosity has its own reason for existence. -- Albert Einstein