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: Sun, 22 Feb 2015 00:14:58 +0200 Message-ID: <54E90362.8070904@yandex.ru> References: <54E40954.7000706@yandex.ru> <54E4AC06.60300@yandex.ru> <54E54DE7.1010807@yandex.ru> <54E558C8.9040600@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 1424556919 30831 80.91.229.3 (21 Feb 2015 22:15:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Feb 2015 22:15:19 +0000 (UTC) Cc: "Wedler, Christoph" , "=?UTF-8?Q?Fabi=c3=a1n_E.Gallina?=" , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 21 23:15:19 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 1YPIKQ-0003x0-OG for ged-emacs-devel@m.gmane.org; Sat, 21 Feb 2015 23:15:15 +0100 Original-Received: from localhost ([::1]:37611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPIKP-0007Bp-Rb for ged-emacs-devel@m.gmane.org; Sat, 21 Feb 2015 17:15:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPIKL-0007Ac-Ly for emacs-devel@gnu.org; Sat, 21 Feb 2015 17:15:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPIKF-0007pf-Ai for emacs-devel@gnu.org; Sat, 21 Feb 2015 17:15:09 -0500 Original-Received: from mail-wg0-x22e.google.com ([2a00:1450:400c:c00::22e]:38730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPIKF-0007nq-0F for emacs-devel@gnu.org; Sat, 21 Feb 2015 17:15:03 -0500 Original-Received: by mail-wg0-f46.google.com with SMTP id a1so19215547wgh.5 for ; Sat, 21 Feb 2015 14:15:01 -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=6oMApS6U3XQyMnKbdri47myochsFLtp4yKJMeMpyi+E=; b=FpZMHh77O0fQhgOSV9K7VDylBJqqBa5lcgrgJcnrmGSkLbAkgz3HPmVc7DTPTmzSKN oEzvd4AICt3KbK4P1N4OSembzHbM3GgVbg8Px4o2P7yYgqxobBW+UN7dkaUA/Qlb9Kcd Q4efa6fz9DnpqbJkgui6bLM/UQ2yV4ng7p9k/doPnKJXT6uHvKxFBqFYVtNHN2LmBso5 zIblZi5csHSE4tASVYxSjc6oBDiTRk+7ILYAu+K6FpBlxRQ28iM2uf6hPTEoytSq+7eY wB0LIyzYrygefDmzJqK7+99/AOCBWmrQQ5s7/OIzMtdpEuPqrTfuGQql7EQZ2TS3qFbA xleA== X-Received: by 10.194.3.40 with SMTP id 8mr7934052wjz.98.1424556901865; Sat, 21 Feb 2015 14:15:01 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id dj4sm48352507wjc.13.2015.02.21.14.14.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Feb 2015 14:15:01 -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:c00::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:183370 Archived-At: On 02/19/2015 03:18 PM, Stefan Monnier wrote: > Could be. But using `widen' is a simple solution to those problems > (until you bump into problematic cases like Rmail and Info where > `widen' ends up widening too much). Maybe, whenever `widen' is required, the original caller is doing something wrong. The only valid use for `widen' is to undo the "visual" sort of narrowing, enacted by the user interactively. If that feature ever gets removed, I won't shed a tear. > BTW, a good start might be for someone to sit down and design a sane > way for narrow and syntax-ppss to interact. If that includes a cleanish > way to support multiple modes, then it's even better. My first reaction to this: invalidate the cache more often. Like if the cached entry is for the position above point-min, don't use it, and calculate the state starting from point-min. This way `syntax-ppss' will remain a good substitute for `parse-partial-sexp'. But then, do we allow it to add entries to cache (and save syntax-ppss-last), when narrowed? What will happen if syntax-pps is called without narrowing, after these entries are added? To keep ideal results, we'd have to save syntax-ppss-point-min-last, as well as include point-min in the cache entries, and invalidate the latter whenever it doesn't match. And I'm pretty sure, in this scenario, the cached entries from submode regions won't ever be useful in the primary region, nor a cache entry from one submode region will be useful in another. So we could as well discard them, and discard syntax-ppss-last after we leave (in a way dependent on the task we've using syntax-ppss for) the subregion. On the other hand, as long as narrowing is only used locally (within, say, `save-restriction'), the same function might as well bind `syntax-ppss-last' and `syntax-ppss-cache' to nil, so that multiple calls to `syntax-ppss' within the narrowing are still quick (that's important if the function in question is font-lock-fontify-region-function; a "composite" one, if we're discussing the multiple-mode case), but after we're done, nothing is remembered. The previously mentioned idea of adding a variable like syntax-ppss-function will help a lot more in the situation when there's no narrowing, and we need to compute the accurate level of nesting in the primary mode (or, to complicate everything by an order of magnitude, when we're in a region that itself has subregions, but I digress). To ignore several regions within, for the purposes of syntax-ppss. `add-function' could even be used instead of the new variable. To sum up: - Strong transient narrowing solves a class of problems. - Anyone doing it might have to take care of syntax-ppss cache (binding two vars to nil isn't hard). - The effect of persistent narrowing (one that lives between command invocations) should be only visual (the rest of the buffer contents are not displayed). Alternatively, if we're worried about editing commands changing text beyond the visible area, it should be made read-only. Or we just keep the current narrowing mechanism for visual purposes, and avoid using it outside of interactive commands. Or remove it entirely, like mentioned above. >> Not really. The leftmost-col avoidance scheme I described further on would >> deal with latex as submode just fine. > > Still: why do you want to avoid LEFTMOST-COL at all? I don't mind it that much, rather I'd like to avoid the variable submode-indentation-context. If prog-indent-calculate-function gets passed LEFTMOST-COL instead of nothing, that can work well. Benefits: - Since the value is passed to the function, the implementors are more likely to pay attention and include it in the calculation. - It's somewhat more likely that they get it right. That nil is returned in all top-level places, is much harder to test interactively. The one con, I guess, is a bit more complicated API. > I don't see how that influences the usefulness (or not) for > LEFTMOST-COL. Um yeah, it's irrelevant.