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 16:36:20 +0200 Message-ID: <8634hyd4t7.fsf@gnu.org> References: <87y0zqvfct.fsf@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="13371"; 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 15:37:34 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 1tU5HR-0003Iu-V8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 15:37:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU5H3-00084Z-P7; Sat, 04 Jan 2025 09:37:09 -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 1tU5Gx-000829-Dg for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 09:37:03 -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 1tU5Gw-0002VC-88 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 09:37:03 -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=V1w0+wBCAznEkUx71pKPQGN7elf1c6KZtXTy4pl7cQg=; b=JVkYgkYC1b0HOrnV4cmQHKHtTizezqwzulacEMui7rdUYk1C/Fzi7pXeGOcbku+tA3kwAwVIgTy/uHq+Mpv3hQ7bf6R6LdVcnrvrP13HGMbTAydlXqgksEdAd9aOEft1pNJRBrKEbgW29Z3jFgb9iEW27Jj/sQNQwiMAsn/BLylA47H4A8FX5jWrY/UcRdeMTCKjDvYYSfPTasxJ4ODzRim11jD88hKnPWQuCoGwYJBtgGaCk7cYs37kdAMSvo/2JalIqVksvz95posOeQVrmNtM1VKSw5+dgPp1sMxPFVhgRNLATx2MQ8vRkHr7iPHpTcQ5crM7nBS4woDq1nn1pw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU5Gv-0002tn-PW for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 09:37: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 14:37: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.173600139311106 (code B ref 75352); Sat, 04 Jan 2025 14:37:01 +0000 Original-Received: (at 75352) by debbugs.gnu.org; 4 Jan 2025 14:36:33 +0000 Original-Received: from localhost ([127.0.0.1]:54076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU5GS-0002t4-P8 for submit@debbugs.gnu.org; Sat, 04 Jan 2025 09:36:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47630) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU5GQ-0002sq-45 for 75352@debbugs.gnu.org; Sat, 04 Jan 2025 09:36:31 -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 1tU5GK-0002SH-1O; Sat, 04 Jan 2025 09:36:24 -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=V1w0+wBCAznEkUx71pKPQGN7elf1c6KZtXTy4pl7cQg=; b=esNyBkVNiwXfHmHaMUMo oGSZiqEst8qLnQWjf1wXxizje3sYoPJEi8nPQRjVx0Ipk26P/BCtW/XzvHXRdShrSYoNXfFI7v1hu 0zHEOvQZYR55/5YygA5z3Hgco3COH/3NznxMx3/ZohiUXGcUOfVphGqhLwfm8LFR4fdq07mkaUsIL 4wRTkq7E9GLgx3LHSC4QrbZ7Mf2C939GOSCltRcgPvHeLH6sDtO4f4g4NDFLAZHatITeeuy2GjweP QgEj/pnTrwfsWEXskCF7AQ3pTyvfRH//GAkIhFMq4aIDJ/cKjZqOfbQbdkTCdLRsVa5Q1fWQevqT0 fv2SuZnL+X+drg==; In-Reply-To: <87y0zqvfct.fsf@qaa.vinc17.org> (message from Vincent Lefevre on Sat, 04 Jan 2025 15:11:14 +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:298416 Archived-At: > From: Vincent Lefevre > Date: Sat, 04 Jan 2025 15:11:14 +0100 > > > 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? > (Due to the following setting, which is important, I don't know whether > the above Emacs.font matters.) > > $ 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. > Then type: C-SPC M-> > > Here, the cursor is placed on line 35 instead of line 50. If the last characters in the file are shown taller than the others, it could happen that the last line is not fully visible, and then Emacs will scroll the display > Note: Even without set-mark-command, once the 黒 character (line 48) > gets displayed, the font used for 岨 changes and the character cells > get taller. I've wondering whether this can confuse Emacs. At least, > this character 黒 is important to reproduce the problem. > > By using C-u C-x =, I get > * over x: > ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-18-*-*-*-m-0-iso10646-1 (#x5B) > * over 岨 before 黒 gets displayed: > ftcrhb:-PfEd-AR PL UMing TW MBE-light-normal-normal-*-18-*-*-*-*-0-iso10646-1 (#x159C) > * over 黒 (and same font over 岨 after 黒 gets displayed): > ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-18-*-*-*-*-0-iso10646-1 (#xB7AC) So there are at least 3 different specific fonts involved, and in addition the region's highlight seems to have some effect, and the frame needs to have a particular geometry. Can you tell why it is important to understand why what you see happens in that particular case? We will likely find that Emacs behaves as expected due to the metrics of the fonts.