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, 08 Jun 2015 16:50:27 -0400 Message-ID: References: <54F47CD3.5080708@yandex.ru> <54F4A62F.3040403@yandex.ru> <54F4BA93.4000801@yandex.ru> <54F73EE0.9070306@yandex.ru> <5571E070.9050905@yandex.ru> <5575BCB3.4070904@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1433796683 23273 80.91.229.3 (8 Jun 2015 20:51:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jun 2015 20:51:23 +0000 (UTC) Cc: "Wedler, Christoph" , "=?windows-1252?Q?Fab?= =?windows-1252?Q?i=E1n?= E.Gallina" , "emacs-devel@gnu.org" To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 08 22:51:08 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 1Z240d-0007tw-5n for ged-emacs-devel@m.gmane.org; Mon, 08 Jun 2015 22:51:03 +0200 Original-Received: from localhost ([::1]:60169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z240c-00031v-EM for ged-emacs-devel@m.gmane.org; Mon, 08 Jun 2015 16:51:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z240B-0002yD-G9 for emacs-devel@gnu.org; Mon, 08 Jun 2015 16:50:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2408-0004pD-2Q for emacs-devel@gnu.org; Mon, 08 Jun 2015 16:50:35 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:33669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2407-0004oa-MO for emacs-devel@gnu.org; Mon, 08 Jun 2015 16:50:32 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t58KoRb1002019; Mon, 8 Jun 2015 16:50:27 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 488DB66166; Mon, 8 Jun 2015 16:50:27 -0400 (EDT) In-Reply-To: <5575BCB3.4070904@yandex.ru> (Dmitry Gutov's message of "Mon, 8 Jun 2015 19:02:59 +0300") 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 RV5331=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5331> : inlines <3172> : streams <1452219> : uri <1953134> 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:187111 Archived-At: >> Maybe we should simply document that it's valid&expected for the inner >> mode to add text-properties to the string. > Which string? IIUC we were talking about the case where PREVIOUS-CHUNKS is a string. So: *the* string. > Suppose an inner chunk A is followed by an "external" region, > and then an inner chunk B. When we work on the contents of the chunk A, the > new variable clearly won't include the contents of that chunk in the > PREVIOUS-CHUNKS field. What new variable? You mean prog-indentation-context? I think in the case you describe, the outer mode wouldn't pass a string in PREVIOUS-CHUNKS but would instead pass a function that gives access to the chunk A. > Thus, it's not possible for the code working in A to > cache some state in a way accessible to the chunk B (to anny code running > when it's current). The inner mode can keep track of its state via text-properties applied to the actual buffer text. So while working on chunk A, it could add properties there, and while working on chunk B it would get access to those properties via the region-bounds returned by the PREVIOUS-CHUNKS function. > Making PREVIOUS-CHUNKS store a list of position pairs (regions), or making > it function, both sound better to me. The intended use case where PREVIOUS-CHUNKS is a string is when this "context" is a fixed short string, e.g. in a tool like yacc/bison, each C chunk would use a PREVIOUS-CHUNKS along the lines of "void pseudofunction () {" so as to make it clear that the chunk's content is expected to be a function body rather than a top-level declaration. Stefan