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

["Jostein Kjønigsen" <jostein@secure.kjonigsen.net>]

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

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





[-- Attachment #2: Type: text/html, Size: 5221 bytes --]