From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#42552: 28.0.50; Overlay 'face' property doesn't set the "underlying face" for 'after-string' Date: Wed, 5 Aug 2020 02:55:59 +0300 Message-ID: References: <46466541-6185-2bf3-87cc-b28c71fe69e7@yandex.ru> <838sf6gkvq.fsf@gnu.org> <83wo2ldrqb.fsf@gnu.org> <831rknbwb9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33682"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: 42552@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 05 01:57:11 2020 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 1k36nv-0008ep-Lf for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Aug 2020 01:57:11 +0200 Original-Received: from localhost ([::1]:46352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k36nu-000657-P5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Aug 2020 19:57:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k36nm-00064o-Gs for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2020 19:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37805) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k36nl-0002vx-Mq for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2020 19:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k36nl-0001bv-Hi for bug-gnu-emacs@gnu.org; Tue, 04 Aug 2020 19:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Aug 2020 23:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42552 X-GNU-PR-Package: emacs Original-Received: via spool by 42552-submit@debbugs.gnu.org id=B42552.15965853726126 (code B ref 42552); Tue, 04 Aug 2020 23:57:01 +0000 Original-Received: (at 42552) by debbugs.gnu.org; 4 Aug 2020 23:56:12 +0000 Original-Received: from localhost ([127.0.0.1]:49351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k36my-0001ak-Gk for submit@debbugs.gnu.org; Tue, 04 Aug 2020 19:56:12 -0400 Original-Received: from mail-wr1-f67.google.com ([209.85.221.67]:38942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k36mu-0001aT-EA for 42552@debbugs.gnu.org; Tue, 04 Aug 2020 19:56:11 -0400 Original-Received: by mail-wr1-f67.google.com with SMTP id a5so28988161wrm.6 for <42552@debbugs.gnu.org>; Tue, 04 Aug 2020 16:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=f0WoAHYDXUSVKguYhm4fCk0XgoPaVzaTw5j1bhlnBXE=; b=uITBED+8fbTrUAuzLU2OdvKL7PwVprloBGH99ccjrmTKVTndPzvD34qa+JKFqIeddO LaWvj+4mrYJHjcXEkQIUdXHvfBIrTpfYM0IH4EZHabcA7qAWbQG5B2tvnsMeQb1JFbf2 nDsO8J48h8nDruqDCIDyIMlN9vvtQAt9rBQ7Jp3B9SzhqBMd3N6O4Hdqt4TT69yYwt08 z+hpXavMtcaUJsCikX8B71OPPr1Dw3xcCaliC38PGCpK8v/yQoJ5lQ13tVOmG1Wv26qs hoCdQ2Y0p9CEu4t01hXLOSurXJjdoznWhSLqChzS4P0A1zqHKLyka2665zKtvjtQRo38 2W6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=f0WoAHYDXUSVKguYhm4fCk0XgoPaVzaTw5j1bhlnBXE=; b=kxLHDX+zVUKh4/7Wc1dzPhYLhxhsCad0OmkAzPo1veZpoGMarZz6SSjA2f7zvsni/g 6EX8ivJhNYa2y20ewNNdEaBzX+t8UNma/stvVSgxvPQJTnAqEAoCq7LQgyZWo3D+9Oe8 OhJ6QOFf6YtLKEcumxeKM3SKBitxLomaMIDezXgVXIpe5TIjGFQII7nk1f6lyegkbeGf D4ID+56ev9R+bbrnzesU62+RXgNWSkf+poBHiBbyyC9d1r/NvOKcL0FS00+dpowwCCyt bfCfbHJPJmuIP1wLR5sBWpULJub+3c2sCM7wVZDk2/ZJQgtwCLSRg+ZplkDeuh+F6+7c vBfA== X-Gm-Message-State: AOAM532V8aH4/v+90CtAzyLjpbzEqQev4UeduDuje4cYNv2yBn+iRO1s wEeGGMzS1crNmUxy2dFvB0Vha70L X-Google-Smtp-Source: ABdhPJxGD3Pny5Mnqk6dE9JPA+gR1Pe9DDZyzyFI2K4fkVMbjkYzvUE3kJWUt3B5jBW8l7pSoif2jw== X-Received: by 2002:a5d:6a4e:: with SMTP id t14mr290701wrw.135.1596585361979; Tue, 04 Aug 2020 16:56:01 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w64sm457201wmb.26.2020.08.04.16.56.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Aug 2020 16:56:01 -0700 (PDT) In-Reply-To: <831rknbwb9.fsf@gnu.org> Content-Language: en-US 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:184055 Archived-At: On 03.08.2020 18:09, Eli Zaretskii wrote: >> Cc: 42552@debbugs.gnu.org >> From: Dmitry Gutov >> Date: Mon, 3 Aug 2020 02:37:37 +0300 >> >> But the installed fix doesn't solve the other scenario, depicted on the >> second screenshot attached to this report: >> https://debbugs.gnu.org/cgi/bugreport.cgi?msg=5;att=3;filename=Screenshot+from+2020-07-26+20-59-25.png;bug=42552 >> >> Do you need a step-by-step repro for that? >> >> The reason for that difference seems to be that it's a log-edit buffer, >> and the delimiter line is fontified using an anonymous face '(:height >> 0.1 :inverse-video t :extend t), see the end of log-edit-font-lock-keywords. > > When the underlying face has the :extend attribute set, we must obey > it. So what you see in that case is the expected behavior. Should the "overlay string" obey the underlying face, though? It doesn't obey the 'face' property, like you explained. Seems inconsistent. >> Still, Emacs 26.3 doesn't exhibit this problem, and in that version the >> contents of that anonymous face was the same (except without :extend t, >> but back then, all faces did "extend"). (*) > > Emacs 26 and before simply extended the face of the last character of > the line. Emacs 27 doesn't do that, it examines the faces in effect > anew, filtering out those which don't have the :extend attribute set, > so the result is different. This is exactly the change in behavior > that was intended, not a bug. But it should obey :extend set to nil, shouldn't it? >> Would it be too hard to have the same behavior in 28+? > > You can have this in Emacs > 26 if you make the face of the last > character have the :extend attribute set, so that its background color > overrides that of the one of the underlying buffer text. E.g., you > could define a face that inherits from 'default', and if that doesn't > specify the background color, From what I can tell, 'default' specifies '#ffffff' background on my machine. It also sets :extend to nil. In the diff attached to the report (which is part of the reproduction scenario), you can see the whole overlay string's 'face' property being appended with the value 'default'. It doesn't seem to help. Even if I replace 'default' in there with a custom face that sets ':extend' to nil, the result is the same. > use the frame's background as fallback > to set that face's background. I suppose you mean the custom face must have :extend set to t, and have a :background value computed right before it is used (otherwise the user might customize the faces mid-session, leading to bad visuals). That seems to work. It also has the significant benefit on working in Emacs 27, so if that's the approach you recommend in the end, the fix you already pushed to master might be unnecessary. > I don't see how else to get the behavior you want when using overlay > strings. The only alternative is to move the position where you place > the overlay outside the problematic face, but that is probably > undesirable for other reasons. It's just hard to do. And there might be no such position anywhere nearby. >> Furthermore, in Emacs 26.3 I can propertize the newlines in the overlay >> string with '(face region) and see the "extend" effect. Or keep them >> with 'default' face and see no "extend" effect on those lines. > > You are saying that this doesn't work in Emacs >= 27? One works, the other doesn't. >>> Like face_at_buffer_position except for OVERLAY. Currently it >>> simply disregards the `face' properties of all overlays. */ >>> >>> int >>> face_for_overlay_string (struct window *w, ptrdiff_t pos, >> >> But it works! That's how we closed bug#38563, didn't we? > > It works with display strings, yes. You now want to switch to overlay > strings, and the rules of collecting faces are subtly different there. Hmm, so 'after-string' and 'before-string' are overlay strings, but 'display' set on an overlay is not an overlay string. Okay then.