* Re: cc-mode: c-font-lock-invalid-string bytecompiled but undefined
[not found] ` <20180715210558.GF4897@ACM>
@ 2018-08-01 20:04 ` Jostein Kjønigsen
0 siblings, 0 replies; 2+ messages in thread
From: Jostein Kjønigsen @ 2018-08-01 20:04 UTC (permalink / raw)
To: Alan Mackenzie, emacs-devel; +Cc: bug-cc-mode
[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]
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-invalid-
string is making a return, I might prefer to stick to that (over
something as unambitious as available time).
--
Regards
Jostein Kjønigsen
jostein@kjonigsen.net 🍵 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
> quite hectic.>
> 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 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
> change has> been so that unterminated strings get font-lock-string-face
> only up till> 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ønigsen wrote:
>> 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
>> 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?
>
>> If it is now obsolete and is intentionally removed, what are derived->> mode developers advised to use instead?
>> --
>> Regards
>> Jostein Kjønigsen
>
>> jostein@kjonigsen.net 🍵 jostein@gmail.com
>> https://jostein.kjonigsen.net
[-- Attachment #2: Type: text/html, Size: 4809 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread