bug#11822: 24.1; emacsclient terminal mode captures escape characters as text

[Stefan Monnier]

> When I created a frame on a second display, there were some calls to
> prepare_menu_bars where both variables were zero, but one call had
> windows_or_buffers_changed=13, update_mode_lines=24.

I was actually a bit confused, the problem is not that all_windows is
true, but that it's true *and* some_windows is false.

But yes, if windows_or_buffers_changed and update_mode_lines are both
0 then things are fine (we'll only redisplay the selected window),
whereas if they're set to 13/24 then we'll redisplay all windows/frames.

So the problem is the case where windows_or_buffers_changed=13 and
update_mode_lines=24.

> With a hardware watchpoint I see windows_or_buffers_changed getting set to
> 2 (wset_redisplay calls redisplay_other_windows),

This is a good setting: the value 2 is the special value which means
"only redisplay those windows which have the `redisplay' flag set
(either in the window, its frame, or its buffer)".

> 30 (apply_window_adjustment), 19 (clear_image_cache because some
> images were freed — I had the tool bar displayed this time), 53
> (Fclear_face_cache), 54 (Finternal_make_lisp_face, possible
> inheritance), 59 (x_set_menu_bar_lines), 60 (x_set_tool_bar_lines),
> 54, 56 (Finternal_set_lisp_face_attribute, possible inheritance), 54
> (many times back and forth between those two), 47 (redisplay_internal,
> because face_change_count was nonzero), 13 (redraw_frame), 58
> (free_realized_faces), 60,

Hmm... so we'd need to fix *all* those places to be more discriminating
(use wset_redisplay or equivalent) in order to avoid the global redisplay.

> the value of update_mode_lines changed just a few
> times, 0 to 2 (bset_update_mode_line)

Same as before: the value 2 is a good one.

> to 24 (status_notify, in case process status is used in a mode line
> for a buffer that might be visible in one or more windows) to
> 0 (redisplay_internal).

And this one *also* has to be fixed before the other fixes let us
avoid the global redisplay.  I installed the patch below which
should fix this part of the problem.

> It appears that init_iterator is getting called a total of 35 times during
> the creation of the second frame. I don’t have the details on how many for
> each frame, but one of the calls specifies base_face_id as
> MODE_LINE_INACTIVE_FACE_ID, which looks like it’s going to update the mode
> line coloring, at least, on the frame on the first display, which I hadn’t
> thought about before. So even if not all frames need updating, the
> previously-selected frame does.

Yes, but that's a simple update which shouldn't (meaning here "in
theory") need tons of round-trips to allocate new colors and stuff.


        Stefan


diff --git a/src/process.c b/src/process.c
index f4613be..26f26c3 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6694,10 +6694,12 @@ status_notify (struct Lisp_Process *deleting_process,
          p->update_tick = p->tick;
          /* Now output the message suitably.  */
          exec_sentinel (proc, msg);
+         if (BUFFERP (p->buffer))
+           /* In case it uses %s in mode-line-format.  */
+           bset_update_mode_line (XBUFFER (p->buffer));
        }
     } /* end for */
 
-  update_mode_lines = 24;  /* In case buffers use %s in mode-line-format.  */
   return got_some_output;
 }