Package: emacs;
Reported by: Dmitrii Kuragin <kuragin <at> google.com>
Date: Fri, 26 Aug 2022 16:55:02 UTC
Severity: normal
Found in version 28.1.91
View this message in rfc822 format
From: Dmitrii Kuragin <kuragin <at> google.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 57434 <at> debbugs.gnu.org Subject: bug#57434: 28.1.91; Terminal Emacs Mac OS flickering. Date: Tue, 30 Aug 2022 09:34:24 -0700
[Message part 1 (text/plain, inline)]
On Tue, Aug 30, 2022 at 9:19 AM Dmitrii Kuragin <kuragin <at> google.com> wrote:
> `tty->TS_ins_line` (al) is supprted.
> `tty->TS_ins_multi_lines` (AL) is supprted.
> `tty->TS_del_line` (dl) is supprted.
> `tty->TS_del_multi_lines` (DL) is supprted.
>
> to verify that I used `tput <cap_name>`.
>
> I think, that is sufficient for `tty->line_ins_del_ok` to be true, but fo
> completeness:
>
> `tty->TS_fwd_scroll` (sf) is supprted.
> `tty->TS_rev_scroll` (sr) is supprted.
>
>
> `tty->TS_set_window` (wi) is NOT supprted.
> `tty->TS_set_scroll_region` (cs) is supprted.
> `tty->TS_set_scroll_region_1` (cS) is NOT supprted.
>
> BUt I do not know how to verify `tty->Wcm->cm_abs`.
>
>
> ```
> tty->scroll_region_ok
> = (tty->Wcm->cm_abs
> && (tty->TS_set_window || tty->TS_set_scroll_region ||
> tty->TS_set_scroll_region_1));
> ```
>
>
> ```
> tty->line_ins_del_ok
> = (((tty->TS_ins_line || tty->TS_ins_multi_lines)
> && (tty->TS_del_line || tty->TS_del_multi_lines))
> || (tty->scroll_region_ok
> && tty->TS_fwd_scroll && tty->TS_rev_scroll));
> ```
>
> BTW, here's a video with what I have with "-Q", it still flickers:
> https://drive.google.com/file/d/1Yq2QFWHR6CHkoM4buEokV6p3a1uOI8ao/view?usp=sharing
>
> On Tue, Aug 30, 2022 at 4:09 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 57434 <at> debbugs.gnu.org
>> > Date: Tue, 30 Aug 2022 08:09:33 +0200
>> >
>> > Dmitrii Kuragin <kuragin <at> google.com> writes:
>> >
>> > > So far:
>> > > ```
>> > > :~/Desktop% tput al; echo $?
>> > > 0
>> > > :~/Desktop% tput AL; echo $?
>> > > 1%dL0
>> > > :~/Desktop% tput dl; echo $?
>> > > 0
>> > > :~/Desktop% tput DL; echo $?
>> > > 1%dM0
>> > > :~/Desktop% tput sf; echo $?
>> > >
>> > > 0
>> > > 0~/Desktop% tput sr; echo $?
>> > > :~/Desktop% tput wi; echo $?
>> > > tput: unknown terminfo capability 'wi'
>> > > 4
>> > > :~/Desktop% tput cs; echo $?
>> > > %p1%d;%p2%dr0
>> > > :~/Desktop% tput cS; echo $?
>> > > tput: unknown terminfo capability 'cS'
>> > > 4
>> > > ```
>> >
>> > Same here.
>>
>> Thanks.
>>
>> But I'm quite confused by all of this, because you don't show all the
>> relevant capabilities, AFAICT.
>>
>> We have in term.c:
>>
>> tty->scroll_region_ok
>> = (tty->Wcm->cm_abs
>> && (tty->TS_set_window || tty->TS_set_scroll_region ||
>> tty->TS_set_scroll_region_1));
>>
>> tty->line_ins_del_ok
>> = (((tty->TS_ins_line || tty->TS_ins_multi_lines)
>> && (tty->TS_del_line || tty->TS_del_multi_lines))
>> || (tty->scroll_region_ok
>> && tty->TS_fwd_scroll && tty->TS_rev_scroll));
>>
>> Please try all of the relevant capabilities and tell me which ones are
>> supported and which aren't. (Please also mention both the capability
>> string and its term.c flag name, so that I shouldn't need to jump
>> back-and-forth in the source looking up each one to understand what it
>> means.)
>>
>> Then we have in dispnew.c:
>>
>> /* If we cannot insert/delete lines, it's no use trying it. */
>> if (!FRAME_LINE_INS_DEL_OK (f))
>> inhibit_id_p = 1;
>> [...]
>> /* Try doing i/d line, if not yet inhibited. */
>> if (!inhibit_id_p && i < desired_matrix->nrows)
>> force_p |= scrolling (f);
>>
>> Which means that 'scrolling', and thus 'scrolling_1' (where the
>> problem happens) will not be called if the line_ins_del_ok flag is not
>> set.
>>
>> Furthermore, we have in scrolling_1:
>>
>> if (FRAME_SCROLL_REGION_OK (frame))
>> {
>> calculate_direct_scrolling (frame, matrix, window_size,
>> unchanged_at_bottom,
>> draw_cost, old_draw_cost,
>> old_hash, new_hash, free_at_end);
>> do_direct_scrolling (frame, frame->current_matrix,
>> matrix, window_size, unchanged_at_top);
>> }
>> else
>> {
>> calculate_scrolling (frame, matrix, window_size,
>> unchanged_at_bottom,
>> draw_cost, old_hash, new_hash,
>> free_at_end);
>> do_scrolling (frame,
>> frame->current_matrix, matrix, window_size,
>> unchanged_at_top);
>> }
>>
>> which means do_direct_scrolling (which causes the problem) will not be
>> called if the terminal's scroll_region_ok flag is not set.
>>
>> So given all of this, can you tell whether Emacs does TRT here? That
>> is:
>>
> Sorry, what does TRT mean?
>
>> . are all the capabilities that are supposed to be available for
>> these two flags are indeed available?
>>
> How can I verify it?
> . do we need to check any additional capabilities, which are in fact
>> used in the problematic scenario, but not tested as part of
>> setting these two flags?
>>
> It makes sense to me, but since the output is still correct after the
glitch, doesn't it mean that capabilities work correctly?
>
>> Assuming that Emacs does TRT, i.e. sets the flags correctly and uses
>> only the capabilities that are conditions for the flags set, then the
>> next important question is: why doesn't Gerd see the flickering on a
>> very similar system and the same terminal emulator? Is it possible
>> that some other local software configuration on Dmitrii's machine
>> causes this, directly or indirectly? E.g., Dmitrii, do you have some
>> display-related software/driver that has some "optimization" features
>> turned on? If so, can you turn them off and try again?
>>
>> Thanks.
>>
>
>
> --
> *If you get an email from me outside of the 9-5 it is *not* because I'm
> always on or expect an immediate response from you; it is because of work
> flexibility
> <http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
> . Evening and weekend emails are a sign I allocated some regular working
> hours for other things (such as family, gym, friends,...). And I encourage
> you to feel free to do the same.
>
>
--
*If you get an email from me outside of the 9-5 it is *not* because I'm
always on or expect an immediate response from you; it is because of work
flexibility
<http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
. Evening and weekend emails are a sign I allocated some regular working
hours for other things (such as family, gym, friends,...). And I encourage
you to feel free to do the same.
[Message part 2 (text/html, inline)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.