From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: cc-mode: Make all parameters introduced in Emacs 26 optional Date: Sat, 30 Mar 2019 16:17:25 -0400 Message-ID: References: <1516608561.1943450.1243462056.1A47A60F@webmail.messagingengine.com> <20180122203254.GA4888@ACM> <87k1vuwr3p.fsf@ahungry.com> <87fu6iwqfu.fsf@ahungry.com> <20180203114451.GA4806@ACM> <20190330135148.GA6312@ACM> <20190330194204.GB6312@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="134337"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 30 21:18:35 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hAKR1-000Yr0-H2 for ged-emacs-devel@m.gmane.org; Sat, 30 Mar 2019 21:18:35 +0100 Original-Received: from localhost ([127.0.0.1]:37971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAKR0-0002r6-IM for ged-emacs-devel@m.gmane.org; Sat, 30 Mar 2019 16:18:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAKQ9-0002ql-5Z for emacs-devel@gnu.org; Sat, 30 Mar 2019 16:17:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hAKQ7-0004DE-KL for emacs-devel@gnu.org; Sat, 30 Mar 2019 16:17:41 -0400 Original-Received: from [195.159.176.226] (port=55454 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hAKQ5-0004CK-Uz for emacs-devel@gnu.org; Sat, 30 Mar 2019 16:17:38 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hAKQ2-000Xjq-4c for emacs-devel@gnu.org; Sat, 30 Mar 2019 21:17:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:m81+8PWFKCsmggaaiGnl/C/Kpi0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:234827 Archived-At: >> (modify-syntax-entry ?' "\"" st) > > Maybe, but that doesn't give you the facilities that CC Mode offers, > namely that the delimiters of invalid constructs (such as unterminated > strings, or invalid character constants) get fontified with warning face. ... or quotes-in-numbers, indeed. > One question which has just occurred to me is why am I doing this in CC > Mode rather than the syntax and font-lock functionality handling it > directly? Languages where strings don't extend over unescaped newlines > aren't exactly a rarity. I think doing it in the syntax part is not necessary: the design of the syntax is made simpler and more efficient by assuming that the behavior on invalid code is largely irrelevant. And efficiency is important there when we need to parse-partial-sexp a large buffer. But providing support for highlighting such errors in font-lock (e.g. within font-lock-fontify-syntactically-region) would make a lot of sense, yes. Or maybe the simplest would be to provide a `font-lock-flag-multiline-strings` function that modes can add to font-lock-keywords. >> But the above sounds surprisingly complex&scary, > It only looks like that because I've spelled it out so laboriously. There > are two hook variables, each of which needs one function and the lack of > another. After re-reading the description I wonder if it couldn't be made simpler by making those hook functions check c-single-quotes-quote-strings instead (or have separate code in the cc-mode setup which adds/removes those hooks as needed based on c-single-quotes-quote-strings, essentially replacing the docstring text with executable code)? Also I still wonder why c-has-quoted-numbers is incompatible with c-single-quotes-quote-strings. I guess c-has-quoted-numbers only exists in C++, so in practice no language needs both features, but I can't see any reason why the CC-mode code wouldn't work just as well when both features are set. While both have to do with ' they seem fundamentally orthogonal. Stefan