From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.bugs Subject: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' Date: Sat, 4 Nov 2023 00:23:30 +0100 Message-ID: References: <8334xm7jsm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008083c6060947cbdc" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19767"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66922@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 04 00:24:54 2023 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 1qz3X3-0004qX-L0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Nov 2023 00:24:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qz3We-000489-D0; Fri, 03 Nov 2023 19:24:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qz3Wc-00047u-Dk for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 19:24:26 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qz3Wc-0007Tq-51 for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 19:24:26 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qz3XB-0004jG-MZ for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 19:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 23:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66922 X-GNU-PR-Package: emacs Original-Received: via spool by 66922-submit@debbugs.gnu.org id=B66922.169905386718126 (code B ref 66922); Fri, 03 Nov 2023 23:25:01 +0000 Original-Received: (at 66922) by debbugs.gnu.org; 3 Nov 2023 23:24:27 +0000 Original-Received: from localhost ([127.0.0.1]:60034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz3Wc-0004iH-DV for submit@debbugs.gnu.org; Fri, 03 Nov 2023 19:24:26 -0400 Original-Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:52726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz3Wa-0004hz-2v for 66922@debbugs.gnu.org; Fri, 03 Nov 2023 19:24:24 -0400 Original-Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2c503da4fd6so34966771fa.1 for <66922@debbugs.gnu.org>; Fri, 03 Nov 2023 16:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699053822; x=1699658622; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JS1mVLgL+BVYDKcHqKZ5gjeVKLWBm2B0H451IryH3qI=; b=Rusu3de5xDErYr26AHl2xMmjwLxdCBTqeEso/dHTkI1oTsY7lG776LLC629UKuRB+N MwrlKDkmkXvGdS1ifS/wQQ+o48+RRb6BuwKmYki29I4hnazIaKBMXuLxsD3O+8uOt/hw +4LeOftmxikCuvju2fc/BThRZjwPCgAiDE2ZaqHKiCr6oq7v4DM/G3lBITwhMu5sRNX5 Ron5JXK9X8KAborza8agSvWT7jO2Y7TvygugjLAHHAH5P1J7AgTk/LksWZd2TC9bYIqm NJQi94gPfRb+sghQ3Pai+ZDj9pqI7fr+iNNud73w4iuVz3FV5N1sr3wzdTGaiuG31V82 kKTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699053822; x=1699658622; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JS1mVLgL+BVYDKcHqKZ5gjeVKLWBm2B0H451IryH3qI=; b=XgGtqYRjxt+GF+I45fdHwwj6hURc0DNdf6RC3tDTDFKQCZt0ojckpM8piDUIt/vmS7 N9oZLVqo0cl0ZNjicCOX44hYGDQOYwckJ9klWaHl7M+uFq08wr7yxRAtoY4udpmrpXOM XMlmlYi2BLU9JNOSvLYgv/UR2hSHQDz5r+GxFXydhMDN2vxSI9hIQ+7kJd4Sm06knRpz pfYd+DfiH0VHsb+D6RvM1wugEAvbTnKK4/gUKCSnw1ZLHagUWSi0HwfP+TFR8gG9b1mV D2ZE0ASBbCiSYbknE1QaHxrZZU4J+sHH7YvWi556MOCE1yt78D/uZp743zaJTMWNwL2W CMYQ== X-Gm-Message-State: AOJu0YwXG1VyS1eOmCDPJ0sTsjQd4YJ3k15FxhBkqJQFlU6swHQQdk39 YYamKmoueowJInQNdvShmoOXTXGNznqClJUZ8fE= X-Google-Smtp-Source: AGHT+IHbu1GgZ5GAaioG6y5mg515lXhM7X4ZWlVwdvwxsCS4QWoZmOhlmyFvb8vSDmMqbptptKhqT+H2WXha6kqfjcI= X-Received: by 2002:a05:651c:39a:b0:2c5:ee7:b322 with SMTP id e26-20020a05651c039a00b002c50ee7b322mr17691293ljp.18.1699053821787; Fri, 03 Nov 2023 16:23:41 -0700 (PDT) In-Reply-To: <8334xm7jsm.fsf@gnu.org> 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273731 Archived-At: --0000000000008083c6060947cbdc Content-Type: text/plain; charset="UTF-8" (Sorry, I used the wrong reply button) Sorry Eli, I don't know what you mean here. Over here the problem does occur also in the GUI, and I am using the print to 'external-debugging-output' because the lwarn is what causes the problem. I explained in the bug report that the window-start does not get updated when including the lwarn after the forced redisplay (the point is at 11, but window-start is still at 1). (Also obviously, I can not use a normal print/message, when 'investigating' redisplay issues) The documentation says that redisplay should recalculate the window-start, and that by using force-window-update, we can ensure that some buffer or window gets redisplayed on the next redisplay. Now if you evaluate the code, from the bug report in GUI emacs, and look at the last output printed to the terminal, it shows that the window-start is still at 1, while it should be at 11, because I applied the 'force-window-update' incl. the redisplay after the (goto-char 11). Is there something I am not understanding correctly? Or could I consider it a bug in the documentation? As far as I know, I checked the documentation and the behavior quite rigidly. On Fri, 3 Nov 2023 at 19:50, Eli Zaretskii wrote: > > From: dalanicolai > > Date: Fri, 3 Nov 2023 19:07:47 +0100 > > > > I was trying to debug my 'image roll' package, that provides a 'virtual > > scroll' for displaying documents (i.e. books), when I encountered the > > following 'bug'. To reproduce it from emacs -Q, just evaluate the > > following code and press `C-c e`; note that relevant debugging output > > will be printed to the terminal: > > The problem only happens in "emacs -nw", not on a GUI frame. And I > wonder why you consider this a bug. I think external-debugging-output > is documented to print to stderr, so the "mess-up" is expected. I'd > say "don't do that". > --0000000000008083c6060947cbdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Sorry, I used the wrong reply button)

