From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: antlr-mode.el - need some support by python.el Date: Fri, 5 Jun 2015 20:46:24 +0300 Message-ID: <5571E070.9050905@yandex.ru> References: <54E90362.8070904@yandex.ru> <54F38FD3.1020307@yandex.ru> <54F47CD3.5080708@yandex.ru> <54F4A62F.3040403@yandex.ru> <54F4BA93.4000801@yandex.ru> <54F73EE0.9070306@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1433526442 27929 80.91.229.3 (5 Jun 2015 17:47:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 17:47:22 +0000 (UTC) Cc: "=?UTF-8?Q?Fabi=c3=a1n_E.Gallina?=" , "emacs-devel@gnu.org" To: "Wedler, Christoph" , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 05 19:47:17 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 1Z0vhk-0001mH-Ok for ged-emacs-devel@m.gmane.org; Fri, 05 Jun 2015 19:46:52 +0200 Original-Received: from localhost ([::1]:48941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0vhf-0002jP-6A for ged-emacs-devel@m.gmane.org; Fri, 05 Jun 2015 13:46:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0vha-0002j9-Dt for emacs-devel@gnu.org; Fri, 05 Jun 2015 13:46:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0vhV-0000Qj-Du for emacs-devel@gnu.org; Fri, 05 Jun 2015 13:46:42 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:35712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0vhV-0000AE-72 for emacs-devel@gnu.org; Fri, 05 Jun 2015 13:46:37 -0400 Original-Received: by wiga1 with SMTP id a1so28282921wig.0 for ; Fri, 05 Jun 2015 10:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=uJI/vy32MldKda6FlbliFsWA0siXLQwt+fQNSrJ8qBY=; b=Bw5bzvOLP7wAf0MMLjKKDhG3mhEopWkgiU37lQ32cSNXFUwECT8PzJJdJUSm36K4xp SRoeWwOQBDuGLoY9DiZ0Ij5uH813WNOFCKXJbIIbJ+/VR2L8NN8az6alStvNGjSFu1t2 kYKeKu50CVsxED2e+Y/fJiJrfX41CS4k/j9R/+G3ukp1+MueThBUF1b1m6TpXOmUZvj2 F+cAh5t36O2USydgAdCxppSNAyAI2dmIZMxU3UyDaWbJYjBEB81ga3cOS8DwBV7mfW8P N4b3k8bO1K3f66uVQgVbdmbokkyHcfvCuTtOPyTFCskqdRuG+xI3KgRSaskZJYXWubNZ nXQA== X-Received: by 10.194.90.100 with SMTP id bv4mr8119296wjb.143.1433526386352; Fri, 05 Jun 2015 10:46:26 -0700 (PDT) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id w11sm11613158wjr.48.2015.06.05.10.46.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2015 10:46:26 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 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:187048 Archived-At: On 06/05/2015 05:17 PM, Wedler, Christoph wrote: > Many modes use more than the current line / code chunk in their > indentation calculations. For example, in `c-guess-basic-syntax', the > outer language constructs are also considered. If the indentation > engine of the inner mode just see the code chunks, there is a potential > problem... I think the string value is not ideal, because then the inner mode can't cache syntactic information, and reuse it between chunks. This is something we probably want to facilitate. Adapting the current major mode indentation code to work with either kind of PREVIOUS-CHUNKS value, looks non-trivial as well. I don't currently have a better suggestion, though. But this proposal could use a corresponding patch to cc-mode.