call-process and display-on-the-fly

call-process and display-on-the-fly

[Kim F. Storm]

While debugging the "call-process" output buffering problem
I noticed that the display_on_the_fly flag is turned off
if the coding system cannot be determined immediately.

However, it seems bogus not to turn it back on when we actually
succeeds determining a coding system.

What about the following patch to remedy this?

Index: src/callproc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/callproc.c,v
retrieving revision 1.203
diff -u -r1.203 callproc.c
--- src/callproc.c	29 Sep 2004 23:40:53 -0000	1.203
+++ src/callproc.c	12 Oct 2004 14:15:17 -0000
@@ -748,6 +748,7 @@
     int total_read = 0;
     int carryover = 0;
     int display_on_the_fly = !NILP (display) && INTERACTIVE;
+    int do_display = display_on_the_fly;
     struct coding_system saved_coding;
     int pt_orig = PT, pt_byte_orig = PT_BYTE;
     int inserted;
@@ -778,7 +779,7 @@
 	    nread += this_read;
 	    total_read += this_read;
 
-	    if (display_on_the_fly)
+	    if (do_display)
 	      break;
 	  }
 
@@ -817,7 +818,7 @@
 		decode_coding (&process_coding, bufptr, decoding_buf,
 			       nread, size);
 
-		if (display_on_the_fly
+		if (do_display
 		    && saved_coding.type == coding_type_undecided
 		    && process_coding.type != coding_type_undecided)
 		  {
@@ -826,7 +827,7 @@
 		       done by insufficient data.  So, we give up
 		       displaying on the fly.  */
 		    xfree (decoding_buf);
-		    display_on_the_fly = 0;
+		    do_display = 0;
 		    process_coding = saved_coding;
 		    carryover = nread;
 		    continue;
@@ -929,12 +930,13 @@
 	    bufptr = tempptr;
 	  }
 
-	if (!NILP (display) && INTERACTIVE)
+	if (display_on_the_fly)
 	  {
 	    if (first)
 	      prepare_menu_bars ();
 	    first = 0;
 	    redisplay_preserve_echo_area (1);
+	    do_display = 1;
 	  }
 	immediate_quit = 1;
 	QUIT;

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: call-process and display-on-the-fly

[Kenichi Handa]

In article <m3zn2sui3v.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> While debugging the "call-process" output buffering problem
> I noticed that the display_on_the_fly flag is turned off
> if the coding system cannot be determined immediately.

> However, it seems bogus not to turn it back on when we actually
> succeeds determining a coding system.

I agree with that kind of change.  But...

> What about the following patch to remedy this?

It seems that the patch doesn't work as expected because
once do_display is set back to 1, the following condition
hits again:

> +		if (do_display
>  		    && saved_coding.type == coding_type_undecided
>  		    && process_coding.type != coding_type_undecided)
>  		  {

so do_display is set to 0 again.  And, why is it necessary
to introduce a new variable do_display?  How about this
patch?



--- callproc.c	29 Sep 2004 23:40:53 -0000	1.203
+++ callproc.c	13 Oct 2004 00:42:36 -0000
@@ -823,12 +823,15 @@
 		  {
 		    /* We have detected some coding system.  But,
 		       there's a possibility that the detection was
-		       done by insufficient data.  So, we give up
-		       displaying on the fly.  */
+		       done by insufficient data.  So, we try the code
+		       detection again with more data.  */
 		    xfree (decoding_buf);
 		    display_on_the_fly = 0;
 		    process_coding = saved_coding;
 		    carryover = nread;
+		    /* This is to make the above condition always
+		       fails in the future.  */
+		    saved_coding.type = coding_type_no_conversion;
 		    continue;
 		  }
 
@@ -935,6 +938,10 @@
 	      prepare_menu_bars ();
 	    first = 0;
 	    redisplay_preserve_echo_area (1);
+	    /* This variable might have been set to 0 for code
+	       detection.  In that case, we set it back to 1 because
+	       we should have already detected a coding system.  */
+	    display_on_the_fly = 1;
 	  }
 	immediate_quit = 1;
 	QUIT;

Re: call-process and display-on-the-fly

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> It seems that the patch doesn't work as expected because
> once do_display is set back to 1, the following condition
> hits again:
>
>> +		if (do_display
>>  		    && saved_coding.type == coding_type_undecided
>>  		    && process_coding.type != coding_type_undecided)
>>  		  {
>
> so do_display is set to 0 again. 

Right -- your patch is better.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: call-process and display-on-the-fly

[Kenichi Handa]

In article <m3sm8jm107.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> Kenichi Handa <handa@m17n.org> writes:
>>  It seems that the patch doesn't work as expected because
>>  once do_display is set back to 1, the following condition
>>  hits again:
>> 
>>>  +		if (do_display
>>>   		    && saved_coding.type == coding_type_undecided
>>>   		    && process_coding.type != coding_type_undecided)
>>>   		  {
>> 
>>  so do_display is set to 0 again. 

> Right -- your patch is better.

Then, shall I install it?

---
Ken'ichi HANDA
handa@m17n.org