From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jostein_Kj=c3=b8nigsen?= Newsgroups: gmane.emacs.devel Subject: Re: bat-mode: Inconsistent fontification. Consider using font-lock-function-name-face Date: Wed, 18 Sep 2019 21:21:08 +0200 Message-ID: <679d52b7-577c-44b7-1f55-10a857b7e00e@secure.kjonigsen.net> References: <3668c95a-d8a0-1e31-c663-297ac684a8f1@secure.kjonigsen.net> <8336h42ocy.fsf@gnu.org> <72cef0cb-d24b-4510-b73d-eced05d40bc0@www.fastmail.com> <83v9u010q8.fsf@gnu.org> <87imq02aq9.fsf@gmx.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AFBE87FEF9C83847F7EB9FB2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="130354"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0 Cc: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= , Andy Moreton , Ergus , emacs-devel@gnu.org, monnier@iro.umontreal.ca, jostein@kjonigsen.net To: Michael Albinus , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 18 21:22:03 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 1iAfWb-000Xf5-Vp for ged-emacs-devel@m.gmane.org; Wed, 18 Sep 2019 21:22:02 +0200 Original-Received: from localhost ([::1]:34684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAfWa-0003pG-Kp for ged-emacs-devel@m.gmane.org; Wed, 18 Sep 2019 15:22:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59937) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAfVu-0003p2-Lk for emacs-devel@gnu.org; Wed, 18 Sep 2019 15:21:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iAfVt-0006Hx-4B for emacs-devel@gnu.org; Wed, 18 Sep 2019 15:21:18 -0400 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:51235) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iAfVq-0006Ec-Oy; Wed, 18 Sep 2019 15:21:15 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 11E02589; Wed, 18 Sep 2019 15:21:12 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 18 Sep 2019 15:21:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type; s=fm1; bh=Om55ND9L8 kla5tO4uY9fIsgF9KIFHtRMgEUttC13vNo=; b=bPLqhWFDQ1x72WAZV10BZ7mlJ cKhOp4sTUFWQ3KMZIBdvpBB5nTlQKPMFC1BXO9m9DjYen/KmFHmZ9nimHjX22Dhc jHeu8s1eL5IBpq6ZBLvSSBe4BiJngJMafz2wRbwgm3K6hMvfHg3KaZu5at6H+7mg fCczpLuhey01UxRdCETYoILRa6wQyKeM0KyGekPyynw4kj4QCqgIuLMRpFlhC7e0 sTOZ56oRRvgTU2DRJGcPuTRnsCMbnPJZW3M/TcX1dtj+a4z+8GslmkEcqOlLwBWA KQM9AiqIAfiWl/uTDWdocSoHxkmTjjlWYK7qAjgc1Ih+D+ulAGz2GXXKePGhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Om55ND 9L8kla5tO4uY9fIsgF9KIFHtRMgEUttC13vNo=; b=orHc2kVTAvLfkNSWpqc1ry 4TWFkoD/D370iO36jaxKWMWW/GKGWyQOlwbDjQUnfcx4Q2YlyO7kmsIO6xRLP6Hn 5fl/ib8iVpjepEHktB3Rtj7fYkr7jFuvk47VuSzutM7ucu/YTw7UCE2xrCTzUmAf dh7wxrV+u5cmErTQz6k/KT/fR2m1KBhRXXguffEHG2mTBztcnnagz00vLq2GFZF3 eL6JBlOP7iaIj/pGecY5ktTi5Y++/S/CvXlF3+CrlWe9PNfpCK3uxrl/xiSz8CBR wEDR3pJXw8Y0utSPXfAoeGGeRuR6oFkUOOjVywzYJsacuCMVpwRzN1SoSnxSJT9w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekgddufeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpeflohhsthgv ihhnpgfmjhppnhhighhsvghnuceojhhoshhtvghinhesshgvtghurhgvrdhkjhhonhhigh hsvghnrdhnvghtqeenucffohhmrghinhepnhhighhsvghnrdhnohdpghhnuhdrohhrghen ucfkphepkeegrddvuddurdefvddruddvkeenucfrrghrrghmpehmrghilhhfrhhomhepjh hoshhtvghinhesshgvtghurhgvrdhkjhhonhhighhsvghnrdhnvghtnecuvehluhhsthgv rhfuihiivgeptd X-ME-Proxy: Original-Received: from [192.168.1.110] (cm-84.211.32.128.getinternet.no [84.211.32.128]) by mail.messagingengine.com (Postfix) with ESMTPA id 20145D6005A; Wed, 18 Sep 2019 15:21:10 -0400 (EDT) In-Reply-To: <87imq02aq9.fsf@gmx.de> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.147.123.20 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:240152 Archived-At: This is a multi-part message in MIME format. --------------AFBE87FEF9C83847F7EB9FB2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/10/19 9:49 PM, Michael Albinus wrote: > Eli Zaretskii writes: > >> The moment new faces are added I expect users to start complaining >> that these faces are not supported by this and that foo-mode. So mode >> authors aren't forced to implement them only in theory, IMO. > For modes in elpa, there is also the backward compatibility problem. So > they cannot feel forced to apply such new faces directly. > > Asking for similar faces for similar syntactic entities in different > modes is legitimate. IMHO. > > These new faces give mode authors a hint how to provide own customized > faces as long as necessary. And moving to the new faces will happen over > the years only. > > Best regards, Michael. Thanks everyone for your feedback. I've been quite busy the last few weeks, so sorry my lack of response. So to sum up the responses I've gotten so far: - personally would appreciate more default font-lock faces to better differentiate between things which are semanticly different, - don't personally have a need for additional default font-lock faces, but don't see anything wrong with it. - critical of the pressure and expectations adding more default-faces would put on major-mode authors. I'll be optimistic and consider that a slight majority in favour of moving forwards. Based on the discussion so far, my proposal last year[1], not to mention the recent parallell thread started by Ergus[2] we have at least these candidates: - font-lock-decorator-face - font-lock-number-face - font-lock-label-face (font-lock-label-reference-face?) - font-lock-function-name-face (font-lock-function-reference-face) - font-lock-function-declaration-face Is that a reasonable list of faces to add? Is it OK for me at this point to create a patch for this, or should that list undergo further discussion first? The advice I received last time[1] I asked about adding faces was that I would need to: - clarify usage of these modes precisely - add them to font-lock.el - document this in the proper **/*.texi files - add news of these additions to ETC/news Does that still hold true? [1] https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00258.html [2] https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00194.html -- Kind regards *Jostein Kjønigsen* jostein@kjonigsen.net 🍵 jostein@gmail.com https://jostein.kjønigsen.no --------------AFBE87FEF9C83847F7EB9FB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 9/10/19 9:49 PM, Michael Albinus wrote:
Eli Zaretskii <eliz@gnu.org> writes:


The moment new faces are added I expect users to start complaining
that these faces are not supported by this and that foo-mode.  So mode
authors aren't forced to implement them only in theory, IMO.

For modes in elpa, there is also the backward compatibility problem. So
they cannot feel forced to apply such new faces directly.

Asking for similar faces for similar syntactic entities in different
modes is legitimate. IMHO.

These new faces give mode authors a hint how to provide own customized
faces as long as necessary. And moving to the new faces will happen over
the years only.

Best regards, Michael.

Thanks everyone for your feedback. I've been quite busy the last few weeks, so sorry my lack of response.

So to sum up the responses I've gotten so far:

- personally would appreciate more default font-lock faces to better differentiate between things which are semanticly different,
- don't personally have a need for additional default font-lock faces, but don't see anything wrong with it.
- critical of the pressure and expectations adding more default-faces would put on major-mode authors.

I'll be optimistic and consider that a slight majority in favour of moving forwards.

Based on the discussion so far, my proposal last year[1], not to mention the recent parallell thread started by Ergus[2] we have at least these candidates:

- font-lock-decorator-face
- font-lock-number-face
- font-lock-label-face (font-lock-label-reference-face?)
- font-lock-function-name-face (font-lock-function-reference-face)
- font-lock-function-declaration-face

Is that a reasonable list of faces to add? Is it OK for me at this point to create a patch for this, or should that list undergo further discussion first?

The advice I received last time[1] I asked about adding faces was that I would need to:

- clarify usage of these modes precisely
- add them to font-lock.el
- document this in the proper **/*.texi files
- add news of these additions to ETC/news

Does that still hold true?

[1] https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00258.html
[2] https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00194.html


--
Kind regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no
--------------AFBE87FEF9C83847F7EB9FB2--