From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 03 Dec 2017 13:40:22 -0500 Message-ID: References: <20171130214621.GA22157@ACM> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <20171202202855.GA22133@ACM> <6a612831-a73f-2223-822f-7d594ebdff30@yandex.ru> <20171203145446.GB5531@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512326436 29881 195.159.176.226 (3 Dec 2017 18:40:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 18:40:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Tom Tromey , emacs-devel@gnu.org, Vitalie Spinu , Dmitry Gutov To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 19:40:32 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 1eLZBl-0007RA-Lx for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 19:40:29 +0100 Original-Received: from localhost ([::1]:39837 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZBt-0002OJ-2M for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 13:40:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZBm-0002O3-50 for emacs-devel@gnu.org; Sun, 03 Dec 2017 13:40:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLZBi-0007VG-Sw for emacs-devel@gnu.org; Sun, 03 Dec 2017 13:40:30 -0500 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:43955) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLZBi-0007UR-GE for emacs-devel@gnu.org; Sun, 03 Dec 2017 13:40:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HvBgBcRCRa/6uapUVbHAEBAQQBAQoBA?= =?us-ascii?q?YM8gVSPOo4BAYF8FCABmGEKhTUEAgKFKkQUAQEBAQEBAQEBA2gohSMBAQEBAgE?= =?us-ascii?q?nLyMFCwsOCR0SFBgNFg4uiX8Iqgg6ilUBAQEBAQEEAQEBAQEjjDWLGQWTGo9So?= =?us-ascii?q?QuHXJY9EIE6NiOBTTIaCDCCZIMGgWwjimUBAQE?= X-IPAS-Result: =?us-ascii?q?A2HvBgBcRCRa/6uapUVbHAEBAQQBAQoBAYM8gVSPOo4BAYF?= =?us-ascii?q?8FCABmGEKhTUEAgKFKkQUAQEBAQEBAQEBA2gohSMBAQEBAgEnLyMFCwsOCR0SF?= =?us-ascii?q?BgNFg4uiX8Iqgg6ilUBAQEBAQEEAQEBAQEjjDWLGQWTGo9SoQuHXJY9EIE6NiO?= =?us-ascii?q?BTTIaCDCCZIMGgWwjimUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,355,1508817600"; d="scan'208";a="10655626" Original-Received: from 69-165-154-171.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.154.171]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2017 13:40:22 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9042AAE0F2; Sun, 3 Dec 2017 13:40:22 -0500 (EST) In-Reply-To: <20171203145446.GB5531@ACM> (Alan Mackenzie's message of "Sun, 3 Dec 2017 14:54:46 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.36 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:220657 Archived-At: > Details do matter. I posted a full proposal, Subject: "Syntax > ambiguities in narrowed buffers and multiple major modes: a proposed > solution." here in emacs-devel on Sat, 25 Feb 2017 13:53:56 +0000. For the reasons exposed before, contrary to Dmitry, I don't really care about seeing a detailed proposal. I know full well that I'm absolutely unable to run such the paper-design in my head and predict if it'll really work. > I don't rate restrictions on the use of Emacs primitives to be minor. I think there's a fundamental misunderstanding abut Dmitry's suggestion here: his proposal does not restrict the use of any primitive anywhere. The only thing it does is to make the calling convention of indent-line-function a bit more precise: instead of not saying anything about the kind of narrowing that can be in place when that is called, it specifies that the caller should arrange the narrowing to expose "all" the code, and so the callee doesn't need to widen (which is useful since in an MMM context, the sub-mode usually doesn't know how far it should widen). The indent-line-functions can still narrow/widen all it wants. And the callers of indent-line-function also can still widen/narrow all they want. Just as is the case now, depending on how they narrow/widen the result may be incorrect. And the novelty here is to provide a convention that, if followed, should make it more likely that the result is correct, without the caller and the callee being aware of each other, because they only care about the shared convention. > If those common solution are adequate, yes. But it is also critical to > have the freedom to depart from things like syntax-propertize when they > are inadequate, or too awkward. syntax-propertize is inadequate for CC > Mode: > > E.g., in C++ Mode, with > > foo (a < b, c > d); > > we have a constructor foo with one parameter d, of a templated type. The > characters "<" and ">" have syntax-table text properties giving them > paren syntaxes and making them match each other. > > Now, mark the characters ", c > d" and kill them with C-w. What we are > left with is a function call with an integer argument a < b: > > foo (a < b); > > . Something, somewhere has to remove the syntax-table property from > "<", since it is no longer a template delimiter. > > The syntax-propertize mechanism won't do this, since the place to > de-propertise is before BEG. syntax-propertize is no silver bullet, indeed, so it won't do everything magically for you. But, it can handle the above situation just fine. In your very specific above example, it will actually be handled magically simply by virtue of syntax-propertize-wholelines being included in the default value of syntax-propertize-extend-region-functions. Now, of course, if you tweak your example so that the < and the > are not on the same line any more, that magic won't work. But that doesn't mean you can't make syntax-propertize handle it right. You could for example solve it with: (add-hook 'syntax-propertize-extend-region-functions #'syntax-propertize-multiline nil t) in your major mode function and (put-text-property position-of-left-< position-of-right-> 'syntax-multiline t) when you find (and put the syntax-table property on) the <...> pair. Of course, it's not the only possible way to do it. It's just the way I solved similar problems in perl-mode and sh-mode. If you're interested in making CC-mode work reliably with syntax-propertize I'd be *thrilled* to help you do that. By design, there should be basically nothing syntax-propertize can't handle (modulo bugs and within the limits of what we can do with syntax-tables and syntax-table properties, obviously). I have no doubt that the way CC-mode works right now will occasionally be more efficient than the way syntax-propertize would do it. But I also have no doubt that the way syntax-propertize would do it will occasionally by more efficient than the way CC-mode does it right now. I strongly doubt that the difference in performance behavior will ever matter, tho. Stefan