From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gabriele Nicolardi Newsgroups: gmane.emacs.bugs Subject: bug#68827: Possible solution Date: Wed, 31 Jan 2024 20:56:12 +0100 Message-ID: <457c866d-d80c-4c5e-b4d4-f60fdf37992c@medialab.sissa.it> References: <8204e83e-f660-4c7e-a966-2b0b111fa5e9@medialab.sissa.it> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0WhMqlirkHE5umXt1rBQbTu7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6853"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird To: 68827@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 31 20:57:24 2024 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 1rVGi4-0001Y0-MX for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 Jan 2024 20:57:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVGhb-0005rI-1I; Wed, 31 Jan 2024 14:56:55 -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 1rVGhY-0005r8-Ua for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2024 14:56:52 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rVGhY-0002Xk-MH for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2024 14:56:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rVGhi-0001uP-9H for bug-gnu-emacs@gnu.org; Wed, 31 Jan 2024 14:57:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <8204e83e-f660-4c7e-a966-2b0b111fa5e9@medialab.sissa.it> Resent-From: Gabriele Nicolardi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 Jan 2024 19:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68827 X-GNU-PR-Package: emacs Original-Received: via spool by 68827-submit@debbugs.gnu.org id=B68827.17067309997306 (code B ref 68827); Wed, 31 Jan 2024 19:57:02 +0000 Original-Received: (at 68827) by debbugs.gnu.org; 31 Jan 2024 19:56:39 +0000 Original-Received: from localhost ([127.0.0.1]:39096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVGhF-0001te-GQ for submit@debbugs.gnu.org; Wed, 31 Jan 2024 14:56:39 -0500 Original-Received: from smtp06.cbsolt.net ([185.97.217.45]:38040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVGhC-0001tQ-Iw for 68827@debbugs.gnu.org; Wed, 31 Jan 2024 14:56:32 -0500 Original-Received: from [10.0.2.15] (host-82-54-244-118.retail.telecomitalia.it [82.54.244.118]) by smtp06.cbsolt.net (Postfix) with ESMTPSA id 4TQCTT6mGmz3wvL for <68827@debbugs.gnu.org>; Wed, 31 Jan 2024 20:56:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cbsolt.net; s=201504-di4k2w; t=1706730974; bh=0RWiTTeoHMi0OKBQ+nvTHnVestW5hG5NQH+HKcNNPYY=; h=Date:To:From:Subject:From; b=iAMIhgMGs/8FJsHUOhqdU0mB2lpZ45mkui0pvf905dfzu5uvx4WYK/jiiJ/X3Ni2X VX4KLhOvh4sBVIhrfZQ57M8/oLO9KGSqpzZi7+lL4kqi382APtSLuwcLf8vFurinvn /3Ra9L7vkxjzV5rnYD0aHIpuEZVu3O7HX6MXvyE0= 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279243 Archived-At: This is a multi-part message in MIME format. --------------0WhMqlirkHE5umXt1rBQbTu7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I checked the value of the font-lock-keywords variable and found: ```lang-el ("\\\(ProvidesFile\|href\|nolinkurl\|path\|url\) \(\[[^]]\] \){\(\(?:[^{}\]\|\\.\|{[^}]}\)+\)" 3 'tex-verbatim t) ``` If I use this command to add fontification: ```lang-el (font-lock-add-keywords nil '(("\\\(ProvidesFile\|href\|nolinkurl\|path\|url\) \(\[[^]]\] \){\(\(?:[^{}\]\|\\.\|{[^}]}\)+\)" 3 'tex-verbatim keep))) ``` the problem disappears. From the manual, I read: The last two values in subexp-highlighter, override and laxmatch, are optional flags. If override is |t|, this element can override existing fontification made by previous elements of |font-lock-keywords|. If it is |keep|, then each character is fontified if it has not been fontified already by some other element. If it is |prepend|, the face specified by facespec is added to the beginning of the |font-lock-face| property. If it is |append|, the face is added to the end of the |font-lock-face| property. So I think that "keep" should be the right choice. --------------0WhMqlirkHE5umXt1rBQbTu7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi,

I checked the value of the font-lock-keywords variable and found: 

```lang-el

("\\\(ProvidesFile\|href\|nolinkurl\|path\|url\) \(\[[^]]\] \){\(\(?:[^{}\]\|\\.\|{[^}]}\)+\)" 3 'tex-verbatim t)

```

If I use this command to add fontification:

```lang-el

(font-lock-add-keywords nil '(("\\\(ProvidesFile\|href\|nolinkurl\|path\|url\) \(\[[^]]\] \){\(\(?:[^{}\]\|\\.\|{[^}]}\)+\)" 3 'tex-verbatim keep)))

```

the problem disappears.

From the manual, I read:

The last two values in subexp-highlighter, override and laxmatch, are optional flags. If override is t, this element can override existing fontification made by previous elements of font-lock-keywords. If it is keep, then each character is fontified if it has not been fontified already by some other element. If it is prepend, the face specified by facespec is added to the beginning of the font-lock-face property. If it is append, the face is added to the end of the font-lock-face property.

So I think that "keep" should be the right choice.


--------------0WhMqlirkHE5umXt1rBQbTu7--