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

[Ken Raeburn <raeburn@permabit.com>]

> On Sep 7, 2015, at 21:29, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> increments face_change_count. If face_change_count is nonzero, init_iterator
>> (which gets called on every frame, thanks to prepare_menu_bars calling
>> x_consider_frame_title, and perhaps other ways) will call
> 
> I think here we should arrange to only call init_iterator on those
> frames that are being redisplayed.
> 
> IIUC this refreshes all frames because
> 
>  bool all_windows = windows_or_buffers_changed || update_mode_lines;
> 
> sets all_windows to true.  Can you check the actual value of
> windows_or_buffers_changed and update_mode_lines to see which one causes
> it to be true, and where it was set (each place they're set uses
> a different value).  Then we can see if this place where it's set can be
> modified so it explicitly marks the few frames/windows that actually
> need to be refreshed, rather than asking for a "global" redisplay.

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.

With a hardware watchpoint I see windows_or_buffers_changed getting set to 2 (wset_redisplay calls redisplay_other_windows), 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, and finally 0 (redisplay_internal); the value of update_mode_lines changed just a few times, 0 to 2 (bset_update_mode_line) 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).

All of that was just in the process of creating the second frame via emacsclient, the server interaction being responsible for the status_notify call.

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.

Ken