From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.] Date: Mon, 21 Mar 2016 06:05:26 +0100 Message-ID: <87twk0beuh.fsf@gmail.com> References: <20160311151512.GD2888@acm.fritz.box> <20160311212410.GG2888@acm.fritz.box> <73903215-f94b-e194-7bfe-0d6350c95769@yandex.ru> <20160311221540.GH2888@acm.fritz.box> <2c301ec9-041d-9172-d628-479062314b23@yandex.ru> <20160314151621.GF1894@acm.fritz.box> <874mc2dqtk.fsf@gmail.com> <87egb5cpmg.fsf@gmail.com> <87a8lsd4j3.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458536745 13830 80.91.229.3 (21 Mar 2016 05:05:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 05:05:45 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 06:05:40 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ahs26-0001ef-8E for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2016 06:05:38 +0100 Original-Received: from localhost ([::1]:55646 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahs25-0007cP-GC for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2016 01:05:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahs21-0007cJ-Ac for emacs-devel@gnu.org; Mon, 21 Mar 2016 01:05:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahs1y-0002vm-0W for emacs-devel@gnu.org; Mon, 21 Mar 2016 01:05:33 -0400 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:37731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahs1x-0002vi-KG for emacs-devel@gnu.org; Mon, 21 Mar 2016 01:05:29 -0400 Original-Received: by mail-wm0-x231.google.com with SMTP id p65so107587299wmp.0 for ; Sun, 20 Mar 2016 22:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=AH0bL/k3aFYRWo9OXnpX6K6VuNY4N0OW+DCoK07tlvc=; b=SlLcFUCuBNt1awniP0OIVhHD32CDr9+K8bJ9P4XEfDcyshgfJWJkavWdOtFfyPTYlz lQgRc8hXshgDZJWHCoxtoAeTnYRNMwvJ4dqLDAVlv0WvA98QmThy1YlwV0tFww8WMyvp z+utrpudLP1TfKNhI+hvKWkH1U/CWJJq+4Y4ZGDrRasiaSQImZh2zUMP/W01GGwdQTct gTjsGscuCmBace1w9sa7Nv/fqAmiYQQUp+TPOjRCfjS0aOz08+nG/n22smnJ0puoWPI7 eUDiictyTmdGdcqIuKGAyyfFmuMMoOf/xyu+jzqOUJhnttj9DKqDXJMZ73gZYe4vzM5p OhSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=AH0bL/k3aFYRWo9OXnpX6K6VuNY4N0OW+DCoK07tlvc=; b=YIJjrqHC7JEH4ialcyrSHHhFiTnWutwIYhdDkJHScmcPZKjnmvT8o0NcJhrTA8isUv le5n/FYVSeFsV+AwZsLDo6y5YD231ipUOnS22CEAlD+tBO05LblC1PnJxLjWR3PxiHQe b+w5spFMyLQsLmcljKDjhPa98wNH3kVZ9ABcU070BiYIun0hnMRy111RsfZFp8sM9z3Y uefh6HXg9bXsUF6gSeHoLnK6+I7Vf4w6tdq1ebo+ivyhFuYuZO/JLV/mSqnaTZig+ppi fhlwnsCdDsAKQxK1ELvKQIEfeRn4tdN/iXfu+J9I8f/8EXY5H/moDal6nyoKzAWd6jzZ tjSQ== X-Gm-Message-State: AD7BkJKCCIXR2qh5bkWTpv+djmK3Lyj7IxW2Vpsl79WGdPFqr1Z+M7GAVoCgcG9u75ZEwg== X-Received: by 10.194.222.234 with SMTP id qp10mr27946230wjc.138.1458536728626; Sun, 20 Mar 2016 22:05:28 -0700 (PDT) Original-Received: from localhost ([143.176.214.220]) by smtp.gmail.com with ESMTPSA id v188sm10561744wmv.3.2016.03.20.22.05.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Mar 2016 22:05:27 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Sun, 20 Mar 2016 23:11:52 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201970 Archived-At: >> On Sun, Mar 20 2016 23:11, Stefan Monnier wrote: >> BTW, I parse-partial-sexp must abide hard-widen-limits as well. > I don't understand what this means. parse-partial-sexp is passed > 2 locations and it works between them. There's not much opportunity > for widening. parse-partial-sexp should work between hard limits (at least the lower bound). It should operate as if hard-narrowed buffer is the real buffer. So ideally it should take (max FROM (car hard-widen-limits)) as the starting position. This will give the desired consistency between parse-partial-sexp and syntax-ppss with the price of slightly modifying the semantics of parse-partial-sexp in a backward compatible way. >> A patch that would require hunting every single mode out there and >> implementing multi-modes locally should have been more carefully >> considered IMO. > I must say I don't understand how what we have is so very different from > what you suggest. It's quite a bit different: - Major mode authors won't need to know about multi-modes. That means not dealing with chunks/spans/headers etc. These concepts are not even uniformly defined between existing multi-mode engines. - Major mode authors won't need to re-implement the indentation logic already there in multi-modes. The logic is likely to be too simplistic and major mode authors will have to re-do it anyways. - Setup is more general. multi-mode engine decides where to call calculate-indent-function and with what parameters and with what narrowing. - Arguably calculate-indent-function is a simpler concept to grasp - calculate-indent-function is needed anyways > I think both suggestions require changes to every mode, and in both cases the > changes can be reduced to a one-liner or close enough (for the simple > case). Admittedly, for it to be a one-liner, we'll need to provide a standard > helper function. Judging from python.el it might be quite hard to provide a generic one liner to deal with all those 3 elements. For calculate-indent-function instead you can provide a straightforward one line assuming that STRING-BEFORE/AFTER do not matter. Vitalie