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: Sat, 2 Dec 2017 20:28:55 +0000 Message-ID: <20171202202855.GA22133@ACM> References: <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512246904 25171 195.159.176.226 (2 Dec 2017 20:35:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 20:35:04 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Tom Tromey , Vitalie Spinu , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 02 21:34:58 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 1eLEUv-0005sa-5m for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 21:34:53 +0100 Original-Received: from localhost ([::1]:36881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLEV2-00055i-Jc for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 15:35:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLEUv-00055b-JH for emacs-devel@gnu.org; Sat, 02 Dec 2017 15:34:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLEUn-0005Cl-T1 for emacs-devel@gnu.org; Sat, 02 Dec 2017 15:34:49 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:59085 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eLEUn-00059x-HX for emacs-devel@gnu.org; Sat, 02 Dec 2017 15:34:45 -0500 Original-Received: (qmail 61004 invoked by uid 3782); 2 Dec 2017 20:34:40 -0000 Original-Received: from acm.muc.de (p548C6EEA.dip0.t-ipconnect.de [84.140.110.234]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Dec 2017 21:34:39 +0100 Original-Received: (qmail 22358 invoked by uid 1000); 2 Dec 2017 20:28:55 -0000 Content-Disposition: inline In-Reply-To: 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:220630 Archived-At: Hello, Stefan. On Fri, Dec 01, 2017 at 21:47:26 -0500, Stefan Monnier wrote: > >> "OK, implement it and we'll see what we can do with it", no > >> encouragement whatsoever. There was no discussion of major topics, such > >> as the possibilities it would open up, or any plans to use it. Mainly, > >> the talk was about minor aspects of the proposal, at one point > >> degenerating into a squabble about the use of the word "island". > Here's my opinion: experience shows that implementing MMM support is messy > for all kinds of reasons, and that the problems that show up in practice > are very varied and many of them are completely unexpected. > So any paper design such as your "islands" to me sounds like a plain and > simple pipe-dream. Can it work in theory? Sure, why not. Can it work > in practice? Probably. Will it work without having to "pollute major > modes to adapt to that particular MMM"? Not a chance in hell, IMO. It would work, and work well, for the simple reason it is a coherent proposal. 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. 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 fact we are having this conversation is a strong indication that the current designs for MMM are not coherent enough. [ .... ] > 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. > E.g. they can just use `syntax-propertize` and move on. If it's not > efficient enough or if it doesn't interact correctly with an MMM > framework, it's not their problem it's syntax-propertize's. syntax-propertize is your way of doing things, so naturally you want it to become a "standard". However it is not the only way of doing things, and is suboptimal in several respects. When designing syntax-propertize, with whom did you discuss the technical aspects? Certainly not with me, but this may have been before my time in Emacs. With Martin Stjernholm or Barry Warsaw, my predecessors as CC Mode maintainers? With RMS? With anybody at all? > Stefan [ .... ] -- Alan Mackenzie (Nuremberg, Germany).