From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel,gmane.emacs.help Subject: Re: Bug in Elisp font-locking Date: Fri, 20 Mar 2015 19:47:13 +0100 Message-ID: <878uersdzi.fsf@gnu.org> References: <878uerem09.fsf@gmail.com> <87d243si1c.fsf_-_@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426877272 24369 80.91.229.3 (20 Mar 2015 18:47:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Mar 2015 18:47:52 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 20 19:47:41 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YZ1x9-00061c-0x for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 19:47:27 +0100 Original-Received: from localhost ([::1]:45154 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ1x7-000116-UI for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 14:47:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ1x4-0000yR-ER for emacs-devel@gnu.org; Fri, 20 Mar 2015 14:47:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ1x0-0007wh-DQ for emacs-devel@gnu.org; Fri, 20 Mar 2015 14:47:22 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:43491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ1x0-0007wX-5i for emacs-devel@gnu.org; Fri, 20 Mar 2015 14:47:18 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 27B5E206C1 for ; Fri, 20 Mar 2015 14:47:15 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 20 Mar 2015 14:47:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:to:cc:subject:references :date:in-reply-to:message-id:mime-version:content-type; s= smtpout; bh=IxhvJH+a6qpizoIuxHgA+vu3xdQ=; b=d55PH20QhGsGiig20Qw7 mEiZEEvTEuDY22SnHfzS4Iexk0YMjBpzy3YcwPJoNuQDLFzIFQa9wVztwytgB4go vwfElz0COlKmqfWTWxKF4QZ+LTmNpyTKljvR6zpZzEomRR+KrK1iN4wrO0nTlD6G bdiTa3hZGlbzm06wBMuOfzg= X-Sasl-enc: hIGdb8/Y+H2fYHUhMrJ7TxDwZanOmODADr/MEUbKczpk 1426877236 Original-Received: from thinkpad-t440p (unknown [2.161.210.144]) by mail.messagingengine.com (Postfix) with ESMTPA id 32F87C00021; Fri, 20 Mar 2015 14:47:16 -0400 (EDT) Mail-Followup-To: Stefan Monnier , emacs-devel@gnu.org, help-gnu-emacs@gnu.org In-Reply-To: (Stefan Monnier's message of "Fri, 20 Mar 2015 13:31:26 -0400") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.111.4.27 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184052 gmane.emacs.help:103230 Archived-At: Stefan Monnier writes: >>>> (defun lh/gen-predicate (label) >>>> (defalias (intern (concat "lh/" label "-p")) >>> ^^^^^^ >>> In this case intern should not be highlighted, isn't it ?. > > Indeed. > >> (defstruct struct-name ...) >> (defstruct (struct-name OPTIONS) ...) > > Also for defun in Common-Lisp, there's (defun (setf foo) ...) where > the "setf" probably shouldn't be highlighted but the "foo" should. The `setf' should be highlighted as a macro but not as function name as it is right now. >> Cc-ing emacs-devel to ask if that's ok to commit. > > Could explain what the patch does? Instead of skipping over whitespace and opening parens between the definition macro/function and the defined thing's name, it skips only over whitespace but captures an optional opening paren. If there's one, then we don't font-lock with `font-lock-function-name-face'. The valid cases where the definition macro/function defines a type like in `cl-defstruct' still highlights the symbol after the paren (but in `font-lock-type-face'). Or in simpler words: if the name appears after an opening paren, that cannot be a function name so don't font-lock as such. Bye, Tassilo