From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38966: 27.0.60; Assertion failure in set_cursor_from_row Date: Mon, 06 Jan 2020 21:50:51 +0200 Message-ID: <8336cse544.fsf@gnu.org> References: <497636f5-1728-1e7e-b826-8310e2a6fe13@gmx.at> <83lfqkecc6.fsf@gnu.org> <12ea3c04-249a-96da-8c88-52dcb5ca8b66@gmx.at> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="25032"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38966-done@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 06 20:51:17 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ioYPB-0006IM-MV for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 20:51:13 +0100 Original-Received: from localhost ([::1]:59262 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioYPA-0000bS-Ep for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 14:51:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56613) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioYP3-0000Zp-Fy for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 14:51:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioYP2-0007c4-86 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 14:51:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40875) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioYP1-0007bL-1F for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 14:51:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ioYP1-0006Kx-1W for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 14:51:03 -0500 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 19:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 38966 X-GNU-PR-Package: emacs Mail-Followup-To: 38966@debbugs.gnu.org, eliz@gnu.org, rudalics@gmx.at Original-Received: via spool by 38966-done@debbugs.gnu.org id=D38966.157834025124288 (code D ref 38966); Mon, 06 Jan 2020 19:51:02 +0000 Original-Received: (at 38966-done) by debbugs.gnu.org; 6 Jan 2020 19:50:51 +0000 Original-Received: from localhost ([127.0.0.1]:46839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioYOo-0006Jf-4D for submit@debbugs.gnu.org; Mon, 06 Jan 2020 14:50:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioYOn-0006JN-78 for 38966-done@debbugs.gnu.org; Mon, 06 Jan 2020 14:50:49 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioYOh-0007Hl-QX; Mon, 06 Jan 2020 14:50:43 -0500 Original-Received: from [176.228.60.248] (port=3506 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioYOh-0004nX-95; Mon, 06 Jan 2020 14:50:43 -0500 In-reply-to: <12ea3c04-249a-96da-8c88-52dcb5ca8b66@gmx.at> (message from martin rudalics on Mon, 6 Jan 2020 20:06:21 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174265 Archived-At: > Cc: 38966@debbugs.gnu.org > From: martin rudalics > Date: Mon, 6 Jan 2020 20:06:21 +0100 > > > I don't expect to have a window that has no lines showing text. I > > believe we don't allow creation/resizing of windows to such a small > > size? If that's not guaranteed, I'm okay with adding an assertion > > somewhere, but that would be a separate problem: we never expected > > such a calamity even before tab-lines were added. > > We did. OK, let me rephrase: _I_ didn't, okay? IOW, the display code doesn't, and AFAIR never did. (For some reason I seem to make people angry today, and you seem to be one of them. Apologies -- I don't know for what.) > Try with emacs 26 loading my old test-popup-2.el (attached once > more). Type C-x 2 and make the lower window as low as you can. Now > hit F2. The lower window shows no text. Why is such a window useful? I thought we had a minimum window height beyond which we didn't allow to resize windows. Isn't that true anymore? > I plan a slight modification that would allow the minibuffer window to > shrink to zero lines whenever it's not used. OTOH, zero size "normal" > windows would allow to show the minibuffer window in a frame that can > acommodate only one or two lines. All I'm saying is that making the display code prepared to deal with such windows might take more changes, and this would be a separate issue, suitable for master, not for the release branch. OK? > > If we don't call set_cursor_from_row, we will not have a cursor > > displayed where it should be, which is a display bug in and of itself. > > Isn't that statement overly conservative? Sooner or later, Emacs will > at least have to allow a mode where the region is not destroyed when a > window is scrolled, allowing the cursor to disappear from the visible > part of its buffer. That's not the same situation. If point is not in the window, it's OK not to display the cursor. But I'm talking about a situation where point _is_ in the window. > > Sorry, but that ship sailed a long time ago. You will have to make do > > with the comments in dispextern.h, which document this weirdness. > > Which comment? This one: /* True means row is a mode or header/tab-line. */ bool_bf mode_line_p : 1; > In either case, rest assured that ordinary people will > have considerable troubles understanding code like the proposed > > if (row->tab_line_p) > ++row; > if (row->mode_line_p) > ++row; I added comments explaining what's going on. > Notwithstanding my concerns, the patch fixes the bug here. Thanks, pushed to the emacs-27 branch, and closing the bug.