From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Several Major Modes. Date: Fri, 15 Nov 2019 23:45:44 +0200 Message-ID: <4b4465c2-b148-b05f-2eb9-863d4548c672@yandex.ru> References: <20191109144026.20810.76129@vcs0.savannah.gnu.org> <20191109144027.DDC3720927@vcs0.savannah.gnu.org> <38328d99-23c8-7ba7-a23d-e70ac0aab67a@yandex.ru> <20191111203445.GA5135@ACM> <7497e71d-bab6-fa04-bbc4-f52fadeda16d@yandex.ru> <20191113211936.GB4942@ACM> <6fc930a1-eb47-9e54-8752-8cf7ff041586@yandex.ru> <20191114212454.GD4297@ACM> <4eb06378-b6ce-e6b6-5939-b1cb34267a9c@yandex.ru> <20191115201016.GA5257@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="91749"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 15 22:46:28 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iVjQB-000Nl6-N8 for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 22:46:27 +0100 Original-Received: from localhost ([::1]:45238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVjQA-0003eQ-83 for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 16:46:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52066) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVjPh-0003Ph-CN for emacs-devel@gnu.org; Fri, 15 Nov 2019 16:45:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVjPf-0003P2-CZ for emacs-devel@gnu.org; Fri, 15 Nov 2019 16:45:57 -0500 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:44104) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iVjPd-0003Mw-CB for emacs-devel@gnu.org; Fri, 15 Nov 2019 16:45:55 -0500 Original-Received: by mail-wr1-x434.google.com with SMTP id f2so12487507wrs.11 for ; Fri, 15 Nov 2019 13:45:48 -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=Gll8LnFy2H9EMLO2H0CQYtxP8kGeBCzFTiPi11AshhU=; b=t7hU7bPfCPP87a6sva7JCRRvaezqfefGDtRV9u9BdEetC3bHG0mxziOvis3W9TmAmJ 6qK2QP8RMVZNvq+ABwiXFrtDLxIzLxD37nlUwdi27ClYDcUrKDuNEuwBQG6SIUOY0WbG o5xKIZ+82QWFbMI3iPAVRVevlpCgfszoOhpF4wQCFxzjWWCWgTY7TDk5yEFVdQd8WKLS +l15Eah1UXabLxoaC7XNRH6DNhExTEWoLPxzGoOHvJXyZloC4KcWddW0iIySsUe+2GMZ MNAERE0iMDs5C0DEzTbJmCdARyVLPoD6gn4Ow8nQvoABirGkdgOMyAZ/OdKiPp7CvQyA nhoQ== 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=Gll8LnFy2H9EMLO2H0CQYtxP8kGeBCzFTiPi11AshhU=; b=MmPIb+ISg1pRhHgCUTagZiFSFi8qHA2fgTQx6YHg/2mr9Ic1rBB85Gl2Oqz29oJ8NF 72kqpc4uBxOns1scLUoOCVuJicSEzP8PDhHh9NXsX3zckVINsPvfV69PXt2lg+Su3LQW r8tdcho1LoEviRJRlPb5g/a0EVd58lCyrvOxObbJdRZKhkde5Db4G6KpV30jov+n0ECh 29JYejqG2VDOaq6DWBn1eh5L11GXNCH2GaHrgjPVbkv3u0tRux0vrTiD4NinNs7RJnnC 66zKRiGFHKojoV8EkZ8ce6Jnu7/KpCZYU4XXlUwa//PMdCBCFtn8d1zUCRoE+0TuKMtb JCAg== X-Gm-Message-State: APjAAAVa8Vgb9RBx/3O+h3taRwlEEEptmb/J49j/Sl8WEhjYMbQUI8Y2 S2kUQIzbAnCxqpxeDOevWdz5x6rRBGk= X-Google-Smtp-Source: APXvYqyamIuSAfBQk2Y4cha4Xc5CTC2AQMKJ2Sg5WTbb5xHCVK/S6PmVrUqfBCjnH6Q9M87ie49CpA== X-Received: by 2002:adf:eecc:: with SMTP id a12mr16963824wrp.363.1573854346627; Fri, 15 Nov 2019 13:45:46 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id y16sm13035486wro.25.2019.11.15.13.45.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 13:45:45 -0800 (PST) In-Reply-To: <20191115201016.GA5257@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::434 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:242248 Archived-At: Hi Alan, On 15.11.2019 22:10, Alan Mackenzie wrote: >> There are options. We'd have to decide on a suitable model, calling them >> islands or whatever, but I think the first approximation is to either >> make sure narrowing is available for this purpose .... > > You also need to make sure narrowing is available for any purpose > required by a major mode. Eh, I think it's "available" already, but I'd have to see specific examples. The problem which triggered this discussion is that *something* called font-lock rules from a narrowed buffer directly. But that's not a "purpose required by a major mode". >> Regarding "new type of local variable", mmm-mode already tracks >> something like that. > > I was envisaging something at the C level, where different regions of a > buffer would have different values of variables, without needing the > continual swapping at the Lisp level. Maybe such a thing isn't needed. I'd been told that even a C-based implementation is unlikely to make things much faster. Anyway, it would be a perf optimization, and we could get to it later. > It can't work if any external Lisp corrupts its syntax-table text > properties. This is what syntax-ppss-flush-cache (on > before-change-functions for many modes) would do if there were a non-nil > syntax-propertize-function at the time. This may be the biggest problem > to getting CC Mode integrated into MMM Mode. mmm-mode sets its own syntax-propertize-function that calls major mode specific syntax-propertize-function's over their respective chunks/subregions. So, in principle, that should work fine. As long as nobody calls 'widen' unexpectedly. >> Is it feasible to support embedded chunks? To support chunks with >> incomplete pieces of code (which are e.g. included conditionally by the >> surrounding template)? > > Well CC Mode already supports preprocessor macros and (for C++) raw > strings, which are syntactically somewhat and very different from the > enclosing code. I'm not sure it's the same. Like, would CC Mode cope with a region starting with closing brackets, etc. This might not be a frequent situation, but at least it shouldn't blow up.