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 03:52:59 +0000 Message-ID: <6a612831-a73f-2223-822f-7d594ebdff30@yandex.ru> 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> <20171202202855.GA22133@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 1512273227 13575 195.159.176.226 (3 Dec 2017 03:53:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 03:53:47 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 Cc: Tom Tromey , Vitalie Spinu , emacs-devel@gnu.org To: Alan Mackenzie , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 04:53:39 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 1eLLLV-000329-At for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 04:53:37 +0100 Original-Received: from localhost ([::1]:37761 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLLLc-0003KD-49 for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 22:53:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLLL0-0003K8-Q2 for emacs-devel@gnu.org; Sat, 02 Dec 2017 22:53:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLLKz-0000tm-OG for emacs-devel@gnu.org; Sat, 02 Dec 2017 22:53:06 -0500 Original-Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]:35137) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLLKz-0000tS-Fr for emacs-devel@gnu.org; Sat, 02 Dec 2017 22:53:05 -0500 Original-Received: by mail-lf0-x22c.google.com with SMTP id j124so15637054lfg.2 for ; Sat, 02 Dec 2017 19:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S9wimg2Jgni33UZoP97Jm1kjV7XhX7fUKWwvbn+SgME=; b=I/+BaCHz4U6n9nO/gDDcLW6gi33CkD58FqHKaATwwevYFHSVt2srzuNWgsMtvwzupn fW3FKDdvH7oi0AyaB8ukR6KU2fxAOQodsbI3K8RLg+AEhcl7OMneh/zKdLdrxjGfJTH9 f4Kq6ZeNPFs3P8JYH3fYrZdbo04WhG/lv20XKqYkvDZF/hRO724ynD6/I0YBUuZonCMK KHENmp1dNLk4ZmxeGoo4WXIiLq55McXcmMwC9v4t+QCrR0/kjBXCZynji1rIZbTeSjTf vLNGmncp+PeHjO8kj6bvA/Ti8WFIWpNJNpZ+bdyxtH4SLJkrP6rqZWlJJGwXm+CN7km0 E+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S9wimg2Jgni33UZoP97Jm1kjV7XhX7fUKWwvbn+SgME=; b=iTDUt/eq+eXp01Fz01JKmzWwDdH4BP/oZY0fdApdNJajxWXO+jO5xrFraFrOhlq+sy oo95Hi3Fp2RNB9ot1LDw8Nyy/sQflilHJaJREA3EoajJaHswIXsGWlOj9GvepvOuYhgy m9FUnzpNnoX7cQPi30jURR5xXxee4E7WeojBhTlBt/sxpMx1Pu6WmoslysRSoA6i1E5p NdEbA1yX3nMgvLIkXFO5TQBzL41rDjYw9XoL8CujwERGcWf8bHsUF5MiVRgFyVIeLtAT xtYIVbLT6p29MVYZgSatKvBCSJmqAEqNNTeVSonwXu01fzShwPf6OOKHzbH+qS6l1OX+ hf3Q== X-Gm-Message-State: AJaThX6afoFPAVpKgE+FhhD2RCFiPYPwp3C0eXnE5iQ/csSwZYI5KQnF AVruT4HDrfnT78dZAoIDYFp8hvSSiGU= X-Google-Smtp-Source: AGs4zMbJDFtrDs1LwfBOeppPsxOEDR9p6Bko6WXfnx18jFfi4gEh3ga4w8UPGQnpnP0OeEWs+6pMLA== X-Received: by 10.46.93.13 with SMTP id r13mr7089830ljb.102.1512273183704; Sat, 02 Dec 2017 19:53:03 -0800 (PST) Original-Received: from ?IPv6:2a02:a311:413e:e480:a5a4:ff2f:5a78:5eb7? ([2a02:a311:413e:e480:a5a4:ff2f:5a78:5eb7]) by smtp.googlemail.com with ESMTPSA id b25sm2051071lje.14.2017.12.02.19.53.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Dec 2017 19:53:02 -0800 (PST) In-Reply-To: <20171202202855.GA22133@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::22c 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:220643 Archived-At: 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. > 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. I'm not convinced "several syntax tables" would be enough, though. > 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. > 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. Coming up with it was not easy at all, BTW. >> 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.