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#73752: 29.4; Ligatures are randomly rendered with extra spaces Date: Tue, 29 Oct 2024 15:04:16 +0200 Message-ID: <86wmhr5acv.fsf@gnu.org> References: <86zfn9ycis.fsf@gnu.org> <86o735als7.fsf@gnu.org> <87o73534dn.fsf@gmail.com> <86h68x8nuz.fsf@gnu.org> <86ed418niu.fsf@gnu.org> <87jzds3lay.fsf@gmail.com> <86iktc6zp5.fsf@gnu.org> <87wmhs19rh.fsf@gmail.com> <86frog6thm.fsf@gnu.org> <87o73318ql.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1229"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me To: Visuwesh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 29 14:05:20 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 1t5luS-00009K-D4 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Oct 2024 14:05:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5luC-0005Wo-Bi; Tue, 29 Oct 2024 09:05:04 -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 1t5luA-0005W0-CA for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 09:05:02 -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 1t5luA-0004vq-1E for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 09:05:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=r4uIP1kwHhIzYL3sZf34qCrJv/VqBsKtKkxFC0wGHlE=; b=RDnzqO8ioYGDsukBkuP+9y8g4aiYI5om1wCb3nzPUMNiiT+zfVaXS1ghHlaTjgC5XS3pIPkQY2Rk1j9EhBlplkKC+2+kXEH6JephBecdgnAwqP5eOxqwB9gwQCLqkJcBDccpfmCckUSWT/hw2AXA3WHacG8XEcgfYGfnkVAH1Y4qHaJQ/xf9P7Rg8Ni/beqbyCsrInLmh3m2y8Mbcenu0jkURzcmtQ8qHbjgiI96EomYh7vV4wvw12hM5dbbR4qrpQnLPIQWKQ9rV9p38t8x+DIfLWUeDGmF9cP1gbQ4KSMem9ytL2kKlsvlHcrPUE3f5JecjWkoot1lJBGdemU+tQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5lu9-0003qX-Re for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 09:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2024 13:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73752 X-GNU-PR-Package: emacs Original-Received: via spool by 73752-submit@debbugs.gnu.org id=B73752.173020707014766 (code B ref 73752); Tue, 29 Oct 2024 13:05:01 +0000 Original-Received: (at 73752) by debbugs.gnu.org; 29 Oct 2024 13:04:30 +0000 Original-Received: from localhost ([127.0.0.1]:56380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5ltd-0003q5-C2 for submit@debbugs.gnu.org; Tue, 29 Oct 2024 09:04:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5ltb-0003py-A2 for 73752@debbugs.gnu.org; Tue, 29 Oct 2024 09:04:28 -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 1t5ltU-0004tE-8w; Tue, 29 Oct 2024 09:04:20 -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=r4uIP1kwHhIzYL3sZf34qCrJv/VqBsKtKkxFC0wGHlE=; b=f2Bx5K3kfkph /z0/eF6/yS9m3A1Sq7mdn28b2A/O7+d9yAAfqlb4Z5A4ufq1f9M6X14QgnTbua6Vcp4QaTP+tq9TQ S7l8tfIQjISgmNjgllLTMjowC4WNUCkC8vrpVg3VCy+JsvIdhktqixITct5XrCgmba5IAkpR1P3qs 9nYGtilkr77YtT/qexCnsSaC8AKfHODgrwKEgKwvRQQC7w3YnCMfYoU4grsT64sDKxZYpsVU62o3n SPpNvUh/cMiOPOydW2TTCacnyynZrqPnrysLSK4Lj2IINxQAMdO01ZJ0IduRfguGJAd41vdO6yY9x N7Qh5BfE5DLFXKjziIfbcg==; In-Reply-To: <87o73318ql.fsf@gmail.com> (message from Visuwesh on Tue, 29 Oct 2024 16:29:48 +0530) 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:294487 Archived-At: > From: Visuwesh > Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me > Date: Tue, 29 Oct 2024 16:29:48 +0530 > > >> Is this hash dependent on the font driver? > > > > No. Only the font used for the composed characters is recorded, not > > the font backend which opened it. But fonts are managed by the font > > backend, so maybe there's some leakage by that way. > > OK, thanks. I wonder if we could compare the value returned by > font-info if something has gone wrong with the font object used to > compute the hash for the glyph? That would not be the first thing I'd look at. According to the screenshots, it is more likely that a wrong cache entry is used for a composition, which uses the "wrong" font variant. IOW, the font used itself is fine, it just is not the font that's supposed to be used with the composed characters in that place. So I would first look at the font object stored in the header of the cached composition. > > Btw, how frequently do you use different frames, > > Quite often, I would say. I usually have two frames but it can go > upwards of 5 to 6 if I have a mouse attached to my laptop. > > > and how likely are you to have different definitions for the same > > faces on different frames in the same Emacs session at the same time? > > I don't quite understand this question. Are you asking if I have any > "frame-specific" face attributes i.e., non-nil FRAME argument in > set-face-attribute? Yes. > If so, no. OK, so one more theory eats dust (we don't record the frame in the composition cache). > > The only way I see to investigate this is to wait for this to happen, > > then attach GDB to Emacs and look at the problematic compositions in > > the cache, comparing them to the corresponding compositions in a fresh > > Emacs session. I can tell what to look for with GDB, if that helps. > > That would help. But given how hard it is to reproduce this issue on my > end, I don't know when I can get back... It would not be useful for me to give instructions before you actually hit the problem (because the code will change until then), so if you want to try this, get back to me when you do reproduce the problem (and then attach GDB and leave the Emacs session under GDB for any investigations I'd ask you to do). Thanks.