From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts Date: Sat, 06 Apr 2024 17:08:32 +0300 Message-ID: <867cha37of.fsf@gnu.org> References: <87ttkrl8w1.fsf@gmail.com> <86zfuihp7t.fsf@gnu.org> <87bk6yl4hu.fsf@gmail.com> <8734sal2bc.fsf@gmail.com> <87wmpm2rd7.fsf@zohomail.eu> <86bk6m3c20.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="351"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, rahguzar@zohomail.eu, r.diaz@uam.es, rdiaz02@gmail.com, 70038@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 06 16:09:07 2024 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 1rt6jD-000ARn-Ff for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Apr 2024 16:09:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rt6j6-00031s-U5; Sat, 06 Apr 2024 10:09:00 -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 1rt6j4-00031I-Nl for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 10:08:59 -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 1rt6j4-0003Dn-F5 for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 10:08:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rt6jA-0002km-BL for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 10:09:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Apr 2024 14:09:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70038 X-GNU-PR-Package: emacs Original-Received: via spool by 70038-submit@debbugs.gnu.org id=B70038.171241253410496 (code B ref 70038); Sat, 06 Apr 2024 14:09:04 +0000 Original-Received: (at 70038) by debbugs.gnu.org; 6 Apr 2024 14:08:54 +0000 Original-Received: from localhost ([127.0.0.1]:40522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rt6iz-0002jD-OT for submit@debbugs.gnu.org; Sat, 06 Apr 2024 10:08:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rt6iv-0002ix-CE for 70038@debbugs.gnu.org; Sat, 06 Apr 2024 10:08:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rt6ih-0003Al-7M; Sat, 06 Apr 2024 10:08:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=aYVecO7f3AymmYbAIzzX8xg0Tv14D1QWi0Cp2QRsz+Q=; b=YNLn78knBc/k kuooFHLInc884uh6z2lYao5BAhcMwx+kH3MkhreaP1OsmoRhmE67ApM/kahuDsISBqXo7q6SY3au0 b370azIXAlxQPGvwNKa449vRPMu/GAyOnqQKmauHq48hOWyVBX/d032Vl0gv/YW7ojLFdoGMCRlI9 QhA/xFixCvLp1fICUDAl651OmfhV6I1k1zSLx9uaByvvuzpggomKxJzLnCv9VCtHSwLpy9bjoOjPF CjmREthXLGN3NqoLqEsCXv9C41DYxwid+Lw5+e5lmL7Gcgw3w5fR5cAJwaMGMoc2K9alz7Yh3QW+x 9iIjtBVc4aanq9ocza7xbA==; In-Reply-To: <86bk6m3c20.fsf@gnu.org> (message from Eli Zaretskii on Sat, 06 Apr 2024 15:33:59 +0300) 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:282793 Archived-At: > Cc: Rahguzar , rdiaz02@gmail.com, 70038@debbugs.gnu.org > Date: Sat, 06 Apr 2024 15:33:59 +0300 > From: Eli Zaretskii > > > From: Rahguzar > > Cc: Eli Zaretskii , 70038@debbugs.gnu.org > > Date: Thu, 28 Mar 2024 18:24:32 +0100 > > > > I can also reproduce this now! And vertico mode can be replaced with the > > builtin icomplete-vertical-mode. So, the following recipe starting with > > emacs -Q works for me: > > > > 1) Paste > > (let ((height (/ (* 2 (frame-pixel-height)) 15))) > > (icomplete-vertical-mode) > > (defun pin-vscroll-down (win) > > (set-window-vscroll win (/ height 2) t)) > > (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height)) > > (image2 (create-image "~/Downloads/image2.png" nil nil :height height)) > > (image3 (create-image "~/Downloads/image3.png" nil nil :height height))) > > (with-current-buffer (get-buffer-create "*image-scroll-test*") > > (insert " \n \n \n \n \n \n") > > (put-image image1 1) > > (put-image image2 5) > > (put-image image3 9) > > ;; With larger image sizes (goto-char 3) > > ;; also consistently triggers the problem. > > (goto-char 11) > > (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t)) > > (split-window-right) > > (other-window 1) > > (switch-to-buffer "*image-scroll-test*"))) > > > > into scratch buffer. > > > > 2) Evaluate the form above using `C-M-x`. > > > > 3) Type M-x t > > > > 4) Wait till minibuffer expands to show completions, then type `C-g` to > > quit minibuffer. > > > > 5) Typing `C-x 0` results in the window with images losing vscroll. > > Po Lu, I'm looking at this part of redisplay_window: > > force_start: > > /* Handle case where place to start displaying has been specified, > unless the specified location is outside the accessible range. */ > if (w->force_start) > { > /* We set this later on if we have to adjust point. */ > int new_vpos = -1; > > w->force_start = false; > > /* The vscroll should be preserved in this case, since > `pixel-scroll-precision-mode' must continue working normally > when a mini-window is resized. (bug#55312) */ > if (!w->preserve_vscroll_p || !window_frozen_p (w)) <<<<<<<<<<<<<<< > w->vscroll = 0; > > w->preserve_vscroll_p = false; > w->window_end_valid = false; > > where you added the condition for resetting w->vscroll in commit > fd8eaa72a61, and I'm thinking that perhaps the condition should be > > if (!w->preserve_vscroll_p && !window_frozen_p (w)) > > instead? If not, can you explain why we use OR and not AND there? > > Ramon, if you replace "||" with "&&" in the above condition, does the > problem go away for you also when you change fonts, as you described > in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70038#29 ? There's one more aspect of this that bothers me: when we resize the mini-window, we set the frame's frozen_window_starts flag, but we seem to never reset it. Martin, can you help out here? I don't see shrink_mini_window being called with non-zero DELTA anywhere, including when the mini-window is exited and is resized to its normal one-line height. Instead, this resizing is performed by restore_window_configuration, called from read_minibuf, but I don't see FRAME_WINDOWS_FROZEN being reset anywhere there. I don't think it's correct for us to leave the frame's frozen_window_starts flag set forever once it was raised, so I guess we should do something in minibuffer_unwind to reset that flag?