From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?Q?Jostein=20Kj=C3=B8nigsen?= Newsgroups: gmane.emacs.devel Subject: Re: cc-mode: c-font-lock-invalid-string bytecompiled but undefined Date: Wed, 01 Aug 2018 22:04:05 +0200 Message-ID: <1533153845.710270.1460360304.3F54C232@webmail.messagingengine.com> References: <1531055917.192964.1433656200.5D23467F@webmail.messagingengine.com> <20180715210558.GF4897@ACM> Reply-To: jostein@kjonigsen.net NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_----------=_15331538457102706" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1533153738 19159 195.159.176.226 (1 Aug 2018 20:02:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2018 20:02:18 +0000 (UTC) Cc: bug-cc-mode@gnu.org To: Alan Mackenzie , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 01 22:02:13 2018 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 1fkxK0-0004pi-EE for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2018 22:02:12 +0200 Original-Received: from localhost ([::1]:42705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkxM7-0004qQ-39 for ged-emacs-devel@m.gmane.org; Wed, 01 Aug 2018 16:04:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkxLw-0004qI-HQ for emacs-devel@gnu.org; Wed, 01 Aug 2018 16:04:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkxLv-00021I-1W for emacs-devel@gnu.org; Wed, 01 Aug 2018 16:04:12 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:53095) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fkxLq-00020a-9U; Wed, 01 Aug 2018 16:04:06 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8B4AF21DC1; Wed, 1 Aug 2018 16:04:05 -0400 (EDT) Original-Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 01 Aug 2018 16:04:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:content-transfer-encoding :content-type:date:from:in-reply-to:message-id:mime-version :references:reply-to:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=svTkeglP8Wb/45iSDgAvgx6iKCvHNUltiSB1wfT9N Uo=; b=1w+A+J6xdy7dwhqZ7qr7aIM+dMPVCixrUm9dmuhq8cyLKmgGQgPl9d/HZ uWaGTvVBw+POY7q4BxpBYHpEQg6BypR0hMydKAKIU+lVPR1pKq5N/X20YA2yytZN Xi1m+hp0tSY83YQd7vIpqrwSkSIrED1+1KQXw4fn3KiSS+xKchPsLWS4HtY+/KR1 a+ozASqZcTzTMifgc4jMiAgc/SoTo4q+F5k6F1hfVCnWyDCITfck8y/8V+P26cGq CBTaBcWXCvjfhcSS+EUSBPQ3pm6PzkZVCAlteJn1owbCzIzOS13lKtdPNv92yrRq ZAD+R4Ldb2Y9YndeQO97NnIwdQsew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=svTkeglP8Wb/45iSDgAvgx6iKCvHNUltiSB1wfT9NUo=; b=c1JoQedDglBV dmG3xC1DJDHzN64BrJrBsSC9n+6u1GRidGoNf/G1ps9VhAb16pu510dYji8CtM0l tIQs4uHxscVGzmPa20djJaLEPlmxhVBBHNt6d8hPw53qRRZ5BG/o9aaWZaQZ9SI5 VjGrjty5NxM83/0XOeHNZhX6e4MgroA90Q0ar0KCoXWc5lRiPSnZOfEnsvQoqG5u m68JHewzKsHI+DgUXDXKAYtf7skupODtLNAnVT/t2bRE5o+1LWzb0Yfly4y87jxZ w30f2/gj9txvG0OxdCRyCAHSExI6TMygvb0o4s6OMnY6RsPnLuocW7wd/jJy+veB 59Q0WLMCDA== X-ME-Proxy: X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2CB6DBA50C; Wed, 1 Aug 2018 16:04:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b In-Reply-To: <20180715210558.GF4897@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.111.4.25 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:228092 Archived-At: This is a multi-part message in MIME format. --_----------=_15331538457102706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hey Alan. Thanks for your reply. No worries about vacation. I'm just back from vacation myself! After sending the email, I too realized that c-font-lock-invalid-string was declared with a comment-string and not a doc-string, and remembering you telling me about these conventions. (Meaning, that in general I'm not exactly entitled to act overly surprised when it went away. Oh well.) That said... You say you now see its use in third-party packages as essential and unavoidable. Should I interpret that as it possibly making a return? Checking latest git master now at least, I see no new cc-fonts.el- changes since the commit in may. I can try looking into the suggestions you offer, but if c-font-lock-invali= d- string is making a return, I might prefer to stick to that (over something as unambitious as available time). -- Regards Jostein Kj=C3=B8nigsen jostein@kjonigsen.net =F0=9F=8D=B5 jostein@gmail.com https://jostein.kjonigsen.net On Sun, Jul 15, 2018, at 11:05 PM, Alan Mackenzie wrote: > Hello, Jostein. >=20 > Sorry I'm only just replying. The last week or two has been > quite hectic.>=20 > As a short answer, c-font-lock-invalid-string was marked with a > comment> rather than a doc-string, hence I regarded it as "internal". > However, I> now see that its use by derived modes is essential and unavoi= dable, so> it should have had a doc string to mark it as part of the UI, an= d I > should have been more careful about removing it. >=20 > As to what to replace c-f-l-invalid-string with, what C Mode has is: > (i) c-before-change-check-unbalanced strings on the hook > c-get-state-before-change-functions. > (ii) c-after-change-re-mark-unbalanced-strings on the hook > c-before-font-lock-functions. > These two functions work together. >=20 > Would you please try these in your mode. The purpose of this > change has> been so that unterminated strings get font-lock-string-face > only up till> the next (unescaped) newline, rather than an arbitrarily lo= ng piece of> buffer up to the next string quote. >=20 > This change has been somewhat controversial on the Emacs developers' > list, and may not yet be in its final form. >=20 > -- > Alan Mackenzie (Nuremberg, Germany). >=20 >=20 >=20 > On Sun, Jul 08, 2018 at 15:18:37 +0200, Jostein Kj=C3=B8nigsen wrote: >> Hey everyone. >=20 >> I'm having some issues with cc-mode after commit >> bb591f139f0602af292c772f974dcc14dabb1deb. >> This commit removed the definition for c-font-lock-invalid- >> string, but>> in cc-fonts.el it's still patched up to silence-compiler w= arnings >> elsewhere: >> (cc-bytecomp-defun c-font-lock-declarators) >> (cc-bytecomp-defun c-font-lock-objc-method) >> (cc-bytecomp-defun c-font-lock-invalid-string) >=20 >> Was the removal a mistake, or was the removal incomplete? >=20 >> If it is now obsolete and is intentionally removed, what are derived->> = mode developers advised to use instead? >> -- >> Regards >> Jostein Kj=C3=B8nigsen >=20 >> jostein@kjonigsen.net =F0=9F=8D=B5 jostein@gmail.com >> https://jostein.kjonigsen.net --_----------=_15331538457102706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hey Alan.

