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#63271: 29.0.90; broken mouse-face Date: Tue, 09 May 2023 16:32:07 +0300 Message-ID: <834jolbpgo.fsf@gnu.org> References: <86zg6kuwz5.fsf@mail.linkov.net> <83354ckrvo.fsf@gnu.org> <86h6sq3che.fsf@mail.linkov.net> <83y1m2hbp6.fsf@gnu.org> <87fs89k8r0.fsf@yahoo.com> <86fs88xbrx.fsf@mail.linkov.net> <833548dm6y.fsf@gnu.org> <86ednrur9e.fsf@mail.linkov.net> <83y1lyby15.fsf@gnu.org> <86ednq11lv.fsf@mail.linkov.net> <83fs85c366.fsf@gnu.org> <87o7mtvnqr.fsf@gmx.net> <87jzxhvmw2.fsf@gmx.net> <83a5ydbya7.fsf@gnu.org> <87fs85vll4.fsf@gmx.net> <838rdxbu61.fsf@gnu.org> <87bkitvfop.fsf@gmx.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25341"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 63271@debbugs.gnu.org, juri@linkov.net To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 09 15:32:20 2023 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 1pwNRz-0006No-P0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 May 2023 15:32:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pwNRl-0004CE-00; Tue, 09 May 2023 09:32:05 -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 1pwNRi-0004A9-St for bug-gnu-emacs@gnu.org; Tue, 09 May 2023 09:32:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pwNRi-0001n4-Hw for bug-gnu-emacs@gnu.org; Tue, 09 May 2023 09:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pwNRh-0000l0-UH for bug-gnu-emacs@gnu.org; Tue, 09 May 2023 09:32: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, 09 May 2023 13:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63271 X-GNU-PR-Package: emacs Original-Received: via spool by 63271-submit@debbugs.gnu.org id=B63271.16836390792859 (code B ref 63271); Tue, 09 May 2023 13:32:01 +0000 Original-Received: (at 63271) by debbugs.gnu.org; 9 May 2023 13:31:19 +0000 Original-Received: from localhost ([127.0.0.1]:42709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwNR0-0000k3-EY for submit@debbugs.gnu.org; Tue, 09 May 2023 09:31:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwNQv-0000jm-VZ for 63271@debbugs.gnu.org; Tue, 09 May 2023 09:31:17 -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 1pwNQo-0001Zt-GA; Tue, 09 May 2023 09:31:07 -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=X9+HQilOszDrDJeeIXYNL2Ottq/JmyMHdGqOVcbMwhA=; b=j4EkdZyBjfsV Av51TMn93HVcPPAD+NdBUF88ScJfdkRbzSSJ5fgh+GwVBqckBFOu44rtJi66RkFO6sKjWfkIuuqXy mDilUw7WGF7yxxeYhCdD3HTsAaZkwjIpq1dhOys4q63CXAwNUz6BUrj8FpzwGpeUuFLEv17vipD72 ogGWhQWMD/XVPplghi+5dfnnpXQNTPVT+oyM35ebMEd6AunNhv/sCNU59qeZ02ca9GdGmQiTGhGGF e+xGHTOyuayY9iUHI6kR8am3vB7BZGghQUvhx5J+Vmk9Ryb8HMy8hZ3TayZQ+0+0l5T3jduK7oUb4 ceVJgs/2lr2e5o+8sGd9Jg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwNQm-0001mm-Ab; Tue, 09 May 2023 09:31:05 -0400 In-Reply-To: <87bkitvfop.fsf@gmx.net> (message from Stephen Berman on Tue, 09 May 2023 14:43:02 +0200) 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:261412 Archived-At: > From: Stephen Berman > Cc: juri@linkov.net, luangruo@yahoo.com, 63271@debbugs.gnu.org > Date: Tue, 09 May 2023 14:43:02 +0200 > > > What do you see on the screen in this case? Please describe the > > visual appearance of each character in the case of fundamental-mode, > > and perhaps also show a screenshot of the window as it is displayed > > when the mouse-highlight becomes visible during this scenario. > > Here's a screenshot of lisp-interaction-mode when the mouse-highlight > appears: Thanks. This is strange. Can you try one more thing, please? With the same breakpoint in xterm.c, when the breakpoint breaks, please type (gdb) print/x s->face->background Please do this every time the breakpoint breaks, and let's see if Emacs thinks both the "TODO" text and the blank after it should be displayed with the same background color (which should be the background of the 'highlight' face). That's what I see on my system. If the colors of the two glyph_string's indeed match, I'm led to believe that the problem is elsewhere, in the low levels of drawing the stuff on screen. Perhaps some library (Cairo?) has a bug or something. Because the data structures prepared by the Emacs display engine are correct, and explicitly specify the mouse-highlight background to be drawn. So somehow using this particular font erases the background, or something to that effect. This is also consistent with the fact that other font backends don't show the problem. Po Lu, any ideas how to look into this further? > Aside from the difference in highlighting, another difference I failed > to notice before is that in fundamental-mode the string "TODO" is > displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans > Mono, although I used the same Lisp code with the face property > (:inherit variable-pitch) to enter the string in both buffers. I guess > lisp-interaction-mode inhibits variable-pitch face and that's the reason > the mouse-highlighting appears on the problematic characters in that > mode, in contrast to fundamental-mode. This is actually easy to understand, and is expected: lisp-interaction-mode has font-lock-mode turned on, and thus the recipe you evaluate doesn't change the face (thus the font), only adds mouse-highlight.