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: Thu, 19 Feb 2015 00:55:38 +0200 Message-ID: <54E5186A.4020906@yandex.ru> References: <54E40954.7000706@yandex.ru> <54E4AFE5.1070208@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 1424300167 11380 80.91.229.3 (18 Feb 2015 22:56:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2015 22:56:07 +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 Wed Feb 18 23:56:00 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 1YODXA-00009z-Cx for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 23:55:56 +0100 Original-Received: from localhost ([::1]:54012 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YODX9-0003fc-WD for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 17:55:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YODX0-0003cr-0t for emacs-devel@gnu.org; Wed, 18 Feb 2015 17:55:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YODWv-0003W0-Ub for emacs-devel@gnu.org; Wed, 18 Feb 2015 17:55:45 -0500 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:48646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YODWv-0003Vn-OE for emacs-devel@gnu.org; Wed, 18 Feb 2015 17:55:41 -0500 Original-Received: by mail-wi0-f174.google.com with SMTP id em10so44477386wid.1 for ; Wed, 18 Feb 2015 14:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hlHAO1zqC6HumWxClrmG+UsY2kUSxx+/kiB2uvW0oiw=; b=YFfoEfGaiZ743NKoJtoMTQI8TsFWj+NzSR9J0oJq4lE3LQmoPfD1Q/qY36QiD0k6F+ WUt8OrgEibnj1LFhwS6jT6lzWk/BDzzwHmC38ZQAl7M4TL2sn+M1mV8XAVrs4sPafvvF gwuDZThY+seN6hgNPtvTK4d+t80bK7Hiaa1JfxIjw0AF7hLV4gmeN7mYNiDcG19keHy1 xSquhB2mIXsj/qPydSTU/snBv1AQYtu8fQhhbIoJslyFppKisdFyA3DHwe89DOBttLrC KSVSxB5YiRyVHrrxU6nMUcTcM0OnKDSuECq9WuAUsbAx4nyz+u+IcXlX+o9LAMvk49fB rdkw== X-Received: by 10.180.208.35 with SMTP id mb3mr9544481wic.14.1424300141037; Wed, 18 Feb 2015 14:55:41 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id dj4sm34686050wjc.13.2015.02.18.14.55.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 14:55:40 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.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::22e 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:183278 Archived-At: On 02/18/2015 06:10 PM, Wedler, Christoph wrote: > Well, if we think that the advantage of a 2nd narrowing is greater then > the disadvantage (complexity) -I am not convinced-, then we should at > least reduce the disadvantage. In this case, this means that the > "functional" narrowing should be visible - I am not sure how to do it if > the "visible" narrowing is smaller... I believe, if this distinction will sometime come into life, the "functional" kind will only be applied programmatically, and won't stay on between commands. So there'll be nothing to highlight. >> Not necessarily: you also can adjust the indentation after the submode >> applies it. > > I do exactly that, but it does not work for python due to its cycling > functionality. (It is also not ideal buffer-undo-list -wise.) I don't know about cycling. Sounds like something that could be handled in a different way. buffer-undo-list should be fine: several changes performed by one command invocation will be treated as one by undo. > The action would be only almost correctly indented - but not the last > two actions like (do-something). Reason: these sexps are top-level in > the code chunk, and Emacs Lisp indents it not relatively to some > previous line, but at column 0. > > We could again do some workaround if the indentation of the sub mode > indents at column 0 (that is exactly what I am currently doing), but it > again does not work for Python due to its indentation cycling. Yes, sorry. I'm actually doing the same as you: 0 column means top-level (and top-level means add N columns). The whitespace-padding is only performed in a certain, special case. Looking at `python-indent-line-function', it seems like it's going to cycle only under certain conditions (this-command is the same as last-command, and it's in the special list). From what I understand, it might even be what the user expects. If not, why not bind `this-command' to some odd value?