bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35464: [PATCH] Refactor update_window_begin and update_window_end ho


From: Alex Gramiak
Subject: bug#35464: [PATCH] Refactor update_window_begin and update_window_end hooks
Date: Sun, 28 Apr 2019 12:37:28 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> Don't know, the problem was specific to X.  I think we should leave
> the code there, the NS port has enough redisplay problems already.

It seems that it's needed (see commit 96e78d1fb) for both X and W32, so
I wouldn't be surprised if NS needs the change as well, or, at least, if
it doesn't matter for that port.

>> @@ -13145,8 +13069,8 @@ static struct redisplay_interface 
>> x_redisplay_interface =
>>      gui_clear_end_of_line,
>>      x_scroll_run,
>>      x_after_update_window_line,
>> -    x_update_window_begin,
>> -    x_update_window_end,
>> +    gui_update_window_begin,
>> +    gui_update_window_end,
>>      x_flip_and_flush,
>>      gui_clear_window_mouse_face,
>>      gui_get_glyph_overhangs,
>
> This looks like a step in the wrong direction to me: the different
> implementations are all almost completely identical, except that w32
> has a small quirk there.  So I'd say make a single function
> window_update_begin, that will be called directly (not via a hook
> pointer), and make the w32 part be an optional hook called only if
> non-NULL.

Done.

> Also, please don't add gui_* functions extracted from the *term.c
> files in xdisp.c, as that file is already too large.  Renaming
> existing functions in xdisp.c is OK, as well as adding static utility
> functions.  But for new gui_* functions that were originally in
> xterm.c etc., I'd prefer a new file, let's call it gui_term.c.

A gui_term.c might be beneficial in the future, but I'm not sure it
should be the place for RIF procedures like these. I attached an updated
patch that currently puts them in terminal.c (beside update_begin and
update_end), but I think a better place would be to put them beside
update_window in dispnew.c. WDYT?

Attachment: 0001-Refactor-update_window_begin-and-update_window_end-h.patch
Description: v2


reply via email to

[Prev in Thread] Current Thread [Next in Thread]