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#75352: 29.4; end-of-buffer is buggy after set-mark-command with some fonts Date: Sat, 04 Jan 2025 22:00:36 +0200 Message-ID: <86ed1ibb8b.fsf@gnu.org> References: <87y0zqvfct.fsf@qaa.vinc17.org> <8634hyd4t7.fsf@gnu.org> <20250104192504.GB2167271@qaa.vinc17.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31525"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75352@debbugs.gnu.org To: Vincent Lefevre Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 04 21:01:19 2025 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 1tUAKk-00084P-SQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 21:01:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUAKY-00051g-NT; Sat, 04 Jan 2025 15:01:06 -0500 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 1tUAKU-000507-C8 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 15:01:02 -0500 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 1tUAKU-0000K7-3J for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 15:01:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=oInpXr7ScDDA52+7sqvgD2Z7IXxtIb577FQwGDHkOV0=; b=uCfL7xj/Y7UccmnE28BuTyvEGQn+PVGxxf4vNCQYSbETj7xaOZw1f+sIqCH4EvIyJ3IoR+MHKur83xuTVNmVxUhM3chJUl+kFHRoOOG6yH5peXY1q/IjrQHQk8uwXqnfE4TlNVkHYmxsJ4gHCMJvTIO/wqPrMT/c314g74BMzfUP5XLZlgtGGD5u4dYleoO7h7KFlMgweXu3od/0baY4MwajpTxmN8g6RqBDEvNRalJT8aQTrLTjpckwyxnHuiRWFQXz5lPqXqZ+CzhFP9H6TgcHXKRpGHsYqUVteFznutyq0UsvhpyrPYdog2ffLToPcbcuLXPXBT4G2HWLGF0ATw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUAKT-00023K-TH for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 15:01:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2025 20:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75352 X-GNU-PR-Package: emacs Original-Received: via spool by 75352-submit@debbugs.gnu.org id=B75352.17360208567866 (code B ref 75352); Sat, 04 Jan 2025 20:01:01 +0000 Original-Received: (at 75352) by debbugs.gnu.org; 4 Jan 2025 20:00:56 +0000 Original-Received: from localhost ([127.0.0.1]:57514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUAKM-00022m-Uq for submit@debbugs.gnu.org; Sat, 04 Jan 2025 15:00:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35504) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUAKK-00022M-UK for 75352@debbugs.gnu.org; Sat, 04 Jan 2025 15:00:53 -0500 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 1tUAKE-0000Ik-MB; Sat, 04 Jan 2025 15:00:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=oInpXr7ScDDA52+7sqvgD2Z7IXxtIb577FQwGDHkOV0=; b=gBhV8Fzb8Xl9+H6PekQ/ I0lQtSeqAkUx8L2sl9fyimNhN+FrpOWzCfQAfQqmEBdknr3g9GIzihdEDRfjpkWhH6vReCfYEYCRZ UdEZ6ZZTBtRkfkDS+wQjMDhyY2e7NaFgBD4beUq0QQ4VPHETqftIjwtBeN6AMbhXovwpFY2taJ8/5 cJJ1It9GIrW/V25ksl3RkFPoVWIMSylwxzkIyevFT46BCNbCFnnebUAouTDHSfhInKshuj6a5TXbz jLgLX1oHvHBCayWgGwM1HfhbavLmm0UXlBbAe/SCaXbxmPWeET4lFOcWcuUhiDZ5+crvRejmN2QRS s40Kk5NUUwG5mg==; In-Reply-To: <20250104192504.GB2167271@qaa.vinc17.org> (message from Vincent Lefevre on Sat, 4 Jan 2025 20:25:04 +0100) 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:298464 Archived-At: > Date: Sat, 4 Jan 2025 20:25:04 +0100 > From: Vincent Lefevre > Cc: 75352@debbugs.gnu.org > > On 2025-01-04 16:36:20 +0200, Eli Zaretskii wrote: > > > With the Noto Mono font and a file with some Japanese characters > > > (I suspect that the reason of the need of such characters is that > > > they slightly modify the cell height, and the font can change by > > > just moving the cursor; see below), after set-mark-command (C-SPC), > > > end-of-buffer (M->) does not go to the end of the buffer. > > > > end-of-buffer scrolls the window to show EOB not-quite-at-the-bottom > > of the window. So what you describe can happen with unusual fonts. > > > > Why is that a problem? > > The main problem is not a display problem, but the fact that the > cursor (point) is not at the end of the buffer. My point is that M-> doesn't guarantee that. > I've attached a screenshot to show what I get. The cursor (not visible > on the screenshot) is just below the yellow area, on the first column. > Note that the last line is only partly visible: one just has the top > of the "x". Didn't you say that point then moves back into the viewport, and is set to line 35? Or what am I missing. > Concerning your other question, > > M-: (goto-char (point-max)) RET > > after C-SPC puts the cursor at the end of the buffer, as I expect. > But, just for confirmation that the cause of the difference is not > due to the minibuffer, > > M-: (end-of-buffer) RET > > also after C-SPC is still affected by the problem. > > BTW, I thought that end-of-buffer were equivalent to > (goto-char (point-max)), except for the "they set the mark and > display messages in the echo area" part. My intent in asking that was to make the point that they are NOT equivalent. If you look at the code of end-of-buffer, you will see that after going to EOB it does something else. My guess is that that something, together with the strange font setup you have, is the reason for the behavior you see. > > > $ emacs -Q --eval="(set-fontset-font t 'unicode (font-spec :name \"Noto Mono\"))" file > > > > This set-fontset-font setting is not a good idea: it tells Emacs that > > the named font can display _any_ Unicode character, which is usually > > not true: almost all fonts support only a subset of Unicode. > > This was taken from https://emacs.stackexchange.com/q/17205/29118 > (the goal was to prevent a fallback to a font with different metrics, > breaking column alignments; well, at least this was working for > math characters, IIRC). That is not how you do that. You should instead use set-fontset-font to specify a particular suitable font for the 'mathematical' script. > Note: Just after opening the file, if I use the , after the > scrolling, C-u C-x = over 岨 says > > ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-20-*-*-*-*-0-iso10646-1 (#x3E7C) > > even though the font has not changed and the character 黒 is displayed. > But C-SPC makes the font change, while I would expect no changes. This > is strange. C-SPC makes characters display in a different face, so strange things can happen if your fontset setup is incorrect (which it is because of the above setting in the --eval command-line argument). Just don't do that. And yes, if the font changes, what was inside the viewport can become outside, and that could cause Emacs move point.