cc-mode: c-font-lock-invalid-string bytecompiled but undefined

cc-mode: c-font-lock-invalid-string bytecompiled but undefined

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

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: 1526 bytes --]

Re: cc-mode: c-font-lock-invalid-string bytecompiled but undefined

[Jostein Kjønigsen]

[-- 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 --]