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: Sun, 17 Nov 2019 14:48:35 +0200 Message-ID: <12fbf5de-e4a8-cfc5-b92e-be368eb2c1f4@yandex.ru> References: <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> <4b4465c2-b148-b05f-2eb9-863d4548c672@yandex.ru> <20191116131007.GB6711@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="257922"; 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 Sun Nov 17 13:48:59 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 1iWJz5-0014lz-Fy for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 13:48:55 +0100 Original-Received: from localhost ([::1]:53488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWJyx-0003Mr-UI for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 07:48:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45306) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWJyr-0003Mh-05 for emacs-devel@gnu.org; Sun, 17 Nov 2019 07:48:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWJyp-0002hd-TK for emacs-devel@gnu.org; Sun, 17 Nov 2019 07:48:40 -0500 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:50630) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWJyp-0002hO-Mx for emacs-devel@gnu.org; Sun, 17 Nov 2019 07:48:39 -0500 Original-Received: by mail-wm1-x336.google.com with SMTP id l17so14483438wmh.0 for ; Sun, 17 Nov 2019 04:48:39 -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=pIk6tGkjsY4qSxLMoblUS5WBIs4XPLQMNvXZpnPkC4g=; b=UkE0HaXJU/BzRQl6x4CZ6UzLVjzyIxleCcHjwPCWkJvp+X0FqjQ+56ngvon47utePM 4DT2wkY+qpnu2uNRip/0iWMuRLwtf+w+WcsitKpdVIje9NF0kkKaA20oddz03trShziN J/DWy9uW+zHPXZHRjDsO7C6UY7mDmRa2xyk1+sufVlMGuPMViNQCnbtGTEqGOaznh6iU KuLIUJn8c2LTxWxl2I5iNeP1oJnOCQ7RN3cyxuk3gsjEW+9/LrdThMnCKEnG9iwma+o4 rbHGNtrVUY96yrlI+oKYkVTBEXGbaTyE9Tf4Gb201o90C8Ylss1f8ofmz1kzUqsAT34y uvYg== 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=pIk6tGkjsY4qSxLMoblUS5WBIs4XPLQMNvXZpnPkC4g=; b=dzzO+1e4jIGBp33fHoqpOvGiii/fTMePlJAEZo+fm70a5wwcRXt9Ur2EvgUf4ySyBa QuMIVQt3ynHmowmgu2JssJcTsK637tA3MJyPVu+yVT/fvl1TZAEFyP6OskHp1qpakpdj WevJrVaQfxcCXc9wUoVqbWb+jRrQgthDYHnO/dWU+bbTGxcf9ex7+StesrOTeFpipntH YtTJuI6SOxlYuQixfY8UoMVQ59wXm9VYYfo1hrPfGrFtCWz426xPiLoVX9E5+4uKyCzW 9iyGNg5+HeQ9hRXsuF8U8mpG9rNSeEM6JBgwYXplS6vabIL5xOZTPdI7YDUP9hYoxwGU mauw== X-Gm-Message-State: APjAAAXKYYb893uhW82+8Mn/vJqvtVjaB1m0QWsXu9WAfC3LD2LkEtbQ ouAXqMKzE1Qva1CmuGTGXK3qVbPloXo= X-Google-Smtp-Source: APXvYqyhz1QAMgkCqxcKS/Iq9uQwfnHIlx/rczuSpTrJ2D+uDHjgpjxC1Qyp76ANvvViDLPhVMiTNQ== X-Received: by 2002:a1c:3c43:: with SMTP id j64mr24204639wma.13.1573994918194; Sun, 17 Nov 2019 04:48:38 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id c24sm22370988wrb.27.2019.11.17.04.48.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 04:48:37 -0800 (PST) In-Reply-To: <20191116131007.GB6711@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::336 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:242275 Archived-At: Hi Alan, On 16.11.2019 15:10, Alan Mackenzie wrote: >>> 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. > > Oh good! I have to admit I haven't actually seen MMM Mode running, or > at least I don't remember it. I think we won't really know until there's a good change of CC Mode working with MMM Mode, so then people could try and exercise various features. And we'll see what works and what does not. > I've taken a closer look at the functions in syntax.el, and I think > you're right. The removal of the syntax-table text properties happens > up to END, not to EOB. It would merely need syntax-propertize-function > to be nil whenever anything involving the CC Mode region (including > fontification) happens. Yes, it should do that already. >>>> 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. > > Maybe having several sets of syntax-table text properties in a buffer, > one set for each sub-buffer, would help. I devised and half-implemented > such a facility back in 2017, calling it "indirect text properties". To > switch to a different set of properties, you would merely have to set > (or bind) a dynamic variable. > > With this, I could set whitespace syntax-table props all over the non-CC > Mode regions while CC Mode is "in scope", thus making syntactic stuff > and fontification easy. It's an interesting suggestion, but a difficult problem. Like, if you just swap the meanings of syntax-table text properties, it would make syntax-ppss caches invalid without telling it. A better solution would be to somehow integrate with it. Anyway, you mentioned a real problem (for which I only have workarounds thus far), but for now I was just asking whether an isolated "incomplete" chunk would work okay.