emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jostein Kjønigsen
Subject: Re: cc-mode: c-font-lock-invalid-string bytecompiled but undefined
Date: Wed, 01 Aug 2018 22:04:05 +0200

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

address@hidden 🍵 address@hidden
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

address@hidden 🍵 address@hidden
https://jostein.kjonigsen.net


reply via email to

[Prev in Thread] Current Thread [Next in Thread]