From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 3 Dec 2017 14:54:46 +0000 Message-ID: <20171203145446.GB5531@ACM> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512313286 30583 195.159.176.226 (3 Dec 2017 15:01:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 15:01:26 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Tom Tromey , Stefan Monnier , Vitalie Spinu , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 16:01:22 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 1eLVlg-0007ey-M7 for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 16:01:20 +0100 Original-Received: from localhost ([::1]:39197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLVlo-0005H8-2r for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 10:01:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLVl6-0005Gw-0C for emacs-devel@gnu.org; Sun, 03 Dec 2017 10:00:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLVl2-00086K-VH for emacs-devel@gnu.org; Sun, 03 Dec 2017 10:00:44 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:31164 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eLVl2-00085g-Jo for emacs-devel@gnu.org; Sun, 03 Dec 2017 10:00:40 -0500 Original-Received: (qmail 41858 invoked by uid 3782); 3 Dec 2017 15:00:38 -0000 Original-Received: from acm.muc.de (p548C6938.dip0.t-ipconnect.de [84.140.105.56]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 03 Dec 2017 16:00:37 +0100 Original-Received: (qmail 8500 invoked by uid 1000); 3 Dec 2017 14:54:46 -0000 Content-Disposition: inline In-Reply-To: <6a612831-a73f-2223-822f-7d594ebdff30@yandex.ru> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:220651 Archived-At: Hello, Dmitry. On Sun, Dec 03, 2017 at 03:52:59 +0000, Dmitry Gutov wrote: > On 12/2/17 8:28 PM, Alan Mackenzie wrote: > > It would work, and work well, for the simple reason it is a coherent > > proposal. > I've never seen a full proposal. Details matter. And it's going to have > to include a lot more of them. 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. > > Emacs was designed with the assumption that each buffer has exactly one > > major mode. It turns out this assumption hasn't held all that well. > > When that assumption does hold, the following returns a well defined and > > meaningful state: > > (parse-partial-sexp 1 n) > > . I am proposing extending this property for buffers with several > > modes and several syntax tables. Nothing more, nothing less. > Extending parse-partial-sexp to nested syntax tables can be worthwhile, > but that can't be it. And while we're on this subject, there are some > example of Ruby syntax that we'd like to see supported, where the > current syntax tables (and even syntax-propertize-function) don't cut it. What is preventing a s-p-function from working satisfactorally? > I'm not convinced "several syntax tables" would be enough, though. OK, let's make that "many syntax tables". :-) > > You're saying that providing support for multiple major modes in the > > Emacs core is a pipe dream. I put it to you you're mistaken. ONLY by > > supporting this in the Emacs core can we arrive at a coherent efficient > > design. > 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.) > > The fact we are having this conversation is a strong indication > > that the current designs for MMM are not coherent enough. > 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. > Coming up with it was not easy at all, BTW. Yes, I can see that. Well done! > >> Also, I don't think major modes need more freedom in how to implement > >> things. Instead, they need more help so they can just use existing > >> solutions rather than reinvent the wheel in their very own way. > >> Conventions/guidelines actually makes the life of major mode > >> implementers easier, rather than harder. > > That is immensely patronising. > 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: 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. In CC Mode, the job is done by c-before-change-check-<>-operators. -- Alan Mackenzie (Nuremberg, Germany).