=
Sorry Eli, I don't know what you mean here. Over here the pr= oblem does
occur also in the GUI, and I am using the print to
'ex= ternal-debugging-output' because the lwarn is what causes the
proble= m. I explained in the bug report that the window-start does not
get upda= ted when including the lwarn after the forced redisplay (the
point is at= 11, but window-start is still at 1).

(Also obviously, I can not use= a normal print/message, when
'investigating' redisplay issues)<= br>
The documentation says that redisplay should recalculate the
wind= ow-start, and that by using force-window-update, we can ensure
that some= buffer or window gets redisplayed on the next redisplay.

Now if you= evaluate the code, from the bug report in GUI emacs, and
look at the la= st output printed to the terminal, it shows that the
window-start is sti= ll at 1, while it should be at 11, because I
applied the 'force-wind= ow-update' incl. the redisplay after the
(goto-char 11).

Is t= here something I am not understanding correctly? Or could I
consider it = a bug in the documentation? As far as I know, I checked
the documentatio= n and the behavior quite rigidly.

On Fri, 3 Nov 2023 at 19:50, Eli Zar= etskii <eliz@gnu.org> wrote:
<= /div>
> From: dalanicol= ai <dalanicol= ai@gmail.com>
> Date: Fri, 3 Nov 2023 19:07:47 +0100
>
> I was trying to debug my 'image roll' package, that provides a= 'virtual
> scroll' for displaying documents (i.e. books), when I encountered = the
> following 'bug'. To reproduce it from emacs -Q, just evaluate = the
> following code and press `C-c e`; note that relevant debugging output<= br> > will be printed to the terminal:

The problem only happens in "emacs -nw", not on a GUI frame.=C2= =A0 And I
wonder why you consider this a bug.=C2=A0 I think external-debugging-output=
is documented to print to stderr, so the "mess-up" is expected.= =C2=A0 I'd
say "don't do that".
--0000000000008083c6060947cbdc--