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#50660: 28.0.50; Text artifacting when the cursor moves over text under mouse face that originally displayed a box Date: Sat, 16 Oct 2021 13:10:59 +0300 Message-ID: <83wnmdgtzg.fsf@gnu.org> References: <87czp6ysw7.fsf.ref@yahoo.com> <878ryvnain.fsf@yahoo.com> <83mtnbltyp.fsf@gnu.org> <87mtnblt35.fsf@yahoo.com> <83ilxzlsck.fsf@gnu.org> <877defls2w.fsf@yahoo.com> <83fst3lrwr.fsf@gnu.org> <87o87rkczt.fsf@yahoo.com> <83czo7lqrl.fsf@gnu.org> <87h7djkayk.fsf@yahoo.com> <83bl3rli53.fsf@gnu.org> <871r4njcum.fsf@yahoo.com> <83v91yiesj.fsf@gnu.org> <8735p1izzi.fsf@yahoo.com> <83k0idijq9.fsf@gnu.org> <87lf2th4ur.fsf@yahoo.com> <83fst1iivf.fsf@gnu.org> <87y26tfp6p.fsf@yahoo.com> <83ee8lihd9.fsf@gnu.org> <87lf2tfnn5.fsf@yahoo.com> <838rytig5g.fsf@gnu.org> <874k9hfltz.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="970"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50660@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 16 12:12:10 2021 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 1mbgfi-00005t-P7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 12:12:10 +0200 Original-Received: from localhost ([::1]:37924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbgfh-0001A2-1g for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 06:12:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbgfa-00019u-L1 for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 06:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57656) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mbgfa-0004Cf-Bz for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 06:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mbgfa-000257-5T for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 06:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Oct 2021 10:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50660 X-GNU-PR-Package: emacs Original-Received: via spool by 50660-submit@debbugs.gnu.org id=B50660.16343790707934 (code B ref 50660); Sat, 16 Oct 2021 10:12:02 +0000 Original-Received: (at 50660) by debbugs.gnu.org; 16 Oct 2021 10:11:10 +0000 Original-Received: from localhost ([127.0.0.1]:40969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbgej-00023t-P0 for submit@debbugs.gnu.org; Sat, 16 Oct 2021 06:11:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbgee-00023M-JQ for 50660@debbugs.gnu.org; Sat, 16 Oct 2021 06:11:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44618) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbgeZ-00025y-Dx; Sat, 16 Oct 2021 06:10:59 -0400 Original-Received: from [87.69.77.57] (port=4853 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 1mbgeZ-0007Kr-15; Sat, 16 Oct 2021 06:10:59 -0400 In-Reply-To: <874k9hfltz.fsf@yahoo.com> (message from Po Lu on Sat, 16 Oct 2021 15:52:24 +0800) 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" Xref: news.gmane.io gmane.emacs.bugs:217356 Archived-At: > From: Po Lu > Cc: larsi@gnus.org, 50660@debbugs.gnu.org > Date: Sat, 16 Oct 2021 15:52:24 +0800 > > Eli Zaretskii writes: > > >> I'm reasonably sure. Under the old code in *term, moving the mouse over > >> the entry for `glyphless-char' in list-faces-display results in nothing, > >> while under the new code (where s->font == s->face->font even under > >> mouse face) the section under mouse face overlaps with its surroundings > >> and is otherwise glitchy, because the mouse face's font is larger than > >> the original face's font. > > > In the examples I used for testing the size of the font was the same, > > so I'm no longer sure we are talking about the same thing. > > Yes, this has gone off on some kind of tangent. I don't think it's a tangent, see below. > Okay. The first issue, with the cursor put on the first character "s", > is caused by this snippet of xterm.c (in x_draw_glyph_string_foreground): > > /* If first glyph of S has a left box line, start drawing the text > of S to the right of that box line. */ > if (s->face->box != FACE_NO_BOX > && s->first_glyph->left_box_line_p) > x = s->x + max (s->face->box_vertical_line_width, 0); > else > x = s->x; > > An identical snippet exists in w32term. > > This happens because s->face is not the mouse face when s->hl is > DRAW_CURSOR and cursor_in_mouse_face_p, so it mistakenly assumes there > is a box for s (when there is in fact no box), and adds the original > face's vertical box width to x. So you are saying that s->hl can only be either DRAW_CURSOR or DRAW_MOUSE_FACE, whereas we need both? If so, this matches what I thought you were trying to solve. So what happens here is that s->face is computed from the face of the glyphs which "belong" to the glyph string s. That face comes from the glyph matrix which holds the glyphs. That face was computed by redisplay_window using FACE_FOR_CHAR, see get_next_display_element, so it's the face at the character's buffer position adjusted for the font suitable for the character at the cursor. Now you want to display that same character, but with the mouse-face. FACE_FROM_ID gives you that face, but it is for ASCII characters. So you call FACE_FOR_CHAR again, to obtain the mouse face adjusted for the font suitable for displaying the character at the cursor. The above sounds correct to me, so I don't understand why you want to ignore the font of the face produced by FACE_FOR_CHAR. What am I missing? > (Seeing this issue, you proposed to also move mouse face selection to > draw_glyphs, and I proposed to move it to fill_XXX_glyph_string, leading > to the above tangent about the semantics of s->font.) Yes. Btw, it would probably be cleaner to add an extra argument to get_glyph_face_and_encoding, but make that argument be a pointer to 'struct face', not just an indication of which face to use. > The second issue was caused by testing for "start <=" end instead of > "start < end" in get_cursor_offset_for_mouse_face. What was that second issue about? why did you need to change the inequality?