From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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: Sun, 7 Apr 2024 10:24:29 +0200 Message-ID: <3ee13fbd-2ba0-4fca-b5ed-b61f1d8dc527@gmx.at> 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> <867cha37of.fsf@gnu.org> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26804"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: luangruo@yahoo.com, rahguzar@zohomail.eu, r.diaz@uam.es, rdiaz02@gmail.com, 70038@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 07 10:25:10 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 1rtNpu-0006lj-4J for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Apr 2024 10:25:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtNph-0004UT-F2; Sun, 07 Apr 2024 04:24:57 -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 1rtNpg-0004UE-AF for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 04:24:56 -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 1rtNpg-00032E-16 for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 04:24:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rtNpm-0005Jv-Lg for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 04:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Apr 2024 08:25:02 +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.171247829420397 (code B ref 70038); Sun, 07 Apr 2024 08:25:02 +0000 Original-Received: (at 70038) by debbugs.gnu.org; 7 Apr 2024 08:24:54 +0000 Original-Received: from localhost ([127.0.0.1]:41543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtNpd-0005Iu-Lz for submit@debbugs.gnu.org; Sun, 07 Apr 2024 04:24:54 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:50735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtNpb-0005Hs-5V for 70038@debbugs.gnu.org; Sun, 07 Apr 2024 04:24:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1712478272; x=1713083072; i=rudalics@gmx.at; bh=azl/FUXODUuEMKAu9UbVxALmQKN0zCIcGy3DX909WFQ=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=qo2VcTCadl4pjqzl49aXVhCP262xdvQ47TQ4QCsEyIeqEpZTcZYBhao8mlEhKpwc Hyhm3xFqDN4C50roIhHiZbcvXKutbTBS5Rbuh9zcBwR+4hxqD1+WbDFnWM76VYg9e cBxXoQ/UXUf3fGZOZJi6Zf3U+MBq0RLYOHRWBiN/Qs7SsSAEUTT/ymM6Jps65j6lQ NlJSoDZh2neBbfZOeQX/fip9J1PCyA0yMZVvNeKaCXLh8N5+B+GFXH5kVkRTf1ibZ 5BCYQQDgjflzZQNO0qKuPC9cdHwDCbhUOB8YecwxyhOhZYX0uP7wasAFy5GFQuHEj fED4qLCCsFaxoDRgFA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.44]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MDQic-1s2m1u2nlG-00ATA5; Sun, 07 Apr 2024 10:24:32 +0200 Content-Language: en-US In-Reply-To: <867cha37of.fsf@gnu.org> X-Provags-ID: V03:K1:XmOz74qz8pAaZ1NY0tFzOinuc594KZvUomhhVPdpG4/+Mt8T6Y3 ehq4iSdPC6/qiuUrqakaTT4kGpJAKCGPU+VmwwNftEZV3Qqisp7QOp+geCV1gfKtj/FRU6t Wm2clrqwz3vW80+i0jthMbJ4z7P1AjhoseTJURDS0BJSgUZGxkLOqTq5VmlFzzguZzzqU7i NG2e8vh+eg3d6KWtoXlhA== UI-OutboundReport: notjunk:1;M01:P0:PqZyfjr3/FI=;Dn67Eu6URqXoOf6ZpP7aL1C5HSe uhijt3kn5I2APrqYDqerp6VNGPF6E3YKWEiaBjzUf4Y9S4LM5QsQQikLRLjjf2I8sWHYHpU7C BPk/SH3tZPXDWTgUSa+ssiCh+uxNUc2eiUK0Y4NkahKevKf1rsTNOn3w2addgpmW9jFdZ8SgK j8bC4gPkS/0ZHq431mI2fayNLDe7ivi24xVg8YhjeT6nbhPwdZZOQYb14kVNeKuDL9hr4HOTT M+6YCs6V924XTvpCmOB7hzQ3gz63zwXwvkPkO5nsrMv0xBtKAW172YbIGvqPWbe7gQcODQlsr LBmCdJ/RYDI85HVMDl0klAMGtL94K9kZH/HcoPBsNM3LV0vsOO91ogm1hrm0pRtg4gNz6vfxz 2QVdMRFIwfJeglFZOsyjHLQ0UWoqCjICekbBMQvO9+1Ii0dP6n8pCTkT2Lb/pXmaWMTzrIy7m 9wrUZU66ybKkitCBD173LoA73UpFcU51glHNIR8oGBu7k5Qtuki1JQMgExQKFLvg1SQBG3XHJ Q4YGNWZs2IkZy78uiGElU2N45aykxRATFSi/DkwdiGcaTjTpuAgJpmXG7z69RJP1dkyBTLlur hVQMy29qEBUexrtqvPbg9QOdhaRgRh4Vz8pwgpp9SL1YUwFri9ytCxo1Jh05ayfOgXUgGVL/t VtYuZIbqKVP4LLhohHZlPFc9MRlEeDcj5Z4KXWSlJdZ2+gs3j3r1ndpy5SleAInaZoJvaB9D6 Zi3It5M9locCkJo8+70zBdRjN7QPy7Qk/f1RY93hpgcFOshp3IFRNI1DzD+Iwr3dLHK2sElV 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:282854 Archived-At: > 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, Just for the record: Here I once used a version of shrink_mini_window that went as /** Shrink mini-window W to its minimum height. */ void shrink_mini_window (struct window *w) { /* Just attempt to shrink it to zero, grow_mini_window makes sure it does not get to small. */ FRAME_WINDOWS_FROZEN (WINDOW_XFRAME (w)) = false; grow_mini_window (w, -WINDOW_PIXEL_HEIGHT (w)); } where grow_mini_window took care of the rest. But I don't call shrink_mini_window any more and so the flag remains stuck here as well. > so I > guess we should do something in minibuffer_unwind to reset that flag? Would that be sufficient? Don't we freeze also when resizing the echo area? martin