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.devel Subject: Re: region-based face-remapping Date: Thu, 4 Jan 2024 02:07:36 +0200 Message-ID: <3ce1e4f9-7f94-4d55-a614-a4c2c3ad6c27@gutov.dev> References: <83y1d7zy8s.fsf@gnu.org> <3592E8C5-35FF-44FF-88ED-B458303BF15A@gmail.com> <83edeyzjgp.fsf@gnu.org> <83y1d6y1n4.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="25393"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: jdtsmith@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 04 01:08:35 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rLBHm-0006RQ-SN for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jan 2024 01:08:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLBGy-00027V-CP; Wed, 03 Jan 2024 19:07:44 -0500 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 1rLBGw-000279-OG for emacs-devel@gnu.org; Wed, 03 Jan 2024 19:07:42 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLBGu-0006Ky-RH; Wed, 03 Jan 2024 19:07:42 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 627C75C02FD; Wed, 3 Jan 2024 19:07:39 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 03 Jan 2024 19:07:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704326859; x=1704413259; bh=fbgulTmNzc7AbUh77WPNB1Su8WzsZpxqQyE4oQo1FX4=; b= cQbpj1voZ1MbSam/1uNGohHbPyi5mz4dbxn5MiJob+O39o4jbmjzDpiB5A2ODw5/ g5kBUlS4zI+0qLDK22mc4QUNMFUn06Ncs0InIKz+H8XmMM56Q9vR6q1AswmG/ZBn RGcUpiguc2ZZScnow8045ZZgjSHMklWr21+SK5Os72PeYap1H5T6bA05csgUYyV0 BAxgeTijEYsv7KklfSCHERftEaIW49TDx8SxH8X/XzZfoFUKSnLSuqJct4bIVHCJ dDJvyboH87OEBJJQ1WzFF2Fmvq8x52eOlbfGTDcI/SQaqz85KG7PtCeQeZ/3x6Tm 2arZivYgAsAQRkfy5NCWbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704326859; x= 1704413259; bh=fbgulTmNzc7AbUh77WPNB1Su8WzsZpxqQyE4oQo1FX4=; b=s Dhu+sAioCWXfsXUlKV7EEZvikvFiTRXgpUUqIBU7GF2hESDm6d+XC9GrknXOkUMY ZX7/EMDJM5KD3uPXAzaHqYSMbJ8DQqLpM+NGHK8xGFmFXtpk2NJ5Lc2ENjN+FP5Y zfj0oa5mLmYnM2dMsyESSPYwmOJ1xeXH73FJ0E4MBITCdwemldijsZ1nT3u1Eqw3 Zw66u9/wJr2xpaCQsBHJw6W/nD4IKDrxwfb9weGNCkDZCBIc9+qSI6HAOGTNlqW9 z6JFitmK+vr3K1WCYGj+9ctOeAAvX2+EOHFBbL13tgWfHRqfmf8TcgWJb6XOktMU v3gS5KTrl4XkhHzph451g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegiedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Jan 2024 19:07:38 -0500 (EST) Content-Language: en-US In-Reply-To: <83y1d6y1n4.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314513 Archived-At: On 03/01/2024 15:42, Eli Zaretskii wrote: >> Date: Wed, 3 Jan 2024 14:40:49 +0200 >> Cc:emacs-devel@gnu.org >> From: Dmitry Gutov >> >> On 03/01/2024 14:31, Eli Zaretskii wrote: >>> The workhorse we use now for obtaining face information is the >>> function face_at_buffer_position, which calls the various face-merging >>> routines. Those merging routines and their subroutines consider >>> face-remapping-alist as part of face merging process outlined above. >>> I don't see how we can avoid passing the buffer position to them if >>> face-remapping depends on buffer position. >> Perhaps face_at_buffer_position would first look up the overlay/text >> property 'face-remapping-alist, then merge its value with the variable >> face-remapping-alist (using plain 'append', for example), and pass on >> the resulting value to the face-merging routines? > Then any code running while face_at_buffer_position does its job will > see a tweaked value of face-remapping-alist, which is not necessarily > TRT, since it is not guaranteed that the buffer position being > examined by face_at_buffer_position is relevant to the rest of the > code. I'm not sure I understand your response. IIUC the request is that one would be able to change the faces' appearances at any position in the buffer using a mechanism like additional text properties or overlay properties. It seems to reason that any code computing the 'face' for a buffer position would need to account for the new property if it's set at that position.