bug#57434: 28.1.91; Terminal Emacs Mac OS flickering.

[Dmitrii Kuragin via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

I also tried vim in the similar configuration (display line numbers, 2
splits, etc).

I understand that it is unreasonable to compare 2 different things, but it
doesn't show any flickering issues there.

Do we actually need to redraw the whole line if we use relative numbers or
we can just redraw the portion with line numbers?

On Mon, Aug 29, 2022 at 7:18 AM Dmitrii Kuragin <kuragin@google.com> wrote:

> I am having difficulty running a debugger.
>
> I tried gdb and signing, but it didn't work. I also tried lldb, but it
> doesn't stop on a breakpoint for whatever reason.
>
> I compiled with `-O0 -g3`, then
> ```
> lldb
> (lldb) file nextstep/Emacs.app/Contents/MacOS/Emacs
> Current executable set to
> '/Users/kuragin/Desktop/emacs/nextstep/Emacs.app/Contents/MacOS/Emacs'
> (x86_64).
> (lldb) breakpoint set -f scroll.c -l 270
> Breakpoint 1: where = Emacs`do_scrolling + 485 at scroll.c:271:11, address
> = 0x0000000100032da5
> ```
>
> But, it doesn't stop there...
>
> and I run Emacs like this:
> ```
> arch --x86_64 make configure="CFLAGS='-O0 -g3'" -j 20 &&
> nextstep/Emacs.app/Contents/MacOS/Emacs -nw
> ```
>
> I can confirm that my patch fixes the problem for me, but I am not
> confident that the issue is in the estimation cost.
>
> When I have line numbers enabled, I assume, the scrolling logic would
> always try to insert/delete/write lines. In my case it might be:
>  - Writing (Is that writing on top of the current lines?) is cheaper.
>  - Screen flickers because of the specific frequency of the terminal (or
> the way we flush the buffer).
>    For example, we insert empty lines and then the screen is updated, only
> then we add content in there and redisplay again.
>
> Potentially, some redrawing might happen inside of `ins_del_lines`?
> Instead of redrawing the whole screen, we redraw it in the middle of
> modifying it?
>
> Those are just my assumptions from reading the code.
>
> I'd appreciate any help in debugging the issue.
>
> On Sat, Aug 27, 2022 at 9:14 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Dmitrii Kuragin <kuragin@google.com>
>> > Date: Sat, 27 Aug 2022 09:01:22 -0700
>> > Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>> >       57434@debbugs.gnu.org
>> >
>> > I think I can give it a try. I just need a bit more time to set up the
>> debugger workflow, since I run GDM only once
>> > in a few years :)
>>
>> Thanks.
>>
>> > I also do not really understand the meaning of "cost" here and what
>> metrics we use to measure that. But, I'd
>> > assume it is something empirical.
>>
>> It's supposed to measure the cost of moving the text-terminal cursor
>> from one point on the screen to another.  And yes, it's heuristics.
>>
>
>
> --
> *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.

[-- Attachment #2: Type: text/html, Size: 8659 bytes --]