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, 02 Mar 2015 11:48:50 -0500 Message-ID: References: <54E40954.7000706@yandex.ru> <54E4AC06.60300@yandex.ru> <54E54DE7.1010807@yandex.ru> <54E558C8.9040600@yandex.ru> <54E90362.8070904@yandex.ru> <54F38FD3.1020307@yandex.ru> <54F47CD3.5080708@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425314957 11508 80.91.229.3 (2 Mar 2015 16:49:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2015 16:49:17 +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 Mar 02 17:49:11 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 1YSTWo-00056S-NG for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 17:49:10 +0100 Original-Received: from localhost ([::1]:58107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSTWo-0002ZY-4D for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 11:49:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSTWk-0002Ya-GM for emacs-devel@gnu.org; Mon, 02 Mar 2015 11:49:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSTWg-0002Mf-3B for emacs-devel@gnu.org; Mon, 02 Mar 2015 11:49:06 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:41388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSTWf-0002MF-Tw for emacs-devel@gnu.org; Mon, 02 Mar 2015 11:49:02 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t22GmsEo020987; Mon, 2 Mar 2015 11:48:56 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 4AF81AE124; Mon, 2 Mar 2015 11:48:50 -0500 (EST) In-Reply-To: <54F47CD3.5080708@yandex.ru> (Dmitry Gutov's message of "Mon, 02 Mar 2015 17:08:03 +0200") 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 RV5233=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5233> : inlines <2334> : streams <1398792> : uri <1869148> 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:183574 Archived-At: > Maybe we can say that code inside narrowing is only allowed to call > `generic' features, which may or may not perform widening themselves. I'm not sure what that buys us. > The uses of `syntax-ppss' are harder to classify, but for font-lock we at > least have font-lock-dont-widen. But that's very crude. It only accounts for those (rather rare) cases where narrowing is used to focus on a "sub-buffer" (i.e. Info mode, and old Rmail). If something uses narrowing in those modes, then the result is plain breakage. > It's hard for the "inner" code to know whether it's allowed to widen, > so when in doubt, it probably shouldn't. Most uses of narrowing should be widened, so the rule goes rather in the opposite direction (which is why font-lock-dont-widen defaults to nil, for example). > But to keep the current code everywhere more or less unchanged, we can come > from the other side and use an extra-flexible solution: introduce > `widen-function' or `widen-bounds'. Right, that's basically attacking the problem of distinguishing between different kinds of narrowing. But in any case, I think that relying on narrowing for the multi-mode support is a bad idea. It's OK if the API *allows* the use of narrowing, but requiring it would be a mistake. Stefan