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: Fri, 06 Feb 2015 12:47:15 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423244879 2543 80.91.229.3 (6 Feb 2015 17:47:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Feb 2015 17:47:59 +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 Fri Feb 06 18:47:58 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 1YJn0Y-0001Yb-AA for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 18:47:58 +0100 Original-Received: from localhost ([::1]:49929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJn0X-0002RB-KM for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 12:47:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJn0K-0002PT-4G for emacs-devel@gnu.org; Fri, 06 Feb 2015 12:47:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJn0G-0000wt-Mi for emacs-devel@gnu.org; Fri, 06 Feb 2015 12:47:44 -0500 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:50880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJn0G-0000vw-H1 for emacs-devel@gnu.org; Fri, 06 Feb 2015 12:47:40 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 23E5385F2B; Fri, 6 Feb 2015 12:47:39 -0500 (EST) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 69CF61E5B8D; Fri, 6 Feb 2015 12:47:15 -0500 (EST) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 4A7F2B4102; Fri, 6 Feb 2015 12:47:15 -0500 (EST) In-Reply-To: (Christoph Wedler's message of "Fri, 6 Feb 2015 15:14:02 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:182548 Archived-At: >> prog-mode sounds good. That doesn't prevent non-prog modes from using >> it (and really, modes like xml-mode or latex-mode should inherit from >> both text-mode and prog-mode). > Ok, how should I name the variable then? `submode-indentation-context' ? I'd use prog-indentation-context. > The values are provided by the outer mode. But the inner mode decides > what it expects in (that's why I called it SUBMODE-SPECIFIC in > the "real doc"). That requires some cross-knowledge of the two modes. It's not ideal, but I guess it's OK. > While it is true that the chunk specified by MIN/MAX should really be > considered begin a continuation of a "chunk series", most modes won't > probably like the idea of having to react to the "text before MIN", > because that would require them to create a temporary buffer for the > indent calculation. 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. > Providing a possibility for some initial syntactic context is probably > easier. E.g. cc-mode can decide that it can accept some initial value > for c-syntactic-context... Providing the location of the previous chunk(s) is all that's needed and the submode can do that "initial context" dance if that's what it likes. This is better because the outer mode doesn't need to know about those "initial contexts". But we can start without support for that kind of "previous chunks" info and add it later. It's often better to add such support only once you have an actual concrete need for it, so you can check that it really does satisfy the need. Stefan