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: Sun, 3 Dec 2017 23:53:27 +0000 Message-ID: <9ffd8834-951a-be7a-2cbc-c57945393fe4@yandex.ru> 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512345253 8369 195.159.176.226 (3 Dec 2017 23:54:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 23:54:13 +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 Mon Dec 04 00:54:06 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 1eLe5B-0001Vn-Bv for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 00:54:01 +0100 Original-Received: from localhost ([::1]:40574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLe5I-0001CD-38 for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 18:54:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLe4i-0001Bw-DU for emacs-devel@gnu.org; Sun, 03 Dec 2017 18:53:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLe4h-0000Jm-CN for emacs-devel@gnu.org; Sun, 03 Dec 2017 18:53:32 -0500 Original-Received: from mail-lf0-x230.google.com ([2a00:1450:4010:c07::230]:45693) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLe4h-0000JM-3T for emacs-devel@gnu.org; Sun, 03 Dec 2017 18:53:31 -0500 Original-Received: by mail-lf0-x230.google.com with SMTP id f13so17151671lff.12 for ; Sun, 03 Dec 2017 15:53:30 -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=uAU2zMJcTWr3SjU3qicdKWKM7WqB3/fMe/6MZ3XbDSs=; b=lZGT31STwiCqptKyUjsVdRe3HMB4rdHGoAJEf5PN31aUYGODrhC+XtzdEqV41/FKWG gRYmH5FYLT1Q3mVYJOU5w4jfVZ4smcUBZ7yOuMopbaZmYCt5TTxPhslJsn39V8ocjCIQ zOCq7Yg5PqpXctpv7oPFTtwWdABTWQd2P4RJ2Jsi2CfK6UeA6Mf4dZqFqzEzKwHsbhNc olwGm3hxbVqeiawoNv7d97i1raqX8Fas5pVsLPMuVbj7SONjn8O/H8sJohvUY/HrkQ+z ucdmwqumPQi/2PmKzu+MJMAxPlv6/BwltrbbPFO061fTrNJa0P51VAAUCR18MY6d951F zb7w== 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=uAU2zMJcTWr3SjU3qicdKWKM7WqB3/fMe/6MZ3XbDSs=; b=P43IyCicvH4b1C8x6wIcP7TAIpxS+rdNMOZ/6YOc+CMbCqVPlFOqCE9bQpBPxxnGzW M0Ii7Q+JmE7cpFYTxmigYjDxrj0Nomxej9C3X49RzIHPSCE6EN2Ey/Iv9yA92iVywQDB SnwrMWyK/WuFyyYfRDGilHQ87/ix8yotIYipOuPynsDL2XZc4R3t5NoSQ6+5vZfibtnP 0HV3/SzI3TeTYjoM4rQ9qpqQIUdVSkMTayQNRLDdnaac1uQz7hUzufonaO/QURwuIWig g42qCZa3CM9oJbWWcDP2kYKdddYEmWt2kAUXuPijHuTXFsveeE7zgsyRLCj6sfBJyWRf C36Q== X-Gm-Message-State: AJaThX5g8/AwalJuA6OQ0c48P02u8jZQ8U5B2SZqkX/QxGzI2kfH/1dm tRa9kmn97LmC5uJdJRnuhLIbEfrj X-Google-Smtp-Source: AGs4zMaPchvyDLiO/SrTmhEpXlndfOzFW3CMjhhO5cOzZzf0wttrA2Qk7H3WFTE9KaDxgtcQ+vOTuQ== X-Received: by 10.46.2.204 with SMTP id y73mr8392653lje.183.1512345209333; Sun, 03 Dec 2017 15:53:29 -0800 (PST) Original-Received: from ?IPv6:2a02:a311:413e:e480::4? ([2a02:a311:413e:e480::4]) by smtp.googlemail.com with ESMTPSA id r89sm2493381ljr.16.2017.12.03.15.53.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Dec 2017 15:53:28 -0800 (PST) In-Reply-To: <20171203145446.GB5531@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::230 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:220671 Archived-At: On 12/3/17 2:54 PM, Alan Mackenzie wrote: > 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. > > I've changed my mind about some of the details, partly in response to > what people said, partly because I see things now I didn't see then. Thanks. I've read it, and you've seen my comments. >> I'm not convinced "several syntax tables" would be enough, though. > > OK, let's make that "many syntax tables". :-) TBH, it's hard for me to tell with confidence either way. But here's the kind of syntax that Ruby allows: a = %Q( #{ %q{abc} + %q{ "#{"abc #{ %q[ abc ] }" }" } } ) These are all nested literals (with the exception of #{}, which is interpolation). Thus exiting from a literal requires the knowledge of all openers that have been used before it, and a pre-defined set of syntax table (if I understood you correctly) won't do. >> The major modes will have to change to allow for this support, that's >> for sure. You can't expect no code changes. > > Maybe, maybe not. Super-modes would definitely have to change to use > it. Any changes in major modes should be minor. (I don't rate > restrictions on the use of Emacs primitives to be minor.) Major modes will have to work inside arbitrary restrictions one way or another. That's the crucial part, and it will require changes. >> The current idea is "let's do the minimum coherent step forward, so that >> somebody can continue improving things later". A step that's easy to >> use, and also easy to undo later, if we find something else that's much >> better. > > OK. With such a tricky subject matter, it would surprising if we > couldn't find improvements for a long time. Since it's tricky, I would bet in the opposite direction. But there's no way to predict. >> Coming up with it was not easy at all, BTW. > > Yes, I can see that. Well done! If you are not being sarcastic, thanks! Could you please stop opposing it? >> It's simply description of good engineering. You can try to criticize >> the details of syntax-propertize, but the idea of reusing common >> solutions is more than sound. > > 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: Sorry, I'd rather you put it in a separate discussion. But, like Stefan described, this example is very much solvable with syntax-propertize (which I could have told you independently, too).