From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Fri, 1 Dec 2017 19:13:27 +0000 Message-ID: <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <20171129233238.504B5204F1@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <20171130214621.GA22157@ACM> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512158534 27941 195.159.176.226 (1 Dec 2017 20:02:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 20:02:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 Cc: Tom Tromey , Stefan Monnier , Vitalie Spinu , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 21:02:09 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKrVf-0006rP-Mf for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 21:02:07 +0100 Original-Received: from localhost ([::1]:60427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKrVm-0002H1-RD for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 15:02:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKqkg-0007tl-Gq for emacs-devel@gnu.org; Fri, 01 Dec 2017 14:13:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKqkc-00008c-6c for emacs-devel@gnu.org; Fri, 01 Dec 2017 14:13:34 -0500 Original-Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:38511) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eKqkb-000086-Ue for emacs-devel@gnu.org; Fri, 01 Dec 2017 14:13:30 -0500 Original-Received: by mail-wm0-x235.google.com with SMTP id 64so5072617wme.3 for ; Fri, 01 Dec 2017 11:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1J+VTVoj+c9n6/qi3yvuF+zRgepgyexyHhTejcQGhyw=; b=mmK/EumwUipr0bXCDL5yM27SXNytM6YehM+nfVCKm2iBPO2ldDAtHOzP1sjcx9Ttn6 UNvZXJyfPZD3owInY4A3Lg5Uj3dMQq1N3oipvlmkHCTpkQTyZ7OVEYt9dNoOVe/bEr80 vbkpiz6D8VNGHGbNK2JgWXzkFNMfmI3dMWN9TDza3XSVq6R2+NNzRMANx/3qTQssC40c gSFFONbHtRGRrc42y8DSohDCgLmcdA/dYUfnRkI1moA9Me7vk5Uo5Qbfz4baKnuc3NjR AYvxiyQI1CWBLc+thCYt/8IFvnHGqf6e8b/sdb181OGy7pwXfZxRh2okccOekMGq4/YL rsug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1J+VTVoj+c9n6/qi3yvuF+zRgepgyexyHhTejcQGhyw=; b=ZesboxhCLZ7YCj20XF93OZUGTDCcRzGv9qg46XkRhZ6nuoNgq5USkk3yGUbKHBfiYw O6yVuMPxjkEFgKF8qself6ysoBPMYMsnOnzm7V16sdU3j1rghLV1KWHjKs8cv9VcQDon mp7bR0gdXO5W03TTUtwsVxFyEQgt5VIEoR7JqkmvvGz5bsfITv2PwEAW8OLgt+wRqK0a hZUF+7uVaVW46fE1FDTWlLf1uKPzOazyMDNWE5T8v5YkTeQna+xEDcl+drKD29en8u7M icIbD6QQ+bZy35ZubQcjgFok+a55R13LhKbSnAYDAaHjy0raeAFwzdIvvZ8xWCR2l4++ ArsA== X-Gm-Message-State: AKGB3mKGDyoV0Nw4DcrUIlYxunK9aK08prXAnSM7WzHprtIKubQx42wi p4Iazw+jWyrUeG0TvgUgJT4= X-Google-Smtp-Source: AGs4zMZv7lP+M6DU92GAhfbJ5EZDBqa1jNBg5JuL/A36IX8LG4u4G5WelKJHh+I2RhZFIPgdjaDk6w== X-Received: by 10.28.120.2 with SMTP id t2mr1841208wmc.5.1512155608887; Fri, 01 Dec 2017 11:13:28 -0800 (PST) Original-Received: from [192.168.1.38] (89-160-235-67.du.xdsl.is. [89.160.235.67]) by smtp.googlemail.com with ESMTPSA id t10sm8867157wra.16.2017.12.01.11.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 11:13:28 -0800 (PST) In-Reply-To: <20171201154913.GB3840@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:220584 Archived-At: On 12/1/17 3:49 PM, Alan Mackenzie wrote: >> Please give an example. > > A low level function which as an essential part of its functionality > (for example, to make sure point-min isn't within a comment or string) > widens. See Stefan and I's responses. Including an example of a shim that wouldn't require you to change your code too much. But first and foremost, CC Mode probably doesn't need to worry about complying with this guideline (yet). In my experience, it doesn't work well in multi-mode context for reasons other than it calling widen. So worrying about this change in protocol might be premature. >> To rephrase, don't widen in indent-line-function or >> beginning-of-defun-function. > > This is an intolerable restriction. The low level function mentioned > above cannot, should not, must not know whether it's being called > (indirectly) from indent-line-function or b-o-d-function. It will have > to widen in all cases or none. Therefore there will be failures whilst > being called either from one of the two noted functions or from > elsewhere. See that shim in the other email. > Indeed it can, and it must. A super-mode thus may not "reserve" > narrowing for its own purposes to the exclusion of other uses. Right. > The multi-mode mechanism should be designed to be usable with any major > mode. There's nothing particularly hard about supporting CC Mode in a > well designed multi-mode scheme. It's harder than supporting Ruby, CSS and JS modes, that I can tell you for sure. For one thing, the extra caches CC Mode uses have given me multiple "argument out of bounds" errors when used with narrowing. So these are my takeaways: 1) The "low-level primitives" in CC Mode do not widen consistently. Some of them miss that responsibility (or else I wouldn't get those kind of errors). That tells me that moving (widen) call to some higher level is generally a good idea, but you can disagree. 2) The other errors should be solvable, but they require a separate investigation, which nobody has found the time and energy to do so far, over many years. So maybe it's not so necessary. 3) The solution to the other problems is most likely orthogonal to the current discussion. Allowing multi-mode packages to use narrowing certainly shouldn't hurt. > We need better tools. I have already proposed and offered to implement > such tools. It was much more complex, nowhere near even a proof of concept, and doesn't seem to move anywhere, so far. The change we're discussing is much smaller and pretty much implemented. And again, there's no reason why they couldn't coexist.