[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11822: 24.1; emacsclient terminal mode captures escape characters as
From: |
Ken Raeburn |
Subject: |
bug#11822: 24.1; emacsclient terminal mode captures escape characters as text |
Date: |
Tue, 8 Sep 2015 02:53:41 -0400 |
> 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
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/07
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Stefan Monnier, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/09
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/10