From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Wed, 28 Aug 2019 18:31:42 +0200 Message-ID: <20190828163142.kds3mfnyrjvxxxcj@Ergus> References: <20190825102205.rxhmu3bukraywhok@Ergus> <83lfvhh6dn.fsf@gnu.org> <20190826043145.pm5aplrxna5hwcso@Ergus> <83y2zgfjzs.fsf@gnu.org> <20190826081819.cuhm3tpw3lq3m5jh@Ergus> <83mufwfe8o.fsf@gnu.org> <20190827222025.p2cbjwak4ysi3ept@Ergus> <3ea328a6-2b35-5a01-77a1-bbf9ff7f16f2@gmx.at> <83lfvdd5f7.fsf@gnu.org> 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="63688"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 28 18:54:52 2019 Return-path: Envelope-to: ged-emacs-devel@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 1i31Dg-000GUk-Ap for ged-emacs-devel@m.gmane.org; Wed, 28 Aug 2019 18:54:52 +0200 Original-Received: from localhost ([::1]:38600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i31Df-0007Xv-3N for ged-emacs-devel@m.gmane.org; Wed, 28 Aug 2019 12:54:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36314) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i30rd-0002oo-Pl for emacs-devel@gnu.org; Wed, 28 Aug 2019 12:32:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i30rX-0003rT-5o for emacs-devel@gnu.org; Wed, 28 Aug 2019 12:32:03 -0400 Original-Received: from sonic303-20.consmr.mail.ir2.yahoo.com ([77.238.178.201]:37975) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i30rS-0003nG-O9 for emacs-devel@gnu.org; Wed, 28 Aug 2019 12:31:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1567009912; bh=HRl3GuvApr4sKiyU4imVtQkzZFwITY+qrsIx2KHRnFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=I66SWSTiORi5R+OHLTQAig0AFR9QmVjZg4qBVp83Sj/yBb0Sk3A5564/C5NHNr79yBVzoWk56D999cXHMkXWURvPMS4Zn4ZkV0Psxggf5fkm1kxZOE3Aqj0hne9sVFdkNj0ndRLtQABBNe4D9tQV32l2X566Fs60jbOV5phNxv1zaDRljNx5wt+z2iGD764RetMoiw2BAgTfwBI69LBKwY4y4iQfmrb19NqXg5J1yLaoA0T2ZqTMp1g08TThIsUXamVdF1ncZBq1/pbAYhR+Od/DoQO1mUe/Qk13oDb0EGCXql6GMy5Z5xDGroDgleLx3ctwTdXiX3kMYKld+ffxBA== X-YMail-OSG: FORUFAgVM1m033LQCsbKtIG5zMg6zHbf4UBQPEX_jpExM4pVPFbn8uHiyCCSo1c yS4xQw2xKKTDcjtn_OVHsNMy1gJt0nvEPUesK3zEog9.1IYUNyap7jv218PxLepcAH563feak5GC 7wjWjwHnbMPKH6ohBJloP_NybYFD.98FRHAWVFZK46_wr4VXqHl15Cyuz13SWjSuXWL5hRMO2YUW 88NVCjhAMnWRPbdSLUzxsPdJgjce6gg8iH9h4lD6adJz3L.xtUsGgMePkX8MFcfR8xAJPvtqR0J7 AYYWgiO_OIMdWhVODzRcnB_aD8mP9lIIr8ZlKXCnIN99bJMa4RLIorPU4oP0vfOCHJJ96ZR2pCm5 NxWvB_ZnZj1gIekeGPWfnVJvWCjZ.bZSMJQM3LNIjOSJnqk18IfNz_kgTxBRB5LrXimBqsxES2Hb QqyjlbRkB9C67P8n1D8CODKGiCCs2F52DoI9aOdZN_qulvPYOwL3UTEph7PYW1qjOM6yisDPhUdM fTLtKxlEX6LwYSnf9CHftdS04I3j_pah2R28g_bK4Gs.61bt05Eaup2MYvwoSRPNPDMUBRCIK1BQ _j8E7p501ji8uWwl4.tYc3Ay7s1qk7UB2i96NTF77iqSey1ugjGGVaAXzTuzrGOlLNhAuT4LLcIu NzRRjIn..hscBwj1YlKnoLOjslCCtKxc_V7TwHbCNFlnHaUhl43vYWRdvD.bfoC.ccAdWfOjAS3k TgK6sA96pd0shscszFbLmE6Mya.OLDpLG6TdOItik1iEsCLfrpRuzngLTu9yo.468msy_tgW9t82 UmZVe2oGpbp6niqP.2jQUgvgLRfXp3zSW.o2hi6pvz Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Wed, 28 Aug 2019 16:31:52 +0000 Original-Received: by smtp429.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9dd237826fd2c8455fb4bafffa5dbc46; Wed, 28 Aug 2019 16:31:47 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.178.201 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239643 Archived-At: On Wed, Aug 28, 2019 at 02:19:03PM +0200, martin rudalics wrote: >> I think we should simply not merge the background color of the region >> face when its extend bit is reset. Then the merged face will not have >> that background color. > >Then which background color would we use? That of the comment was >lost when setting up the current face for the iterator. > >> I don't see a problem here. A user who doesn't want the region face's >> background extend to the end of line wants only text (as opposed to >> whitespace after the newline) to have the region's background, and >> that's true both to regions that cross line boundaries and regions that >> end at a newline. > >I agree that we don't want to extend the region's background. But the >question I raised above still stands. > >We could make :extend sticky in the sense that once an :extend for the >background has been defined, it will apply to all higher priority faces >as well. This would make specifying a nil :extend value idempotent to >not specifying a value at all as you (IIRC) proposed earlier. But the >mechanism then becomes considerably less powerful. > Any way my question comes from 2 frequent use cases I don't know what's the expected behavior: 1) Base face sets background and extend; and face sets only background. 2) Base face sets extend but not background; and face sets both. in what condition the :extend attribute goes to the merged face? Always? when in base_face? When in face? in what condition the extend_element bits are reset after a merge? >>> Maybe the display engine could consult, with the stop position >>> privilege triggered by the newline character in mind, whether the >>> extend_background false setting of the current face could result in >>> applying another, lower-priority face specified by font-locking and >>> consult the extend_background bit of the corresponding realized face. >> >> I don't think I understand this proposal. > >Let's talk about it when we both see a problem here. > >martin