Received: (at 79677) by debbugs.gnu.org; 30 Oct 2025 09:13:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 30 05:13:18 2025 Received: from localhost ([127.0.0.1]:34066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vEOic-00051d-49 for submit <at> debbugs.gnu.org; Thu, 30 Oct 2025 05:13:18 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:45084 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1vEOiT-00051D-Kh for 79677 <at> debbugs.gnu.org; Thu, 30 Oct 2025 05:13:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1761815587; bh=K3kNiiyg8KzQbtuzCNR7MHYGwosA1LnQPK3EHJLX2zc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HvXQRdTpFvDodNGRvsHSOzXYNkwwURwBf0NhA+Zj5X+OFK6fKlv+vjFg9d1revGDq 0LONuWAOu+hwwOMF5B0aw8BMlS3UqkwDKBmk2+Aq59QdYuWhbPts55AufzIbYBBaqy MfiCncsI+1Pmstp/DW0Zjxc1WgILQeG2adzC5RLoDefqtUL+LB+oOt7NZLr1W+h7tL Kfe/t62ogAKVW1B18jV0Ik242daZss/fepCkVsnx9FqQjzsdm8ruiP0peJVHITNHAL 5Ni0HKayif1ztwwNOj7guv10s8Kq/FGQ2F6eBHEcQzZzr03l0ZvzkOL6URYvrU0hIB o93pnsJmC9LIA== From: Eshel Yaron <me@HIDDEN> To: Protesilaos Stavrou <prot@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <5ef978de9e8045438f7eb03023f93b59@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> <87ikg5n8mr.fsf@HIDDEN> <2380b90a3a13f10a24789735cfb9e23d@HIDDEN> <877bwit0oq.fsf@HIDDEN> <87a51dboa3.fsf@HIDDEN> <9084bb18711c238f1cbcc524249d661e@HIDDEN> <87tszk7ah4.fsf@HIDDEN> <5ef978de9e8045438f7eb03023f93b59@HIDDEN> Date: Thu, 30 Oct 2025 10:13:03 +0100 Message-ID: <871pmkoiqo.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi, Protesilaos Stavrou <prot@HIDDEN> writes: > On 2025-10-27 15:14, Eshel Yaron wrote: > > I just pushed the change that supports this feature. Thank you for > taking the time to explain everything! Great, thank you! >> We want to communicate the most important information, so we use >> distinct faces for important distinctions. If few people care about a >> certain distinction, we might use indistinguishable faces by default. >> For example, the analysis can tell apart macros from special forms, but >> this distinction is not that important for programmers, so we make the >> elisp-special-form face look the same as elisp-macro by default. > > With this in mind, I made several of those faces nil, while I styled > others to look right in context. It is a delicate balancing act. I took a quick look, so far it seems really good. :) The variable highlighting is now somewhat incoherent though: You reset elisp-binding-variable to default while highlighting elisp-bound-variable with a non-default foreground color. In contrast, you highlight elisp-shadowed-variable while resetting elisp-shadowing-variable to default. But elisp-shadowed-variable and elisp-bound-variable should appear alike, they are both for let-bound variables. Likewise for e-binding-v and e-shadowing-v. By default only an underline differentiates these two pairs. The underline says "this is a special variable." See the snippet I sent earlier in this thread for examples, specifically see how the let-binding of exec-path now appears exactly the same as the reference to the local variable cpa, which is differently from how the let-binding of cpa appears, whereas that let-binding of cpa now appears like the reference to the locally-shadowed exec-path. So I suggest to at least switch between the customization of elisp-bound-variable and elisp-binding-variable. I would also restore some distinguishing attribute to elisp-free-variable, to make references to special (global) variables easily identifiable again. (By default they get that same underline.) Lastly I think that elisp-face, elisp-feature and elisp-widget-type should not be reset to default, but that's of secondary importance. >>> - The foreground of the 'elisp-symbol-at-mouse' is ignored. >>> The foreground of 'elisp-symbol-at-mouse' should take precedence >>> like how the 'highlight' or 'mode-line-highlight' faces work. >> It's not exactly that elisp-symbol-at-mouse works differently from >> that >> face or another, rather it has to do with the way we use this face: >> We set the mouse-face property to (FACE elisp-symbol-at-mouse) where >> FACE is the face we apply to the symbol (as its 'face' text property, >> not the mouse-face property). So properties of FACE override >> properties >> of elisp-symbol-at-mouse. This creates the nice effect that the symbol >> retains its foreground color (specified by FACE) when you hover over >> it, >> only the background (specified by elisp-symbol-at-mouse) changes. >> Do you think it'd be preferable to change also the foreground color >> when >> you hover over a symbol? Do you plan to give elisp-symbol-at-mouse a >> non-default foreground color? If so, we can add a user option that >> would control what we do with the mouse-face property, and the themes >> could then set this option. > > The foreground has to change as well when that is given. Otherwise we > are forced to use a background that maintains the expected contrast > ratio values for all possible foregrounds. This means that the > background must be subtle, which may not even be noticeable anymore in > some cases, such as when hl-line-mode is involved. I see, that makes sense. I'll add some way to control this behavior and let you know. Regards, Eshel
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at 79677) by debbugs.gnu.org; 30 Oct 2025 05:48:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 30 01:48:22 2025 Received: from localhost ([127.0.0.1]:33323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vELWH-0000aZ-SZ for submit <at> debbugs.gnu.org; Thu, 30 Oct 2025 01:48:22 -0400 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:60947) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <prot@HIDDEN>) id 1vELWD-0000Zy-4v for 79677 <at> debbugs.gnu.org; Thu, 30 Oct 2025 01:48:18 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id BFD6844423; Thu, 30 Oct 2025 05:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protesilaos.com; s=gm1; t=1761803286; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bu4SxdLMWpxoLnQbL2627cHftw9IjBMQ51x3h2IqgLc=; b=I9nYMblRWEYVe5/je2KuB/ODmFSSJ/8vHVw20cDTv+2W7OSKLw7ESGPFJRbGG2oKCwHt5r UxcZK5oiwOVhDcE3LUk5lYWUJuOrrlxWkpBvAxYXhUj8f+7j0x6T+3VJ1sHCZ0ckp8PQLp cucpQ++f8a7rwoJZJ8nDO9ST9OZ+snF3QitsjXJzm7/yzGGQbLIwcO0WOe/mL4qGBMHXV3 E6X9kh/gDa4OcqiCNKnxUp9HhAJ3KP5r2u4EZstKe/mU7GI6sU20SoA7ddQtFgrBWMKAtN KwaEab3pa46YB2aB4L/7Q0RrdwBhRQSoNq11QXnGCiwODUXnrupBgXm3/Ag4Kw== MIME-Version: 1.0 Date: Thu, 30 Oct 2025 07:48:05 +0200 From: Protesilaos Stavrou <prot@HIDDEN> To: Eshel Yaron <me@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <87tszk7ah4.fsf@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> <87ikg5n8mr.fsf@HIDDEN> <2380b90a3a13f10a24789735cfb9e23d@HIDDEN> <877bwit0oq.fsf@HIDDEN> <87a51dboa3.fsf@HIDDEN> <9084bb18711c238f1cbcc524249d661e@HIDDEN> <87tszk7ah4.fsf@HIDDEN> Message-ID: <5ef978de9e8045438f7eb03023f93b59@HIDDEN> X-Sender: prot@HIDDEN Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduieehkedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecunecujfgurhepggffhffvvefujghfkfigtgfgsehtjehjtddttddvnecuhfhrohhmpefrrhhothgvshhilhgrohhsucfuthgrvhhrohhuuceophhrohhtsehprhhothgvshhilhgrohhsrdgtohhmqeenucggtffrrghtthgvrhhnpeettdffhedvkeevffefteejjeefteeuhedtueejfeeguefhhfdvudeludevvdffvdenucfkphepuddtrddvtddtrddvtddurddvheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedutddrvddttddrvddtuddrvdehpdhhvghlohepfigvsghmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehprhhothesphhrohhtvghsihhlrghoshdrtghomhdpnhgspghrtghpthhtohepvddprhgtphhtthhopehmvgesvghshhgvlhihrghrohhnrdgtohhmpdhrtghpthhtohepjeelieejjeesuggvsggsuhhgshdrghhnuhdrohhrgh X-GND-Sasl: prot@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 2025-10-27 15:14, Eshel Yaron wrote: > Hi, Hello again Eshel, I just pushed the change that supports this feature. Thank you for taking the time to explain everything! In short: - Some faces are nil. - Common faces are desatured. > Protesilaos Stavrou <prot@HIDDEN> writes: > >> Thank you! I have been working on it. Some questions and observations: > > Thanks for looking into it! > >> - Is this semantic styling intended to apply as many distinct colours >> as possible? > > Well, not as many as possible, rather just the right amount: > We want to communicate the most important information, so we use > distinct faces for important distinctions. If few people care about a > certain distinction, we might use indistinguishable faces by default. > For example, the analysis can tell apart macros from special forms, but > this distinction is not that important for programmers, so we make the > elisp-special-form face look the same as elisp-macro by default. With this in mind, I made several of those faces nil, while I styled others to look right in context. It is a delicate balancing act. >> [...] >> >> - I get inconsistent results. For example, in the '(rx (zero-or-more >> (or "foo" "bar"...' the 'zero-or-more' gets only the 'elisp-rx' face >> while the 'or' has that face in addition to the >> 'font-lock-keyword-face'. > > That's an artifact of the default highlighting that emacs-lisp-mode > applies (without elisp-fontify-semantically). Note that if you disable > semantic highlighting, that 'or' still gets font-lock-keyword-face, > because the default highlighting mistakes it for an 'or' special form. > That's the source of this inconsistency. > > What effect do you see in practice though? > Note that by default semantic highlighting takes precedence here, which > is why elisp-rx comes first, before font-lock-keyword-face. I arranged to work around this problem. Basically, I wanted to avoid the scenario where I could not predict what the face would look like when, say, font-lock has a bold weight while the semantic face does not. >> [...] >> >> - I expect the keywords to look the same everywhere, but they do >> not. An example: >> >> (let ((arg :one)) >> (unless (memq arg '(:one :two)) >> (error "Something unrelated")) >> (pcase arg >> (:one "one") >> (:two "two"))) >> >> (let ((arg :one)) >> (unless (memq arg '(:one :two)) >> (error "Something unrelated")) >> (cond >> ((eq arg :one) "one") >> ((eq arg :two) "two"))) > > Hmm, all keywords look the same here, which keywords look differently? > Oh, you probably customized elisp-constant so it no longer inherits > from > font-lock-builtin-face, so the quoted keywords seem different... If > so, > that's expected, essentially, but we can discuss it further if you > want, > perhaps in separate bug thread. Again, I worked around this. > [...] > >> - The foreground of the 'elisp-symbol-at-mouse' is ignored. >> The foreground of 'elisp-symbol-at-mouse' should take precedence >> like how the 'highlight' or 'mode-line-highlight' faces work. > > It's not exactly that elisp-symbol-at-mouse works differently from that > face or another, rather it has to do with the way we use this face: > We set the mouse-face property to (FACE elisp-symbol-at-mouse) where > FACE is the face we apply to the symbol (as its 'face' text property, > not the mouse-face property). So properties of FACE override > properties > of elisp-symbol-at-mouse. This creates the nice effect that the symbol > retains its foreground color (specified by FACE) when you hover over > it, > only the background (specified by elisp-symbol-at-mouse) changes. > > Do you think it'd be preferable to change also the foreground color > when > you hover over a symbol? Do you plan to give elisp-symbol-at-mouse a > non-default foreground color? If so, we can add a user option that > would control what we do with the mouse-face property, and the themes > could then set this option. The foreground has to change as well when that is given. Otherwise we are forced to use a background that maintains the expected contrast ratio values for all possible foregrounds. This means that the background must be subtle, which may not even be noticeable anymore in some cases, such as when hl-line-mode is involved. All the best, Prot
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at 79677) by debbugs.gnu.org; 27 Oct 2025 13:14:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 27 09:14:51 2025 Received: from localhost ([127.0.0.1]:48482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vDN3i-0008Hj-4N for submit <at> debbugs.gnu.org; Mon, 27 Oct 2025 09:14:51 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:52208 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1vDN3W-0008HP-Hv for 79677 <at> debbugs.gnu.org; Mon, 27 Oct 2025 09:14:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1761570874; bh=/vD2wylRSFuCzCEFigzls4Y9+rDV1cFJyEDaUDCbvwc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z+KiJuxxIH72A5ozHzUGy/5GiRUJ2umWa/a13dleuUjQxrReeYQOYfD3NFaWxsNl8 EIfSzIx8U04IIhHNKUKZz57YzIyt31OJlVsShyG5MVd4/X+eENXEdz9D6oh9CcsNNR DQOVj5etRuwp0zbZ2ri3o9fwECw0SWvXCp2gZETXU4ftbSt6r//WqpxZBwUb8FJ7zf oRKSGfsK6pQFEjWzG94L3nYa6rFKuR/zvCkIyS/3x/GAPwJLrcB1zKScVDNJxunAon yPFRcoPloxVy0VFo9ayVcwJF64JTjT3UrFTlkZyZRBImtv+KPIqltFMq4e1IavtvJY iwkemfD/fS+VA== From: Eshel Yaron <me@HIDDEN> To: Protesilaos Stavrou <prot@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <9084bb18711c238f1cbcc524249d661e@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> <87ikg5n8mr.fsf@HIDDEN> <2380b90a3a13f10a24789735cfb9e23d@HIDDEN> <877bwit0oq.fsf@HIDDEN> <87a51dboa3.fsf@HIDDEN> <9084bb18711c238f1cbcc524249d661e@HIDDEN> Date: Mon, 27 Oct 2025 14:14:31 +0100 Message-ID: <87tszk7ah4.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi, Protesilaos Stavrou <prot@HIDDEN> writes: > Thank you! I have been working on it. Some questions and observations: Thanks for looking into it! > - Is this semantic styling intended to apply as many distinct colours > as possible? Well, not as many as possible, rather just the right amount: We want to communicate the most important information, so we use distinct faces for important distinctions. If few people care about a certain distinction, we might use indistinguishable faces by default. For example, the analysis can tell apart macros from special forms, but this distinction is not that important for programmers, so we make the elisp-special-form face look the same as elisp-macro by default. > Are users supposed to use this by default, or is it > something akin to a debugging or code analysis mode? It's mostly intended to be a global setting. Typically you'd enable it in your init file and that's it. > How do you envisage it? Sorry if this sounds naive, but I have no > prior experience with such fine-grained highlighting. If it is the > new normal for everyday programming, I think all these faces are > distracting and I will choose to define many of them as nil. I'm not sure that'd be the right thing to do. Note that this is an opt-in feature that users enable to get more visual information (namely, information about what different symbols do/mean), so forgoing highlighting would kinda defeat the purpose of enabling this feature. Users that find the extra highlighting distracting wouldn't turn it on, I presume. :) > - I get inconsistent results. For example, in the '(rx (zero-or-more > (or "foo" "bar"...' the 'zero-or-more' gets only the 'elisp-rx' face > while the 'or' has that face in addition to the > 'font-lock-keyword-face'. That's an artifact of the default highlighting that emacs-lisp-mode applies (without elisp-fontify-semantically). Note that if you disable semantic highlighting, that 'or' still gets font-lock-keyword-face, because the default highlighting mistakes it for an 'or' special form. That's the source of this inconsistency. What effect do you see in practice though? Note that by default semantic highlighting takes precedence here, which is why elisp-rx comes first, before font-lock-keyword-face. > - Another example of two faces being applied is with something like > '(make-directory directory :parents)' where ':parents' gets > 'elisp-constant' in addition to 'font-lock-builtin-face'. Same idea > for every 'defalias' I saw, which gets 'elisp-function' and > 'font-lock-keyword-face'. See above. > - I expect the keywords to look the same everywhere, but they do > not. An example: > > (let ((arg :one)) > (unless (memq arg '(:one :two)) > (error "Something unrelated")) > (pcase arg > (:one "one") > (:two "two"))) > > (let ((arg :one)) > (unless (memq arg '(:one :two)) > (error "Something unrelated")) > (cond > ((eq arg :one) "one") > ((eq arg :two) "two"))) Hmm, all keywords look the same here, which keywords look differently? Oh, you probably customized elisp-constant so it no longer inherits from font-lock-builtin-face, so the quoted keywords seem different... If so, that's expected, essentially, but we can discuss it further if you want, perhaps in separate bug thread. > - There are a few faces that I could not see in context. Where I can > find examples with 'elisp-nnoo-backend', > 'elisp-completion-category', 'elisp-completion-category-definition', > 'elisp-symbol-role', 'elisp-symbol-role-definition'? I wouldn't worry about these too much, since they are used in more obscure contexts. But let's see...: - elisp-nnoo-backend: check out any nnoo-define-basics call, such as the one in lisp/gnus/nntp.el. - elisp-completion-category(-definition): see the define-completion-category call in project.el. You should see both faces in use. - elisp-symbol-role(-definition): see elisp-scope.el, e.g. search for "elisp-scope-define-symbol-role bound-variable". > - The foreground of the 'elisp-symbol-at-mouse' is ignored. > The foreground of 'elisp-symbol-at-mouse' should take precedence > like how the 'highlight' or 'mode-line-highlight' faces work. It's not exactly that elisp-symbol-at-mouse works differently from that face or another, rather it has to do with the way we use this face: We set the mouse-face property to (FACE elisp-symbol-at-mouse) where FACE is the face we apply to the symbol (as its 'face' text property, not the mouse-face property). So properties of FACE override properties of elisp-symbol-at-mouse. This creates the nice effect that the symbol retains its foreground color (specified by FACE) when you hover over it, only the background (specified by elisp-symbol-at-mouse) changes. Do you think it'd be preferable to change also the foreground color when you hover over a symbol? Do you plan to give elisp-symbol-at-mouse a non-default foreground color? If so, we can add a user option that would control what we do with the mouse-face property, and the themes could then set this option. Best, Eshel
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.
Received: (at 79677) by debbugs.gnu.org; 27 Oct 2025 09:35:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 27 05:35:46 2025
Received: from localhost ([127.0.0.1]:47983 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vDJdh-0001pm-MP
for submit <at> debbugs.gnu.org; Mon, 27 Oct 2025 05:35:46 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:49993)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <prot@HIDDEN>)
id 1vDJda-0001p0-Ia
for 79677 <at> debbugs.gnu.org; Mon, 27 Oct 2025 05:35:41 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id A6EBC432C2;
Mon, 27 Oct 2025 09:35:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protesilaos.com;
s=gm1; t=1761557728;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=1x2nIL49lwYcFdqfL8ozCId/4hgnF7DLbrcAAZJ4pRY=;
b=XBsf2zUZeFLGcktXmTFl9S+yUtgTE/nIwauI5MJx+a5y6noJLf+1ca4GmCz1M8SNoW6JdZ
E5h/y5kJpW53aC1N9JbYCz4zIfRo/cQYVsASgZibvNL5lvpDO2FKhJtxAsoUluEl/+29rB
Dg3RqOeiFkZs+cdN+rrc57cT6X5SERHRzcr+TEIUM50vosK/Bq6kAghXJOAa6COJkThzGl
AJL1jjBtRUDwXYYje/r/KcY8SJZixW/p+0RUDxriNJVWF2DxG41Yi96uoY84I/6o6qynoJ
165/teqJ2xtb8dOl+JuaeWYpvMGg4sPN/3JWhNU2iwFkKzrpy/RXEaQtFiRQfQ==
MIME-Version: 1.0
Date: Mon, 27 Oct 2025 11:35:28 +0200
From: Protesilaos Stavrou <prot@HIDDEN>
To: Eshel Yaron <me@HIDDEN>
Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol
highlighting
In-Reply-To: <87a51dboa3.fsf@HIDDEN>
References: <87cy6ekf5f.fsf@HIDDEN>
<3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN>
<87ikg5n8mr.fsf@HIDDEN>
<2380b90a3a13f10a24789735cfb9e23d@HIDDEN>
<877bwit0oq.fsf@HIDDEN> <87a51dboa3.fsf@HIDDEN>
Message-ID: <9084bb18711c238f1cbcc524249d661e@HIDDEN>
X-Sender: prot@HIDDEN
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-GND-State: clean
X-GND-Score: 0
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduheejiedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecunecujfgurhepggffhffvvefujghfkfigtgfgsehtjehjtddttddvnecuhfhrohhmpefrrhhothgvshhilhgrohhsucfuthgrvhhrohhuuceophhrohhtsehprhhothgvshhilhgrohhsrdgtohhmqeenucggtffrrghtthgvrhhnpeettdffhedvkeevffefteejjeefteeuhedtueejfeeguefhhfdvudeludevvdffvdenucfkphepuddtrddvtddtrddvtddurddvjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedutddrvddttddrvddtuddrvdejpdhhvghlohepfigvsghmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehprhhothesphhrohhtvghsihhlrghoshdrtghomhdpnhgspghrtghpthhtohepvddprhgtphhtthhopehmvgesvghshhgvlhihrghrohhnrdgtohhmpdhrtghpthhtohepjeelieejjeesuggvsggsuhhgshdrghhnuhdrohhrgh
X-GND-Sasl: prot@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 79677
Cc: 79677 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
On 2025-10-26 18:50, Eshel Yaron wrote:
>> [...]
>
> Two things I forgot to mention:
>
> 1. By default (with non-nil 'elisp-add-help-echo'), we also add a
> 'mouse-face' property to highlighted symbols, which gives them a
> slightly different background color when you hover over them with
> the mouse, so it might be a good a idea to hover over different
> symbols and see how it looks. The face we use for this is
> 'elisp-symbol-at-mouse'.
>
> 2. If you enable 'cursor-sensor-mode', then whenever point enters a
> local variable we highlight all occurrences of that variable with
> the 'elisp-variable-at-point' face, which by default just inherits
> from 'bold'.
Thank you! I have been working on it. Some questions and observations:
- Is this semantic styling intended to apply as many distinct colours as
possible? Are users supposed to use this by default, or is it something
akin to a debugging or code analysis mode? How do you envisage it? Sorry
if this sounds naive, but I have no prior experience with such
fine-grained highlighting. If it is the new normal for everyday
programming, I think all these faces are distracting and I will choose
to define many of them as nil. But if it is for a special purpose, like
to analyse the code, then all the extra styles are appropriate and I
will style them accordingly.
- I get inconsistent results. For example, in the '(rx (zero-or-more (or
"foo" "bar"...' the 'zero-or-more' gets only the 'elisp-rx' face while
the 'or' has that face in addition to the 'font-lock-keyword-face'.
- Another example of two faces being applied is with something like
'(make-directory directory :parents)' where ':parents' gets
'elisp-constant' in addition to 'font-lock-builtin-face'. Same idea for
every 'defalias' I saw, which gets 'elisp-function' and
'font-lock-keyword-face'.
- I expect the keywords to look the same everywhere, but they do not. An
example:
(let ((arg :one))
(unless (memq arg '(:one :two))
(error "Something unrelated"))
(pcase arg
(:one "one")
(:two "two")))
(let ((arg :one))
(unless (memq arg '(:one :two))
(error "Something unrelated"))
(cond
((eq arg :one) "one")
((eq arg :two) "two")))
- There are a few faces that I could not see in context. Where I can
find examples with 'elisp-nnoo-backend', 'elisp-completion-category',
'elisp-completion-category-definition', 'elisp-symbol-role',
'elisp-symbol-role-definition'?
- The foreground of the 'elisp-symbol-at-mouse' is ignored. The
foreground of 'elisp-symbol-at-mouse' should take precedence like how
the 'highlight' or 'mode-line-highlight' faces work.
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at 79677) by debbugs.gnu.org; 26 Oct 2025 16:50:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 26 12:50:36 2025 Received: from localhost ([127.0.0.1]:46200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vD3wy-0001KA-2X for submit <at> debbugs.gnu.org; Sun, 26 Oct 2025 12:50:36 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:51980 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1vD3wv-0001Jn-Gg for 79677 <at> debbugs.gnu.org; Sun, 26 Oct 2025 12:50:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1761497432; bh=CBotKPpAhxUNo2IOeUwDHGZGmVLn8H22YZUxnLGK+ZU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mei7Gsii1nw8ziSynYYxDx6zou5YdQW7aYPoU4HHlxC6XXlXhqhF83d711nJjxpRr ZtN3NOgDDUdT0dQjPs4E6hn51c9YQc/0PMi5ZYeW68rXueiXhKWQcbR8oEgpzDGcUx pOS/bxQA9wKcjLBcCb7btXnfoywEgiHL6EZ0Tgd8Pyz7wDIPdU1mL3SNruF3ostzt9 zVeByAQ5TQsNT1Br7J4xpt6ltsE/8aRthTqWGRH7QnJxlBCdryNSKwvpWGYLy8GDdt l9AFNX0NY0ySlF1cNVjeAB10dqsHF1PKtdbyLCocvIwV/Y1EQNHyQuHUqSvkX2HinY AGt1Yu8CTBsRg== From: Eshel Yaron <me@HIDDEN> To: Protesilaos Stavrou <prot@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <877bwit0oq.fsf@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> <87ikg5n8mr.fsf@HIDDEN> <2380b90a3a13f10a24789735cfb9e23d@HIDDEN> <877bwit0oq.fsf@HIDDEN> Date: Sun, 26 Oct 2025 17:50:28 +0100 Message-ID: <87a51dboa3.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi, Eshel Yaron <me@HIDDEN> writes: > Protesilaos Stavrou <prot@HIDDEN> writes: > >> Very well! Please send me the examples and I will make the changes >> right away. > > Great, here's a snippet that showcases the most important faces: > > [...] > > Put it in an 'emacs-lisp-mode' buffer, make sure the buffer is "trusted" > (e.g. by setting 'trusted-content' to ':all' buffer-locally), and set > 'elisp-fontify-semantically' to non-nil. > > You should be able to see the following faces in action: > [...] Two things I forgot to mention: 1. By default (with non-nil 'elisp-add-help-echo'), we also add a 'mouse-face' property to highlighted symbols, which gives them a slightly different background color when you hover over them with the mouse, so it might be a good a idea to hover over different symbols and see how it looks. The face we use for this is 'elisp-symbol-at-mouse'. 2. If you enable 'cursor-sensor-mode', then whenever point enters a local variable we highlight all occurrences of that variable with the 'elisp-variable-at-point' face, which by default just inherits from 'bold'. Eshel
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.
Received: (at 79677) by debbugs.gnu.org; 26 Oct 2025 10:30:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 26 06:30:37 2025
Received: from localhost ([127.0.0.1]:44279 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vCy1F-0002hE-Eh
for submit <at> debbugs.gnu.org; Sun, 26 Oct 2025 06:30:37 -0400
Received: from mail.eshelyaron.com ([107.175.124.16]:46410 helo=eshelyaron.com)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1vCy1D-0002aU-9P
for 79677 <at> debbugs.gnu.org; Sun, 26 Oct 2025 06:30:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1761474634;
bh=IDD8KgGE6PFSxKfUrE/xh4tTwKmGtVgTfQdb11t/1UY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=gWgbdEHWHw20+RDC/5fMx1qJRuth0XZGY3Olt1vQ6ZgEERjlrg702ovXI1XXfysWc
6/gXf22keVN9IVQ6mdMeuopv94jhwQnua0uphHsncae42ciBltllATRrXg4jWC9Upu
VWXL/H3XEr0lF3HCK+yHQgGJQBdj4aAK9VQpD7XbiarN/iP46loGmQhwkq277ZB52e
qSU93v3H42cpvcJx9FBVIuNYNSvqpWpPdm541dGeo0BKAx16DsgM1T6fsk0MU2xZOk
HJF5iXclGwacYImOKRo/47Igp/xkKScx8N5UatK1xAKJiA+6TeId5P2Us9vL1EsfKz
pkEPpgxWqyUaA==
From: Eshel Yaron <me@HIDDEN>
To: Protesilaos Stavrou <prot@HIDDEN>
Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic
symbol highlighting
In-Reply-To: <2380b90a3a13f10a24789735cfb9e23d@HIDDEN>
References: <87cy6ekf5f.fsf@HIDDEN>
<3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN>
<87ikg5n8mr.fsf@HIDDEN>
<2380b90a3a13f10a24789735cfb9e23d@HIDDEN>
Date: Sun, 26 Oct 2025 11:30:29 +0100
Message-ID: <877bwit0oq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79677
Cc: 79677 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hi Prot,
Protesilaos Stavrou <prot@HIDDEN> writes:
> On 2025-10-23 14:46, Eshel Yaron wrote:
>>> [...]
>>> I am happy to make changes. There are a lot of faces though and I
>>> need
>>> to test them thorougly.
>> Thank you. Let me know if you need some example snippets for
>> testing.
>
> Very well! Please send me the examples and I will make the changes
> right away.
Great, here's a snippet that showcases the most important faces:
--8<---------------cut here---------------start------------->8---
(defvar foo-variable nil "Variable.")
(defun foo-function (bar &optional baz)
"Function with arguments BAR and BAZ."
(interactive nil lisp-mode)
(if (string-match (rx (zero-or-more (or "foo" "bar"))) bar)
(let ((exec-path nil)
(cpa current-prefix-arg))
(vector major-mode exec-path cpa))
(ignore-error end-of-file
(catch 'ball
(ignore (face-attribute 'success :foreground) baz 'qux)
(throw 'ball (spam t))))))
--8<---------------cut here---------------end--------------->8---
Put it in an 'emacs-lisp-mode' buffer, make sure the buffer is "trusted"
(e.g. by setting 'trusted-content' to ':all' buffer-locally), and set
'elisp-fontify-semantically' to non-nil.
You should be able to see the following faces in action:
'defvar' gets 'elisp-special-form'
'foo-variable' gets 'elisp-defvar'
'defun' gets 'elisp-macro'
'foo-function' gets 'elisp-defun'
'bar' gets 'elisp-binding-variable'
'&optional' gets 'elisp-ampersand'
'lisp-mode' gets 'elisp-major-mode-name'
'string-much' gets 'elisp-function'
'rx' gets 'elisp-macro'
'zero-or-more' gets 'elisp-rx'
'exec-path' gets 'elisp-shadowing-variable'
'cpa' gets 'elisp-binding-variable'
'major-mode' gets 'elisp-free-variable'
'exec-path' gets 'elisp-shadowed-variable' (second occurrence of 'exec-path')
'end-of-file' gets 'elisp-condition'
'ball' gets 'elisp-throw-tag'
'success' gets 'elisp-face'
':foreground' gets 'elisp-constant'
'throw' gets 'elisp-non-local-exit'
'spam' gets 'elisp-unknown-call'
Thanks,
Eshel
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at 79677) by debbugs.gnu.org; 24 Oct 2025 05:34:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 24 01:34:10 2025 Received: from localhost ([127.0.0.1]:34774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vCARG-0008Nb-7r for submit <at> debbugs.gnu.org; Fri, 24 Oct 2025 01:34:10 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:44823) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <prot@HIDDEN>) id 1vCARE-0008N2-0d for 79677 <at> debbugs.gnu.org; Fri, 24 Oct 2025 01:34:08 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2ECAC4430E; Fri, 24 Oct 2025 05:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protesilaos.com; s=gm1; t=1761284040; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9Vqt2ubW3qD++n6wBw7XfWKm+UuCBDx6S9VtxUkThVQ=; b=DS7zCvhU1O1QKdRQR+PF91nHjwuxp3Q/QxYp3Y8pIHJG9v+HuYFJuB4304k5jmNtkm6ipi WisaHQHYMrk4cVBcduX3LRWm+wFNGL2yz5uGMR70xDDzyi0Z5HOGg8VT/+gDAcYZ+1quDy 5WJPMAH3J6QrO+dINaJoSZr44BH8Q2wgBnxZEc2JgFd6/fCmohPr9XIR+wDm4uB/AqdM3N JP4fosxQnlKM0qLS6j4JJ7Z1WRDQ4x01ftdLVEjEf2n5lKInbB810ItlGLAQxO/yMAdqBm DDeZMIqoMmRNodDGUqdORF7p3c8Yn12YSXOPKbqUe2TxMSNBJXjuWkleOQevyw== MIME-Version: 1.0 Date: Fri, 24 Oct 2025 08:33:59 +0300 From: Protesilaos Stavrou <prot@HIDDEN> To: Eshel Yaron <me@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <87ikg5n8mr.fsf@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> <87ikg5n8mr.fsf@HIDDEN> Message-ID: <2380b90a3a13f10a24789735cfb9e23d@HIDDEN> X-Sender: prot@HIDDEN Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-GND-Sasl: prot@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 2025-10-23 14:46, Eshel Yaron wrote: >> [...] >> >> I am happy to make changes. There are a lot of faces though and I need >> to test them thorougly. > > Thank you. Let me know if you need some example snippets for testing. Very well! Please send me the examples and I will make the changes right away.
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at 79677) by debbugs.gnu.org; 23 Oct 2025 11:46:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 23 07:46:30 2025 Received: from localhost ([127.0.0.1]:60221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBtm1-0004tN-OD for submit <at> debbugs.gnu.org; Thu, 23 Oct 2025 07:46:30 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:45044 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1vBtlx-0004sy-Qp for 79677 <at> debbugs.gnu.org; Thu, 23 Oct 2025 07:46:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1761219984; bh=2yo1nMc/PGG8zCdDPUlONTFW2awhAaPAL9Em4Ckt2no=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I7njItAlziA6E4G97068Y0/oX5iBBdI/Wlxau71bL3TJWFosUSoiQ34M7dMNUbE32 R3yhThkYvkGspjGsy9TxWuPwpGCd9MoSTCVHn4sIaGjL3sWPF0Z+CkypNFm7eHNCSP WTzYbkl+0G8gs75dNDIRgJ8hlHK/ySQvMlkk13vYISP3zTccwRTi9lGAFurWEcC6GG QOslI5QVjr3p4uTWhKgJC+lWktTG3rOVoJxezUtcZIjiA0IudBAdUADw4/NBZFkqpY 3Gtnp9N3BxXYjSMyaqIqg/I6JwSedAoXMXCyozA9RZtsSCZKrX2yewe84c1Tj+kAQp 2BQUbkDp56ZoA== From: Eshel Yaron <me@HIDDEN> To: Protesilaos Stavrou <prot@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> Date: Thu, 23 Oct 2025 13:46:20 +0200 Message-ID: <87ikg5n8mr.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Protesilaos Stavrou <prot@HIDDEN> writes: > On 2025-10-22 20:41, Eshel Yaron wrote: >> Hi Prot, all, > > Hello Eshel, > >> [...] >> Request: >> Built-in themes should "support" these new faces to produce the best >> user experience. Namely, I think it'd be great if the modus themes >> could support these faces, since these themes are very popular. I >> don't >> know about any specific issues with using the new highlighting feature >> with modus or other themes, so it's possible that no customization >> is actually required, but I suspect that there's room for some tweaks. >> We can also look into refining the new face definitions if there are >> concrete changes that would make it easier for themes to support them. > > I am happy to make changes. There are a lot of faces though and I need > to test them thorougly. Thank you. Let me know if you need some example snippets for testing. > Overall, what is there is fine in terms of face definitions. Though > there are a few that apply specific colour values. I think it is > safer to always inherit from font-lock faces, as those as covered by > virtually all themes. We can't rely only on the existing font-lock faces, because we want to provide more information than this set of faces can currently carry. That's a major attraction of this feature: you enable it to see richer symbol highlighting. So in order to provide the same benefit for users of a certain theme, the theme needs to preserve these new distinctions. If we'd strictly stick to the lowest common denominator of existing font-lock faces, we'd be forfeiting this added benefit to begin with. > Yes, this means that something like 'elisp-major-mode-name' will not > necessarily stand out by default, though I believe it is better to > have maximum compatibility with theme/user settings than to assume the > given colour works everywhere. To be clear, as far as we know, the faces work well by default. If some face does not work well in context with the "default theme", then that's a bug to be fixed. So you might say that we assume it works, yes, but only in the same sense that we assume any feature works as long as people use it and no bugs are reported. But we only "assume" it works everywhere *by default*, not necessarily with every theme. Of course, many users depart from the defaults and do use some theme, and ideally they should get the best experience as well, hence this request. :) Best, Eshel
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at 79677) by debbugs.gnu.org; 23 Oct 2025 05:14:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 23 01:14:38 2025 Received: from localhost ([127.0.0.1]:59289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBneo-0004M8-IU for submit <at> debbugs.gnu.org; Thu, 23 Oct 2025 01:14:38 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:47469) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <prot@HIDDEN>) id 1vBnel-0004La-J4 for 79677 <at> debbugs.gnu.org; Thu, 23 Oct 2025 01:14:37 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 25F5020083; Thu, 23 Oct 2025 05:14:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protesilaos.com; s=gm1; t=1761196468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uKeJbhrJWw4LgVBcsK80vl8e+vetIce2UwdBV70LQ78=; b=ienn2uR5PV8O9+tmlzP2vp4JSf2W/HgW81lRWu3B46Zptn/HqUHJbxzi8xEX3iQfum7xYy Se/p+7XyWxqmORWf8OgGejJ+s7lmj/0ENCSKcPDWvIzf2GvKbaMEsByEXw1yvGmldDDrk3 pAgnzXax4YJipVvvcOXSO39zZxWoXsjnCMTzKF6bBQyzuPu7jke3zVC8Fx7ZGtYkeqJGUt n+VVbbdYyX/ePWZBIv8owRC2vvrVtJorxZ9ueW+0nmJM92OaeIz8mjjMlx5LlhXEyaHxCE sp6FZx0OhKXLSV0cc/B9ONTrWvr5H52MOyJjkp2UdsGY6hcAgLGbfGA36LSrRg== MIME-Version: 1.0 Date: Thu, 23 Oct 2025 08:14:27 +0300 From: Protesilaos Stavrou <prot@HIDDEN> To: Eshel Yaron <me@HIDDEN> Subject: Re: bug#79677: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting In-Reply-To: <87cy6ekf5f.fsf@HIDDEN> References: <87cy6ekf5f.fsf@HIDDEN> Message-ID: <3f8d49a4b659e159aa1fd14edd1623bf@HIDDEN> X-Sender: prot@HIDDEN Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-GND-Sasl: prot@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79677 Cc: 79677 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 2025-10-22 20:41, Eshel Yaron wrote: > Hi Prot, all, Hello Eshel, > [...] > > Request: > > Built-in themes should "support" these new faces to produce the best > user experience. Namely, I think it'd be great if the modus themes > could support these faces, since these themes are very popular. I > don't > know about any specific issues with using the new highlighting feature > with modus or other themes, so it's possible that no customization > is actually required, but I suspect that there's room for some tweaks. > We can also look into refining the new face definitions if there are > concrete changes that would make it easier for themes to support them. I am happy to make changes. There are a lot of faces though and I need to test them thorougly. Overall, what is there is fine in terms of face definitions. Though there are a few that apply specific colour values. I think it is safer to always inherit from font-lock faces, as those as covered by virtually all themes. Yes, this means that something like 'elisp-major-mode-name' will not necessarily stand out by default, though I believe it is better to have maximum compatibility with theme/user settings than to assume the given colour works everywhere. Have a nice day, Prot
bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 22 Oct 2025 17:41:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 22 13:41:56 2025 Received: from localhost ([127.0.0.1]:57691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBcqR-0004SF-NE for submit <at> debbugs.gnu.org; Wed, 22 Oct 2025 13:41:55 -0400 Received: from lists.gnu.org ([2001:470:142::17]:56468) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1vBcqJ-0004Rc-TV for submit <at> debbugs.gnu.org; Wed, 22 Oct 2025 13:41:50 -0400 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 <me@HIDDEN>) id 1vBcqB-0001Eo-Ru for bug-gnu-emacs@HIDDEN; Wed, 22 Oct 2025 13:41:39 -0400 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1vBcq8-0003vs-Lg for bug-gnu-emacs@HIDDEN; Wed, 22 Oct 2025 13:41:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1761154895; bh=AYDnChLPoZI5zdJFfmbwqKxPyp5vomTWwEz8HgYe+oE=; h=From:To:Subject:Date:From; b=DiWjF4CPih15d4XFG4QyfeqIQ1XRTSnMvF3785DSzNMLer7xIWG97+2Hvzd92xXDq 29yN/PmCL8VX01pnNs8z9w1/hYEgNdxSXKrnzXUM32ZCexME6K9tNkkPfk+5GyYhTG XVbLp5ACezrg7zysYaWI2BoM310dGVcAEwwWtQrIJH9BmLPYkjg5kLxNAhAi5+4/JF 7Pys7Al28uzgNMzycBrofDH2ESopEfwlZCASohqmUaAdRgLWlSjP4Z+wjXUM7wLPC8 JKe/EFW0wLzmXei/yKFo6quEAcDkAB9pz/eCU+uewof0yJK3i3EIEgwrwR9lNHqAUG Wi4JAXtsC+9qQ== From: Eshel Yaron <me@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 31.0.50; [FR] Theme support for ELisp semantic symbol highlighting X-Debbugs-Cc: Protesilaos Stavrou <prot@HIDDEN> Date: Wed, 22 Oct 2025 19:41:32 +0200 Message-ID: <87cy6ekf5f.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) Hi Prot, all, Background: We've recently added a new highlighting feature to emacs-lisp-mode which uses code analysis to provide richer and more precise highlighting. See (info "(emacs) Semantic Font Lock") and the variable elisp-fontify-semantically for details. This highlighting uses various new 'elisp-*' faces that correspond to the semantic "roles" that the analysis assigns to symbols. Most new faces ultimately inherit from an existing 'font-lock-*' face, but some new faces use bespoke foreground colors etc. Request: Built-in themes should "support" these new faces to produce the best user experience. Namely, I think it'd be great if the modus themes could support these faces, since these themes are very popular. I don't know about any specific issues with using the new highlighting feature with modus or other themes, so it's possible that no customization is actually required, but I suspect that there's room for some tweaks. We can also look into refining the new face definitions if there are concrete changes that would make it easier for themes to support them. Thanks and best regards, Eshel
Eshel Yaron <me@HIDDEN>:prot@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.prot@HIDDEN, bug-gnu-emacs@HIDDEN:bug#79677; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.