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

[Kenichi Handa <handa@m17n.org>]

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;