Re: cc-mode: Make all parameters introduced in Emacs 26 optional

[Matthew Carter <m@ahungry.com>]

Matthew Carter <m@ahungry.com> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> Hello, Jostein.
>>
>> On Mon, Jan 22, 2018 at 09:09:21 +0100, Jostein Kjønigsen wrote:
>>> Hey everyone.
>>
>>> While cc-mode seems to be a foundation for lots of the major-modes
>>> shipped with Emacs, it's also used by third-party packages.
>>> For major-modes shipped with Emacs, changes to the core cc-mode
>>> functions is not that big of a problem, since they can be changed in
>>> tandem with the changes to cc-mode itself.
>>
>>> For third party modules (like csharp-mode, which I maintain), changes to
>>> cc-mode core-functions are more problematic due to Emacs lacking
>>> reliable introspection capabilities.
>>
>> There's a convention in CC Mode that functions, macros, and variables
>> with a doc string are regarded as part of an "API" to derived modes, but
>> objects with merely a "doc comment" are regarded as internal to CC Mode,
>> and _much_ less secure against random changes.
>>
>>> As an example in the Emacs 26 branch c-font-lock-declarators is now
>>> declared like this:
>>> (defun c-font-lock-declarators (limit list types not-top &optional template-
>>> class)  ...)
>>> While in Emacs 25.3 and earlier it's declared like this:
>>
>>> (defun c-font-lock-declarators (limit list types)
>>>   ...)
>>
>>> Basically the number of mandatory parameters has been bumped from 3 to
>>> 4, with another optional parameter added.
>>
>> c-font-lock-declarators is one of these functions intended to be
>> "internal".  If a derived mode like csharp-mode is using it directly,
>> one of the following is true:
>> (i) There's a need for functionality which is currently lacking in CC
>> Mode.
>> (ii) The maintainer of the derived mode is unaware of existing CC Mode
>> functionality which would satisfy his need.
>> (iii) ???
>>
>>> These kinds of changes makes it harder for third party modules to
>>> maintain compatibility across Emacs-versions.
>>
>> Why is csharp-mode using c-font-lock-declarators at all?  Could it be
>> you're wanting to do something which currently can't be done with the
>> "API" functions/macros/variables?  If so, it might well be better to
>> amend CC Mode to provide this functionality.
>>
>>> Wouldn't it be better to make *all *the new parameters optional and thus
>>> maintain compatibility? Are there any good reasons not to do so?
>>
>> Well, to work properly, the caller of c-font-lock-declarators will need
>> to determine the `not-top' argument rather than just relying on a
>> randomish default.  The meaning of the function has changed.  `not-top'
>> doesn't seem suitable for being &optional.
>>
>> Again, why is csharp-mode using this function?  Are there any other
>> "internal" functions/macros/variables it is using?
>>
>>> --
>>> Regards
>>> Jostein Kjønigsen
>>
>>> jostein@kjonigsen.net 🍵 jostein@gmail.com
>>> https://jostein.kjonigsen.net
>
> Somewhat on this subject - recent versions of Emacs have seemed to have
> changed single quotes with text between the quotes with a length greater
> than 1 to use a warn font face on the quotes, instead of the font string
> face (likely because in C the single quote denotes a char, but in many
> of the derived modes that cc-mode mentions in it's own comment set
> (php-mode, dart-mode etc.), a single quoted string and double quoted
> string are used interchangeably).
>
> Does cc-mode have a setting to correct this and restore the old behavior?

I hate to respond to my own post, but I have tracked this down to
#'c-parse-quotes-after-change (defined in cc-mode.el).  

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com