From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages Date: Wed, 16 Oct 2019 22:23:42 +0200 Message-ID: <20191016202342.4xlyoqzxeloo4hxg@Ergus> References: <83bluhf7nz.fsf@gnu.org> <20191016111004.oialbyleokafpccz@Ergus> <87k194fvn7.fsf@mail.linkov.net> <83y2xkcyu9.fsf@gnu.org> <87o8yg5v80.fsf@mail.linkov.net> Reply-To: Ergus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="81547"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: andreyorst@gmail.com, Eli Zaretskii , 37774@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 16 22:25:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iKprB-000Kuz-E3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Oct 2019 22:25:17 +0200 Original-Received: from localhost ([::1]:47954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKpr4-0001Pk-J3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Oct 2019 16:25:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40574) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKpqy-0001NB-73 for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2019 16:25:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iKpqw-0000w5-P8 for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2019 16:25:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37823) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iKpqw-0000w0-LD for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2019 16:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iKpqw-0002AU-Fl for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2019 16:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2019 20:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37774 X-GNU-PR-Package: emacs Original-Received: via spool by 37774-submit@debbugs.gnu.org id=B37774.15712574498269 (code B ref 37774); Wed, 16 Oct 2019 20:25:02 +0000 Original-Received: (at 37774) by debbugs.gnu.org; 16 Oct 2019 20:24:09 +0000 Original-Received: from localhost ([127.0.0.1]:46644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iKpq4-00029J-VE for submit@debbugs.gnu.org; Wed, 16 Oct 2019 16:24:09 -0400 Original-Received: from sonic306-20.consmr.mail.ir2.yahoo.com ([77.238.176.206]:35235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iKpq2-00028g-1I for 37774@debbugs.gnu.org; Wed, 16 Oct 2019 16:24:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1571257439; bh=OdeVz4C4pyPjhBZr0xhhtqDgo6UmGBebCC0L5ht/BiE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=c6Qwveb4d/4uYNZcXxJOpD/Nii//rowRsIiRI797eI/NyB1uXZDJlJ7cdt7WENPcYBBXW5Ty7CCwDmXU+iuIsdTWJAYvMNoxICuHvkjYQ1FwLjwmXaVgf+H3MpmwUlKYcKDRxAMsVaXgmkHmfed+PnTU3BjCKP8v6RMj5It/qjR7nrqUHqO0maCxtLxKWZtZtar6QJ7CcJ+bTxAbXTGWxQXfD1I4FdN5l9iIl2MBDV5pHFEz2tfl/4VkKP3/zKQ77KvgZT3acAU8fGFgSS46Sy9Lz1Mx9JAaHb8jAnnU9g2vhvKhus8XKWDhMThf642On0emEaRWzgJzgEp8PHDAdA== X-YMail-OSG: LpWk3BsVM1kOsDqmyYDu8viORkQoSgv19OGfXNyGXjo9xakmhcsO1NF6YaoJk3f sCFTN_KSJ_.LCbHLhRXrb4N0iZmchrtxa9IoTegYVO5mk.2DwQawf3dEE5zKZJ0qihAMy79Y9Q9z PZIFiHiW4W5AsJ2ncZw1IuPxP584m_6cqZFJf9fP0MgfGyLVZRYCLTOf_q5bkNefRuI_kQxyUvzI uttl6nIgmEIugdUojf_DSt9JgrDxueibVxG7rBMGRxlTcGhtrYv4L.aqeAeL2bDxAg6W8rFe6zzd p6WM8vfOK8yS1y1mldQSMiztf2e5QAwDOPOeEc2g8nMmEhP_mqjKOJU4sQf5skT6v2YY0HU1ULZf cU5uR9a0Rv5yr3q.XDgM.CjqY4tkF7PhqEW4JpwT4ltoBvyOtWOMAs5VOVOB24g.MQoKp045KkNu k7p4dyuewIXgYFtgJMW58uTPMTBRkWeH8SjKallH8kkwGIM_Fr.7qNCgEFxCgwGD4xggyy0XdlKv svAvaxiVlYBmbxx6nMvnh_eKaEadLQT9x8.b40DQv2ESZ8k9GzFTkBMT2qXke.rwJPvUMFBWEcwd 9a0rVbHMoHiDGx7WyJtZf_JOFrk3Jc5dZJbm2_O0IMcloBVSqq7bzqkZVywPdbOraXr.RlQpsl7B iPy3KA9KpJx3MqZ65Szc3WIQgRN5MKv4ZfodSSP5NBr6Rsvfb3sZu0L0StXGRpck9jUwEDP.hbL3 XAFKtqabAn91xO36oOOP0c7Z_lEMo06ZCFDR_8oDwoiPOmHtwJyV1e68NsokEKnjGaHkEwat0do5 deSOCmbdTGbkO_zxOL1DhzXxzq0NkjLTPHcZVBh6G4 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Wed, 16 Oct 2019 20:23:59 +0000 Original-Received: by smtp408.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 72bc951dba4cf8eeabbe2f36b900feb0; Wed, 16 Oct 2019 20:23:56 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87o8yg5v80.fsf@mail.linkov.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:169496 Archived-At: On Wed, Oct 16, 2019 at 10:46:55PM +0300, Juri Linkov wrote: >>> 1. Backward-compatibility problem: >>> >>> I had to spend significant time investigating why the region face broke >>> recently, and discovered that customized faces in custom-set-faces need >>> to be updated. >> >> I'm not sure I understand: the region face is defined to be extended >> beyond EOL. How does custom-set-faces enter this picture, and why did >> you need to do anything about the customized faces? > >The region face customized long ago in the init file >has no ':extend t' face attribute, e.g. > >(custom-set-faces > '(region ((((class color) (background light)) (:background "gray90")))) > When moving to a new emacs version (with early init and other tweaks) it will be recommended to update some details in the init file any way. >>> Soon I tired fixing their customizations one by one manually, >> >> Which other faces needed to be "fixed", how, and why? > >All diff faces and faces that have a distinct background color >like 'comint-highlight-input' (should extend to window edge >to help locating visually the command line in shell buffers), >'org-block' (because it highlights code blocks), 'xref-file-header' >for the same reason as diff faces, i.e. faces that highlights blocks. > For sure some other faces will be corrected once we find they are "broken" or they work better with ":extend t". Org mode is a very active package so the authors will correct this once they get emacs 27 (or we contact them). Actually some of them follow this mailing list. >> Why are you talking only about the colors? face extension is not only >> about colors, it's about other attributes as well: underline, >> strike-through, box, etc. You list underline with foreground color, >> but they are not the same as color, especially not when face extension >> is concerned. They actually behave more like background colors. > >Yes, this new feature is useful for all these face attributes >to extend them to EOL. The only exception is background colors. > >All complaints are only about extending background colors to EOL. >So the change could apply to all face attributes except background colors. > I think this will be inconsistent with the own intention if the feature, the problems it fixes and the criteria to distinguish and determine what to extend and what not. Remember we are dealing with merged faces too. >Only other attributes should be extended to EOL, because when such face >attributes like underline and strike-through are displayed over >an empty space beyond EOL, this looks ugly. > In the discussion previous to the implementation we agreed to give the freedom to the user to extend or not. Actually we choose a more complex design to assert give this freedom to the user. Baybe the user wants to highlight the region using underline, and adjust that to the EOL or not... now he can. >> And then there are faces with both foreground and background colors. > >Actually the distinction is not so simple: even some background colors >need to extend to EOL, such as when used in combination with the 'box' >face attributes, because when a button takes two lines, extending >the button box face to the window edge looks ugly. > This depends of the use case; so we won't have a criteria that will fit all the cases. >>> As I see the change was meant to fix only the problem that relates to >>> faces with distinct foreground, because indeed underlines extended >>> to the window edge look very ugly. So the change should affect >>> only faces with distinct foreground. >> >> That wasn't the intent. the intent was explicitly to cause the change >> in background color and underline/strikethough/etc. attributes--those >> which show in the face extension. Foreground color doesn't show in >> face extension. >> >>> This screenshot demonstrates how badly broken these blocks are now >>> in diff-mode that it makes harder to read diffs: >> >> I'm sorry, but I don't see why it is broken or hard to read. > >Because there is no distinctive rectangular header anymore, >and no diff hunk blocks. > This will be fixed in 2 minutes once we have a set of faces we should update. But also this will be a matter of preference. >>> Ideally to be more nice-looking, background colors in such faces should be >>> extended to the column defined e.g. by display-fill-column-indicator-column. >> >> That would be ugly if the line's text extends beyond the fill-column, >> no? Also, it would look even uglier with variable-pitch fonts. > >Extending to the fill-column could be an optional feature. >It won't work with variable-pitch fonts the same way as >filling to fill-column doesn't work with variable-pitch fonts. >But if some line's text will extend beyond the fill-column >with fixed-pitch fonts, this even could help to find long lines >(like in whitespace-mode). This will be not implemented for now; it will add too many corner cases I'm not sure it worth the effort to solve them just for an exceptional aesthetic use case. Maybe for emacs 28 ;p