From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: cc-mode: Make all parameters introduced in Emacs 26 optional Date: Mon, 22 Jan 2018 20:32:54 +0000 Message-ID: <20180122203254.GA4888@ACM> References: <1516608561.1943450.1243462056.1A47A60F@webmail.messagingengine.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1516653526 10169 195.159.176.226 (22 Jan 2018 20:38:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Jan 2018 20:38:46 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: jostein@kjonigsen.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 22 21:38:42 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 1edirG-00018l-DP for ged-emacs-devel@m.gmane.org; Mon, 22 Jan 2018 21:38:22 +0100 Original-Received: from localhost ([::1]:36587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1editG-0000Mu-Np for ged-emacs-devel@m.gmane.org; Mon, 22 Jan 2018 15:40:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edit5-0000LW-Uz for emacs-devel@gnu.org; Mon, 22 Jan 2018 15:40:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edit2-0001G7-0E for emacs-devel@gnu.org; Mon, 22 Jan 2018 15:40:15 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:50455 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1edit1-00016x-Ku for emacs-devel@gnu.org; Mon, 22 Jan 2018 15:40:11 -0500 Original-Received: (qmail 92052 invoked by uid 3782); 22 Jan 2018 20:40:06 -0000 Original-Received: from acm.muc.de (p548C7516.dip0.t-ipconnect.de [84.140.117.22]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Jan 2018 21:40:05 +0100 Original-Received: (qmail 5220 invoked by uid 1000); 22 Jan 2018 20:32:54 -0000 Content-Disposition: inline In-Reply-To: <1516608561.1943450.1243462056.1A47A60F@webmail.messagingengine.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:222156 Archived-At: 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 -- Alan Mackenzie (Nuremberg, Germany).