From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Indirect text properties Date: Sun, 17 Nov 2019 17:05:27 +0000 Message-ID: <20191117170527.GB11551@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="213513"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 17 18:05:42 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 1iWNzX-000tLT-7E for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 18:05:39 +0100 Original-Received: from localhost ([::1]:55074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWNzV-00075e-Tu for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 12:05:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37622) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWNzP-00075U-Sp for emacs-devel@gnu.org; Sun, 17 Nov 2019 12:05:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWNzO-0004z2-Pu for emacs-devel@gnu.org; Sun, 17 Nov 2019 12:05:31 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10211 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iWNzO-0004y7-GZ for emacs-devel@gnu.org; Sun, 17 Nov 2019 12:05:30 -0500 Original-Received: (qmail 22462 invoked by uid 3782); 17 Nov 2019 17:05:28 -0000 Original-Received: from acm.muc.de (p4FE150B7.dip0.t-ipconnect.de [79.225.80.183]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 17 Nov 2019 18:05:27 +0100 Original-Received: (qmail 13625 invoked by uid 1000); 17 Nov 2019 17:05:27 -0000 Content-Disposition: inline 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.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:242281 Archived-At: Hello, Emacs. This is an idea I had a couple of years ago, and has recently resurfaced in discussions with Dmitry (Subject: Several major modes). The idea is that there could be several alternative sets of text properties with the same symbol simultaneously in a buffer, the Lisp code selecting which to use by binding a dynamic variable. This would be most useful for the syntax-table text property. How would this work? In textprop.c, the code would, on any access to a text property, check its symbol's property 'indirect-text-property, and if that is a non-nil symbol, access it's value (another symbol) and use that as the symbol for the text property instead. It's easier to say in code, which would look something like: #define TEXP_PROP_END_NAME(sym) \ !NILP (itp = Fget (sym, Qindirect_text_property)) && SYMPOLP (itp) \ && !NILP (etp = find_symbol_value (itp)) && SYMBOLP (etp) \ ? etp : sym . To switch to a different set of, e.g., syntax-table text properties it would suffice to bind the lisp variable i-t-p to, say, the gensym syntax-table-13. Of course low level caches, e.g. in syntax.c, would have to be kept synchronised, too. So, what use would it be? What I have proposed to Dmitry is having a distinct set of syntax-table properties for each major mode chunk of an MMM Mode ("multiple major mode") buffer. Say syntax-table-13 would be the set for a CC Mode chunk. Outside of that chunk, every character would be given a space syntax-table-13 text property. This is the critical thing. Thus all actions dependent upon syntax (and there are a LOT), could be performed by CC Mode in the chunk without the other chunks getting in the way. It may not even be necessary to narrow to the chunk. The necessary juggling with the various syntax-table-13s would be done by MMM Mode. This might well allow arbitrary major modes to be used in MMM Mode with minimal, if any, modification. Thoughts? -- Alan Mackenzie (Nuremberg, Germany).