From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?Q?Jostein=20Kj=C3=B8nigsen?= Newsgroups: gmane.emacs.devel Subject: Re: cc-mode: Make all parameters introduced in Emacs 26 optional Date: Mon, 12 Mar 2018 21:16:38 +0100 Message-ID: <1520885798.1440538.1300560400.68951242@webmail.messagingengine.com> References: <1516608561.1943450.1243462056.1A47A60F@webmail.messagingengine.com> <20180122203254.GA4888@ACM> Reply-To: jostein@kjonigsen.net NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_----------=_152088579814405381" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1520885760 16141 195.159.176.226 (12 Mar 2018 20:16:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Mar 2018 20:16:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie , jostein@kjonigsen.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 12 21:15:55 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evTrM-00041g-TH for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2018 21:15:53 +0100 Original-Received: from localhost ([::1]:34427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evTtP-00078t-TE for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2018 16:17:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evTsD-00076K-SN for emacs-devel@gnu.org; Mon, 12 Mar 2018 16:16:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evTs9-0000uc-PE for emacs-devel@gnu.org; Mon, 12 Mar 2018 16:16:45 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:38623) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1evTs9-0000tl-GH for emacs-devel@gnu.org; Mon, 12 Mar 2018 16:16:41 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ED96720C11; Mon, 12 Mar 2018 16:16:38 -0400 (EDT) Original-Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 12 Mar 2018 16:16:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:content-transfer-encoding :content-type:date:from:in-reply-to:message-id:mime-version :references:reply-to:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ekrTCPxKeA49TIOp35FA50Cww8ppzPD2sIIexkTpD zs=; b=VePpt01yFjVhEM8ct7HQETabF1GylUW3oztYlmzLPjc73+We8lv+ilcLI ALmPB/+woFf9xYYeS2Z3xC063zd+26hn3JehUG23n2IeTQ3UFxgtKSXgFqz5kcAt a907Du2gZlK/bcFrohZQ26ImKIFWfrqX3slctdI8mvYZS/jcDTxyQO8S2fDTO7Ig kaV37ffzFsks3ad85DBUbGxF/ZoDB5xO8JXY18QilN7bLCuDK6QWXzFkUXb5Me/W Ouh9wT16t93U8egRbyCxI85RPQsMbncG67FhKafu+MsW3pjWgXaKfxePWNWGbrtI Pc+wbyH0chDIfhDkpFt/8iPCwrPBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ekrTCPxKeA49TIOp35FA50Cww8ppzPD2sIIexkTpDzs=; b=Tk2+7KsxLehx KdeE3+nYCt9vE09woRqJWkIPribPk6WgKjdTwTSSRZFpvUMkT5gFFMQWUTVDf99G iQD1HUdXBRZrpGn3/1Vgk/lkMbD56/BmVJv3xCpeRiDXW487DvrGVPXxq2Lm73kz 9+kp7SbyHOWi7HYJJRZdEljyyocQd32cygK0m5UAb6/rZFH/3HXvQmPHWpeIeISk X64pMsew1yJkNRnOOJnjMu0QgcQQC/BXijgxQffcoZZQL5j7JaICBV3THaFl9HD9 Wa/wlUEVU6a1J2Ri2Hb7tqNxHuBjZpve7/FJGbCScsoE/xipMLyUag9cYUoz9dZa VDyRvdpU1g== X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id CEC47940A5; Mon, 12 Mar 2018 16:16:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface - ajax-54087d22 In-Reply-To: <20180122203254.GA4888@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.111.4.25 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223656 Archived-At: This is a multi-part message in MIME format. --_----------=_152088579814405381 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hey Alan. Thanks for your answer! > There's a convention in CC Mode that functions, macros, and variables> wi= th 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,> on= e of the following is true: > (i) There's a need for functionality which is currently lacking in CC> Mo= de. > (ii) The maintainer of the derived mode is unaware of existing CC Mode> f= unctionality 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> yo= u'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 o= n 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-d= eclarators, 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=C3=B8nigsen --_----------=_152088579814405381 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hey Alan.

Thanks for your answer!

There's a convention in CC Mode that functio= ns, macros, and variables
with a doc string are regarded as part of an "API" to derived modes, b= ut
objects with merely a "doc comment" are regarded as internal to CC Mod= e,
and _much_ less secure against random changes.

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

c-font-lock-declarators is one of these func= tions intended to be
"internal".  If a derived mode like csharp-mode is using it direc= tly,
one of the following is true:
(i) There's a need for functionality which is currently lacking in CC<= br>
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-declara= tors at all?  Could it be
you're wanting to do something which currently can't be done with the<= br>
"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 co= de.

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 a= nd I'm definitely not 100% in control w.r.t. what all parts of the code act= ually does.

Why this particular function was chosen is something I cannot directly= answer for. This particular section of code has been unchanged since the f= irst commit in any version-controlled version of this code I can find, by D= ino Chiesa. As such, it's lacking a change/context which can further explai= n 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
<= /div>
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 posit= ion 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 th= e road.

When/if I can get that done, that leaves me in a position where I'll h= ave 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 ve= rsions.

Is there any way for package to know how many mandatory arguments a fu= nction 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 functio= n?  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 "inter= nal" members used:

  • c-safe
  • c-put-character-property
  • c-put-font-= lock-face
  • c-fontify-types-and-refs
  • c-forward-keywor= d-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 th= e state of affairs. As such, any advice appreciated.

--
Regards
Jostein Kj=C3=B8nigsen




--_----------=_152088579814405381--