From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: compilation-mode, face, font-lock-face Date: Thu, 2 Feb 2017 21:43:18 +0100 Message-ID: References: <86bmuk27bv.fsf@stephe-leake.org> <87tw8ckdxo.fsf@drachen> <867f581qwq.fsf@stephe-leake.org> <9900a3e7-0c34-47ed-92df-e822e7089859@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114dcffa1dbfdf0547923738 X-Trace: blaine.gmane.org 1486068244 8671 195.159.176.226 (2 Feb 2017 20:44:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Feb 2017 20:44:04 +0000 (UTC) Cc: Stephen Leake , Drew Adams , emacs-devel To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 02 21:43:55 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZOEV-0001sK-GP for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2017 21:43:55 +0100 Original-Received: from localhost ([::1]:58937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZOEa-00053C-Uk for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2017 15:44:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZODx-00052c-D9 for emacs-devel@gnu.org; Thu, 02 Feb 2017 15:43:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZODw-0001OX-65 for emacs-devel@gnu.org; Thu, 02 Feb 2017 15:43:21 -0500 Original-Received: from mail-vk0-x232.google.com ([2607:f8b0:400c:c05::232]:32814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZODw-0001Ng-0d for emacs-devel@gnu.org; Thu, 02 Feb 2017 15:43:20 -0500 Original-Received: by mail-vk0-x232.google.com with SMTP id k127so19464231vke.0 for ; Thu, 02 Feb 2017 12:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vo9EmnSC1XrDLt7Qod6Y0pwEBDMFSPaF3ADC6cC86hw=; b=EBniO0cP27Xc1mHzBh9tDBoSxlpLPOQ/UyUDHDAR+btK02DFFUQe2xrbVRISn5M1OY uUI+/sjQwYEJo31mq40Yc4V2ymJUpYjs3ujz8Ib7poXGHpoxxKVP045/YSd1kXIVUf19 jMXujamFrusKV8t3NaGUdH7nJdJ+hgPIsL3dMHcwxq4r9FqSJtz+/Btm0gAwHVmBp0Pc g1ZagXHGZGihjrIo/oET1kwi160kYFK2R1C8iOk8eTt8IPjfnGg1ugHCgWLbN5PwUpJG VdmCJOe1dBV21zIeWIBEzi7/IpCvy98PNBIwSO3PNujkWT/2ZS2tYnaIslziKJkZtbhj U+Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vo9EmnSC1XrDLt7Qod6Y0pwEBDMFSPaF3ADC6cC86hw=; b=HBPT5bRV2OGTOf/abJCmwtkobNJ+R0H5yr2cd8wwsHYZ+6UwiX2TxCzhDOBCRW92i0 yNOVrhN7oDCOD6VAhBa57kUqywQFZiBmyHVUAIIVF6MUTQraOgL13y5238zNR4aW9VYK 8aj59xPfEbfiXJxaJnn85/VMykT//cLS8YqlFXnX16SRYNFvR429svdr7ENQDAGrUs7C gcZmb4W4pkmMq7r7VsW3/YEYZbq07J9fZ8SiNJiBXbwSm8w5Nysa24aqQCrswWwfNyiW SmYD6v6TGCEprONhmSkMriVAMfwfdXGfh/c0A0e6VWLXC03p9OBQcr9qoF0lAlACGvxb 6edw== X-Gm-Message-State: AIkVDXKBRXKQ9LmTB5ZBTdYhSsVIYbUmcipb/9vOc+8nBqyzlNxCzUmHr9fGF98jARStb42eUQuITWY5Ief8AA== X-Received: by 10.31.205.133 with SMTP id d127mr4910611vkg.18.1486068199044; Thu, 02 Feb 2017 12:43:19 -0800 (PST) Original-Received: by 10.31.52.129 with HTTP; Thu, 2 Feb 2017 12:43:18 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:211892 Archived-At: --001a114dcffa1dbfdf0547923738 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 2, 2017 at 8:31 PM, Davis Herring wrote: > OK, I can understand that if there is no display then there >> _cannot_ be any font-locking, so the `noninteractive' test >> makes sense, I guess. >> > > Even that is questionable -- there are many (unfortunate) situations in > which font-lock is used to apply syntactically meaningful properties to the > text that might then be used by Lisp programs. It's fine if font-lock > skips configuring the lack of display, of course, and it could be OK for it > to skip setting the face property (since a program that depended on > examining it could be said to be broken). But even then, what if a > non-interactive Emacs is supposed to be running tests of font-lock itself? Fortunately, it's easy to bypass this test. `font-lock-fontify-region` can be called explicitly to add highlighting even in batch mode. Alternatively, `noninteractive` is a variable that can be bound to another value. For example, I do the following in one of my packages*: (let ((noninteractive nil)) (font-lock-mode 1)) *) "e2ansi", a package that converts text with face information into ANSI sequences. You can configure "less" to run an emacs in batch mode to add syntax highlighting to anything viewed in the terminal. See the environment variable LESSOPEN and https://github.com/Lindydancer/e2ansi for more information. But even then, what if a non-interactive Emacs is supposed to be running > tests of font-lock itself? Funny you should ask. I just published a collection of tests for font-lock the other day. It consists of real-world source files in various programming languages and font-lock reference files in "faceup" format. It run fine in batch mode as well as in the GUI. See https://github.com/Lindydancer/font-lock-regression-suite and https://github.com/Lindydancer/faceup for more information. -- Anders --001a114dcffa1dbfdf0547923738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 2, 2017 at 8:31 PM, Davis Herring <herring@lanl.gov> = wrote:
OK, I can understand that if there is no display then there
_cannot_ be any font-locking, so the `noninteractive' test
makes sense, I guess.

 Even that is questionable -- there are many (unfortunate) situations in whi= ch font-lock is used to apply syntactically meaningful properties to the te= xt that might then be used by Lisp programs.=C2=A0 It's fine if font-lo= ck skips configuring the lack of display, of course, and it could be OK for= it to skip setting the face property (since a program that depended on exa= mining it could be said to be broken).=C2=A0 But even then, what if a non-i= nteractive Emacs is supposed to be running tests of font-lock itself?

Fortunately, it's easy to bypass this test. = `font-lock-fontify-region` can be called explicitly to add highlighting eve= n in batch mode. Alternatively, `noninteractive` is a variable that can be = bound to another value. For example, I do the following in one of my packag= es*:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((noninteracti= ve nil))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (font-lock-mod= e 1))

*) "e2ansi", a pac= kage that converts text with face information into ANSI sequences. You can = configure "less" to run an emacs in batch mode to add syntax high= lighting to anything viewed in the terminal. See the environment variable L= ESSOPEN and https://github.com/Lindydancer/e2ansi=C2=A0for more informati= on.


But even then, what if a non-interactive Emacs is suppos= ed to be running tests of font-lock itself?

Funny you should ask. I just published a collection of tests for fon= t-lock the other day. It consists of real-world source files in various pro= gramming languages and font-lock reference files in "faceup" form= at. It run fine in batch mode as well as in the GUI. See https://github.com/Lind= ydancer/font-lock-regression-suite and=C2=A0https://github.com/Lindydancer/faceup for more i= nformation.

=C2=A0 =C2=A0 -- Anders
=
--001a114dcffa1dbfdf0547923738--