[Date Prev][Date Next][Thread Prev][][Date Index][Thread Index]

Re: `call-process-region' bug?


I reported the same problem 4 days ago and made a change to the
emacs-w3m CVS trunk so that a point may move to the end of the
region just before calling call-process-region.  However, please
don't use the latest emacs-w3m CVS since it is currently buggy
for asynchronous processes.  I'll announce when it is fixed.

>>>>> In <87k75p5kjv.fsf@enki.rimspace.net>
>>>>>	Daniel Pittman <daniel@rimspace.net> wrote:

> 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