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: 3256 bytes --]

Thank you Eli and Gerd!

Now I can run the debugger!

> What exactly do you mean by "scrolling"? which keys or commands do you
> invoke?

I use C-n/C-p (next-line).

> Why are you setting the breakpoint on that line?

I am trying to debug the current version w/o my patch, but probably I just
messed something up. Let's ignore this I got better results.

I am using `breakpoint set -f scroll.c -l 697`.

Currently, when I have 2 panes and I have the right pane with content on it
`do_direct_scrolling` doesn't go into the first condition in the loop. So,
It doesn't stop in the debugger. But, when I open the scratch buffer which
has only few lines and I try to scroll in the left pane on the lines where
the right buffer doesn't have any content because there are only few lines
in the buffer it stops:
```
(lldb) p *p
(matrix_elt) $3 = {
  writecost = 35356
  insertcost = 34958
  deletecost = 35357
  insertcount = 97
  deletecount = 1
  writecount = 1
}
```

... just because the cost of insertion is lower than the write cost. Then I
set the breakpoint into different line set the right window a buffer with
content:
```
(lldb) breakpoint set -f scroll.c -l 688
```
So, I see
```
(lldb) p *p
(matrix_elt) $4 = {
  writecost = 54426
  insertcost = 54996
  deletecost = 54735
  insertcount = 1
  deletecount = 8
  writecount = 148
}
```

Insert and delete cost are greater than write cost.

I see the behavior as a correct one (at least by design), but when we do
insert instead of writing the terminal flickers. Do we need to adjust some
numbers or do we have to understand the reason why we flush the content?



On Mon, Aug 29, 2022 at 10:14 AM Gerd Möllmann <gerd.moellmann@gmail.com>
wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> but then Emacs gets stuck.  Maybe it's a bug in LLDB.
> >
> > Is this specific to -nw sessions?  If so, maybe LLFB has a command
> > similar to GDB's "set new-console 1"?  That's what I do to make sure
> > the console used by GDB doesn't get messed up by the terminal setup
> > used by Emacs to prepare the terminal for itself.  Like this:
> >
> >   $ gdb ./emacs
> >   ...
> >   (gdb) set new-console 1
> >   (gdb) r -Q -nw
> >
> > Then Emacs gets a new console for its TTY frame, while GDB retains its
> > original console.
>
> That was an excellent hint, thanks!
>
> The following seems to work:
>
> cd src
> lldb emacs
> b main
> process launch --tty -- -nw -Q
>
> LLDB then opens a new terminal window with a working Emacs in it,
> and stops at main in the original window.  One can interrupt the running
> Emacs by issuing
>
> process interrupt
>
> in the LLDB terminal window and so on.  The process launch --tty instead
> of run is key here.
>
>
>

-- 
*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: 5877 bytes --]