From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitrii Kuragin via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#57434: 28.1.91; Terminal Emacs Mac OS flickering. Date: Mon, 29 Aug 2022 11:24:45 -0700 Message-ID: References: <83edx1znjl.fsf@gnu.org> <83czclzms4.fsf@gnu.org> <83ler7vx3o.fsf@gnu.org> Reply-To: Dmitrii Kuragin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000074f0d705e765618c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8235"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 57434@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 29 20:26:16 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSjSh-0001xV-Dt for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Aug 2022 20:26:15 +0200 Original-Received: from localhost ([::1]:42668 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oSjSg-0005cI-AB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Aug 2022 14:26:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32904) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSjSU-0005aB-Gq for bug-gnu-emacs@gnu.org; Mon, 29 Aug 2022 14:26:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44055) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oSjSU-0005cP-84 for bug-gnu-emacs@gnu.org; Mon, 29 Aug 2022 14:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oSjSU-0002HS-3n for bug-gnu-emacs@gnu.org; Mon, 29 Aug 2022 14:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitrii Kuragin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Aug 2022 18:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57434 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57434-submit@debbugs.gnu.org id=B57434.16617975048690 (code B ref 57434); Mon, 29 Aug 2022 18:26:02 +0000 Original-Received: (at 57434) by debbugs.gnu.org; 29 Aug 2022 18:25:04 +0000 Original-Received: from localhost ([127.0.0.1]:33804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSjRY-0002G6-43 for submit@debbugs.gnu.org; Mon, 29 Aug 2022 14:25:04 -0400 Original-Received: from mail-yw1-f171.google.com ([209.85.128.171]:38888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSjRV-0002FV-W0 for 57434@debbugs.gnu.org; Mon, 29 Aug 2022 14:25:02 -0400 Original-Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-3321c2a8d4cso217297027b3.5 for <57434@debbugs.gnu.org>; Mon, 29 Aug 2022 11:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=olpnyl9SdDU+6NC9cwh4SYH0uEmVEJCFGYA3mngC0EI=; b=ERgTkzCV+gSvUiXqYWO9fU5x/LssUOxA+/oneybjqZ0FyT1fsOxi8qV7ZbVDptwFK1 bl36cTjTcBbefz2bRZIr7fuKmZZ1tx7q6J/zKPuTWFCnz9L12yaWu8VE9gN5UaPPEoiU VAaQDB+n5nmiZCm8tz4MkfKHxaSexcbt+HuZMJEaaB2NPFjgqDRhM0xqZ6aYDQbBxrau wjvfEBaMN0C5tG9sFGTWZfFvt7iO8Mq34fCK2OQB5FFbMxCflFHoa2beFlUX2uwiXaXT LI0jBh4NlHyrjy7crJyveEgSppaDIHsGKPZmv8y3pcRJwf8SVjmYnv7nr6Qrl9ORqVbB CpZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=olpnyl9SdDU+6NC9cwh4SYH0uEmVEJCFGYA3mngC0EI=; b=7pZAjMhv4mwnj+ms5C+zFvvCRedKaPYdQx1J2h+z7fdfkVNI7YZMfm3rD76C2o+/n5 T8x8gN+FDSAJlbX/c6ac1CJaoVoYanY9N+SUnXHsnfQJcxZvpzps+nNRyEoL/oE7nW1t MPXM2PHYU9kGUmgWnivlVDehuFXTCeW9agOgElwQCNmN+RpngKp8pX4vPz2hBk22EqLU Y6xOtPetv2Hb/WdTwFpkJVe92gPiATrwfiuVV/lg3wGRkj2VwK0fmaVLuiNDAwBsBIP+ sMGWO4qh/M20Oee0Bh2X7dzDYprgeAylZxCPNrT5ILX16MOrdjnx1kgaHqcwRn75ql7X 1goA== X-Gm-Message-State: ACgBeo1QWy52UITx48XGUmV5CvCsx5CbPeA35e1bYAgwKIqlY7xwcMPW 3qXJAzskpubyrZTl/OhazVqeUJX7sQpLa6qksEMaDg== X-Google-Smtp-Source: AA6agR5IoKpR+qNVD6h6f2kq2nq0UyQx9me/tif3BzpetqaAhlYJBY4DLAw5mgu0CWyLEEmhDO8X/tkSfWU0yaH/6cU= X-Received: by 2002:a81:b043:0:b0:340:df78:9318 with SMTP id x3-20020a81b043000000b00340df789318mr7932523ywk.215.1661797496281; Mon, 29 Aug 2022 11:24:56 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241061 Archived-At: --00000000000074f0d705e765618c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D { writecost =3D 35356 insertcost =3D 34958 deletecost =3D 35357 insertcount =3D 97 deletecount =3D 1 writecount =3D 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 =3D { writecost =3D 54426 insertcost =3D 54996 deletecost =3D 54735 insertcount =3D 1 deletecount =3D 8 writecount =3D 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=C3=B6llmann wrote: > Eli Zaretskii 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. > > > --=20 *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 . 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. --00000000000074f0d705e765618c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Eli and=C2=A0Gerd!

Now I can run the d= ebugger!

>=C2=A0What exactly do you mean by "scrolling"? whic= h keys or commands do you
> invoke?

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

>=C2=A0Why are you setting the breakpoint on th= at line?

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

I am using `break= point 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 debug= ger. 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:<= br>```
(lldb) p *p
(matrix_elt) $3 =3D {
=C2=A0 writecost =3D 3535= 6
=C2=A0 insertcost =3D 34958
=C2=A0 deletecost =3D 35357
=C2=A0 i= nsertcount =3D 97
=C2=A0 deletecount =3D 1
=C2=A0 writecount =3D 1}
```

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

Insert and delete cost are greater=C2=A0than 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=C3=B6llmann <gerd.moellmann@gmail.com> w= rote:
Eli Zarets= kii <eliz@gnu.org&= gt; writes:

>> but then Emacs gets stuck.=C2=A0 Maybe it's a bug in LLDB.
>
> Is this specific to -nw sessions?=C2=A0 If so, maybe LLFB has a comman= d
> similar to GDB's "set new-console 1"?=C2=A0 That's w= hat I do to make sure
> the console used by GDB doesn't get messed up by the terminal setu= p
> used by Emacs to prepare the terminal for itself.=C2=A0 Like this:
>
>=C2=A0 =C2=A0$ gdb ./emacs
>=C2=A0 =C2=A0...
>=C2=A0 =C2=A0(gdb) set new-console 1
>=C2=A0 =C2=A0(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.=C2=A0 One can interrupt the runni= ng
Emacs by issuing

process interrupt

in the LLDB terminal window and so on.=C2=A0 The process launch --tty inste= ad
of run is key here.




--
*If you get an email from me outside of the 9-5 it is=C2= =A0not=C2=A0because I'm always on or expect an immediate respons= e from you; it is because of=C2=A0<= a href=3D"http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-= better-work-life-balance.html" style=3D"color:rgb(17,85,204)" target=3D"_bl= ank">work flexibility.=C2=A0=C2=A0= Evening and weekend emails are a sign I allocated some regular working hour= s for other things (such as family, gym, friends,...).=C2=A0 And I encourag= e you to feel free to do the same.

--00000000000074f0d705e765618c--