Thanks for your reply. No worries about vacation. I'm just back from v= acation myself!

After sending the email, I too realized that c-font-lock-invalid-= string was declared with a comment-string and not a doc-string, and remembe= ring you telling me about these conventions. (Meaning, that in general I'm = not exactly entitled to act overly surprised when it went away. Oh well.)

That said... You say you now see its use in third-party packages as es= sential and unavoidable. Should I interpret that as it possibly making a re= turn? Checking latest git master now at least, I see no new cc-fonts.el-cha= nges since the commit in may.

I can try looking into the suggestions you offer, but if c-font-lock-i= nvalid-string is making a return, I might prefer to stick to that (over som= ething as unambitious as available time).

--
Regard= s
Jostein Kj=C3=B8nigsen

jostein@k= jonigsen.net =F0=9F=8D=B5 jostein@= gmail.com
https://= jostein.kjonigsen.net


On Sun, Jul 15, 2018, at 11:05 PM, Alan Mackenzie wrote:
Hello, Jostein.

Sorry I'm only just replying.  The last week or two has been quit= e hectic.

As a short answer, c-font-lock-invalid-string was marked with a commen= t
rather than a doc-string, hence I regarded it as "internal".  How= ever, I
now see that its use by derived modes is essential and unavoidable, so=
it should have had a doc string to mark it as part of the UI, and I
should have been more careful about removing it.

As to what to replace c-f-l-invalid-string with, what C Mode has is:
(i) c-before-change-check-unbalanced strings on the hook
  c-get-state-before-change-functions.
(ii) c-after-change-re-mark-unbalanced-strings on the hook
  c-before-font-lock-functions.
These two functions work together.

Would you please try these in your mode.  The purpose of this cha= nge has
been so that unterminated strings get font-lock-string-face only up ti= ll
the next (unescaped) newline, rather than an arbitrarily long piece of=
buffer up to the next string quote.

This change has been somewhat controversial on the Emacs developers'
list, and may not yet be in its final form.

--
Alan Mackenzie (Nuremberg, Germany).



On Sun, Jul 08, 2018 at 15:18:37 +0200, Jostein Kj=C3=B8nigsen wrote:<= br>
Hey everyone.

I'm having some issues with cc-mode after commit
bb591f139f0602af292c772f974dcc14dabb1deb.
This commit removed the definition for c-font-lock-invalid-string, but=
in cc-fonts.el it's still patched up to silence-compiler warnings
<= /div>
elsewhere:
  (cc-bytecomp-defun c-font-lock-declarators)
  (cc-bytecomp-defun c-font-lock-objc-method)
  (cc-bytecomp-defun c-font-lock-invalid-string)

Was the removal a mistake, or was the removal incomplete?<= br>

If it is now obsolete and is intentionally removed, what a= re derived-
mode developers advised to use instead?
--
Regards
Jostein Kj=C3=B8nigsen


--_----------=_15331538457102706--