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

[Jostein Kjønigsen]

Hey Alan.

Thanks for your answer!

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.

I was unaware of such a convention, but that's definitely useful to know for the future.

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) ???

That sounds like a valid assessment.

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.

I'd hate to pass ball on this one, but I didn't write this original code.

It's fairly messy and dirty I picked up from the internet and decided to patch up when it started breaking with Emacs 24. Since then I've done my best to keep it working, but I've never had time to clean it properly up and I'm definitely not 100% in control w.r.t. what all parts of the code actually does.

Why this particular function was chosen is something I cannot directly answer for. This particular section of code has been unchanged since the first commit in any version-controlled version of this code I can find, by Dino Chiesa. As such, it's lacking a change/context which can further explain the choice of function.

Definitely not an optimal situation.

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.

That's a reasonable position indeed. I guess that puts me in the position where I need to better figure out how this particular part of the code actually works. I'm sure I'll appreciate that on some level further down the road.

When/if I can get that done, that leaves me in a position where I'll have to make a choice:

1. try to replace this broken section of code with something different (with a understanding of what it needs to do)

2. keep using c-font-lock-declarators, in case I don't have time for a rewrite.

In the latter case, I will face a compatibility-issue between Emacs versions.

Is there any way for package to know how many mandatory arguments a function has, to be able to branch out for compatibility reasons? My research so far haven't given me any obvious answer.

Again, why is csharp-mode using this function?  Are there any other

"internal" functions/macros/variables it is using?

That's indeed a good question. Seeing the kind of problems such usage lands me in, I'd definitely want to reduce the scope of that.

A quick skim of the source-code uncovers at least the following "internal" members used:

• c-safe
  
• c-put-character-property
  
• c-put-font-lock-face
  
• c-fontify-types-and-refs
  
• c-forward-keyword-clause
  
• c-font-lock-declarators
  
• Not to mention it does monkey-patch/advice c-inside-bracelist-p and c-forward-objc-directive.
  

Like I said. This is dirty code, and I'm definitely not happy about the state of affairs. As such, any advice appreciated.

--

Regards

Jostein Kjønigsen