From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: antlr-mode.el - need some support by python.el Date: Mon, 16 Feb 2015 14:23:25 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424114640 21541 80.91.229.3 (16 Feb 2015 19:24:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 19:24:00 +0000 (UTC) Cc: "=?windows-1252?Q?Fabi?= =?windows-1252?Q?=E1n?= E.Gallina" , "emacs-devel@gnu.org" To: "Wedler\, Christoph" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 16 20:23:51 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNRGp-0007ix-M7 for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 20:23:51 +0100 Original-Received: from localhost ([::1]:41587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRGp-0008Ko-4Q for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 14:23:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRGl-0008Hj-57 for emacs-devel@gnu.org; Mon, 16 Feb 2015 14:23:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNRGf-0001Et-UE for emacs-devel@gnu.org; Mon, 16 Feb 2015 14:23:47 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:45921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRGf-0001Ed-P7 for emacs-devel@gnu.org; Mon, 16 Feb 2015 14:23:41 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t1GJNbAP004353; Mon, 16 Feb 2015 14:23:37 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 44903F86; Mon, 16 Feb 2015 14:23:25 -0500 (EST) In-Reply-To: (Christoph Wedler's message of "Mon, 16 Feb 2015 14:38:45 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5219=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5219> : inlines <2191> : streams <1391343> : uri <1856837> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183175 Archived-At: >>>> Not necessarily: the submode can just go to the end of the previous >>>> chunk, compute some state at that position and use that state as initial >>>> context at MIN. >>> ... if scan-lists, mode-specific skip-comments etc are prepared for this. >> That's the responsibility of the sub-mode. > To get support by the authors of potential sub-modes, I would really > like to keep the effort for the sub-modes small. > Given that the indentation code of many prog-modes is probably the most > complex part, I would understand if the authors do not want to change it > considerably just to support some special-topic major mode. But it's not like there are many other options. The options are either: - the submode doesn't know how to use previous chunks, so it doesn't work correctly when the code is split into related chunks. - the submode does know how to parse and connect the various chunks. In either case, the outer mode can't do anything more than provide the boundaries and relationships between the various chunks (e.g. in the case of antlr, I guess the relationship is that each chunk for an action is independent) because the outer mode can't know what info the submode might need to propagate from one chunk to the other. IOW, what I stated is not a design choice, it's just a fact of life. > 4. SUB provides a function which creates a valid value for > `SUB-extra-indentation-context' - valid arguments for that function > would either be a string, or a list of buffer ranges. > For C (assuming that a valid value for `c-extra-indentation-context' > would look like the return value of `c-guess-basic-syntax'), this > function could simply put the string / buffer chunks into a > temporary buffer and call `c-guess-basic-syntax' at eob. > In my use case, I would run this function once - in the literate > programming case, you would run it whenever you delegate the > indentation to the sub mode. > 5. If SUB decides that it can support the "multi-chunk case" directly > in the indentation code (e.g. for performance improvements), it can > do so without any change in the call by the main mode - the function > introduced in stage 4 would then simply return the buffer-positions. I don't see much difference between 4 and 5: basically, the difference is between putting the code in the outer-mode or in the submode, but it'll be the same code. And since this code is submode-specific, I'd rather skip the step 4. If the submode can't be modified (e.g. the author doesn't want to cooperate or you want your outer mode to work with older versions), then we can use with-eval-after-load, add-hook, add-advice and friends to get the effect of 4 without having explicit support for it. In any case your patch looks good, feel free to install it. Stefan