From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: cc-mode: Make all parameters introduced in Emacs 26 optional Date: Sat, 30 Mar 2019 19:42:04 +0000 Message-ID: <20190330194204.GB6312@ACM> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="251013"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 30 20:42:19 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 1hAJru-0013CZ-Iu for ged-emacs-devel@m.gmane.org; Sat, 30 Mar 2019 20:42:18 +0100 Original-Received: from localhost ([127.0.0.1]:55705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAJrt-0000ft-HT for ged-emacs-devel@m.gmane.org; Sat, 30 Mar 2019 15:42:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAJrn-0000fV-AH for emacs-devel@gnu.org; Sat, 30 Mar 2019 15:42:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hAJrm-0007uC-3v for emacs-devel@gnu.org; Sat, 30 Mar 2019 15:42:11 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:46272 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hAJrl-0007tj-ND for emacs-devel@gnu.org; Sat, 30 Mar 2019 15:42:10 -0400 Original-Received: (qmail 4123 invoked by uid 3782); 30 Mar 2019 19:42:05 -0000 Original-Received: from acm.muc.de (p2E5D5F4A.dip0.t-ipconnect.de [46.93.95.74]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 30 Mar 2019 20:42:04 +0100 Original-Received: (qmail 11374 invoked by uid 1000); 30 Mar 2019 19:42:04 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:234826 Archived-At: Hello, Stefan. On Sat, Mar 30, 2019 at 12:39:55 -0400, Stefan Monnier wrote: > Hi Alan, > > To set up a CC Mode derived mode to recognise strings 'like this', do the > > following: > > (i) Set the derived mode's value of `c-single-quotes-quote-strings' to t. > > (This is done with `c-lang-defconst' in the derived mode's .el file). > > (ii) Make sure the derived mode's value of > > `c-get-state-before-change-function' does not include > > `c-parse-quotes-before-change'. > > (iii) Similarly ensure `c-before-font-lock-functions' doesn't contain > > `c-parse-quotes-after-change'. > > (iv) Ensure the derived mode's value of > > `c-get-state-before-change-function' contains > > `c-before-change-check-unbalanced-strings' and that of > > `c-before-font-lock-functions' contains > > 'c-after-change-mark-abnormal-strings'. > > (v) Make sure `c-has-quoted-numbers' is nil. (This is a pure C++ > > facility for writing numbers as 4'294'967'295.) > > (vi) Ensure `c-multiline-string-start-char' (which allows strings to > > continue over line ends without \) is set correctly for the mode. > In non-CC modes, all it takes is > (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. > so is there somewhere in CC-mode's code where there's some comment or > something that explains why this simple approach isn't sufficient? There're comments which explain the strategems used to get the font-lock-warning-face. 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 understand that things aren't always that simple: > - you need to handle the 4'294'967'295 thingies in C++, but that should > only affect C++ and I'd assume that the C++ code handles it by > recognizing something like "[0-9]'" and changing the syntax-class of > those quotes so it shouldn't prevent multichar single-quoted strings. More or less, although it checks there aren't two adjacent 's, and things like that. > - you apparently want to help the user catch the erroneous use of > single-quoted strings in those languages where single quotes are used > for chars rather than strings. but again this would seem to only > explain the need for c-single-quotes-quote-strings. > 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. There are two boolean constants which need setting. It needs to be done once when writing a mode, and only then when there's something unusual, like 'strings like this'. > Stefan -- Alan Mackenzie (Nuremberg, Germany).