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: Indirect text properties Date: Mon, 18 Nov 2019 00:55:50 +0200 Message-ID: References: <20191117170527.GB11551@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="18502"; 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: Vitalie Spinu To: Alan Mackenzie , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 17 23:56:39 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 1iWTTC-0004hF-AJ for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 23:56:38 +0100 Original-Received: from localhost ([::1]:56840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWTTB-0002QS-4C for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 17:56:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47314) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWTSV-0002QM-Cx for emacs-devel@gnu.org; Sun, 17 Nov 2019 17:55:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWTSU-0005ln-2F for emacs-devel@gnu.org; Sun, 17 Nov 2019 17:55:55 -0500 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:34457) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWTST-0005lT-SM for emacs-devel@gnu.org; Sun, 17 Nov 2019 17:55:54 -0500 Original-Received: by mail-wr1-x42e.google.com with SMTP id e6so17303116wrw.1 for ; Sun, 17 Nov 2019 14:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1E551W+cAo3SJHXz1UXS/7PDI46c5ljXrJItQ4RyjkI=; b=UzhbGk6ztQjUr5MP8U8KbLpLe60YppsV4Dz8F7R8gzBunwC87A5S+Y+hdGaxOOPK3/ Yetv1P3JjTqFmgdouHZWQNbrulDdgc2EP96oZKCs0wOkVlEyAoq2AmGIA9wOSiKKyHGw iF576te9AmG3p1FAdyLngkcEiWO2YlcPg1YjrhYGsy8UYC+L4qenudXT1tkrlwtqbA7f QjwqQ8auEpw7QyGWF0V7XFt/S/bek+wBj7LcQ/P6FiC/SSqQD42RueJh7B3y6n+4oGIM Yi7zo3Ehtzyjz9LIyf4IscIrqqAZZtIPODlMcas3kRV7daD/rE4uVrk/VkxuK7wUaEkz MCqA== 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:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1E551W+cAo3SJHXz1UXS/7PDI46c5ljXrJItQ4RyjkI=; b=mYp7JKs0Nytua+h7KS1eVTDjjK4OFe73omLggtIRXBXkpyMfVq4uDo1Oauhi7BcWpH cGg8ffESp/K7LvL4m4a0GBHhCGo9L8THdI9ESW6Tc1F/HwUQp59JMvIOU/AiEzT/li6M oNKPJ01wmFE8FQGBGUEK6Us05GyCkWwY5iwOWjNTLEU08yhbkm3fbt2yglvl8ZfjjSSf muoRrktkO8msMWRuvjEcSDytVR77aDz/t+mG+1AS9dgIeNLUi0238cWzWhmr8Wknigob +OUqyDo0jB9GVGXUhaHgowFZoyKVvCZanENPIl3W7Nz6J5DSEJsYa4MGuXHD1/2EOHtA awog== X-Gm-Message-State: APjAAAWrIzNKA8P60ujdD3+g4jrIHPWfutrilUVnvoa6FcbctKhkcCMW c4XaPg0tRg5mh2bVZDMxm5k= X-Google-Smtp-Source: APXvYqwvyyjkN/t/UICtC0i7+2+Ucpi238OOpLWnZbPhM/2EGLRQVJqOVy3Hra6TfAjifzom5AqQaQ== X-Received: by 2002:adf:f650:: with SMTP id x16mr29149904wrp.223.1574031352583; Sun, 17 Nov 2019 14:55:52 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id 13sm14024398wmk.1.2019.11.17.14.55.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 14:55:51 -0800 (PST) In-Reply-To: <20191117170527.GB11551@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::42e 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:242336 Archived-At: Hi Alan, On 17.11.2019 19:05, Alan Mackenzie wrote: > 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. Could char-property-alias-alist help? > 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. It's a lot of work with likely some performance overhead even for the default case as well. It sounds like it could be a piece of the puzzle, but let's see if we get the full picture first. Also, I think most (all?) of this proposal could be implemented in Lisp by just setting the 'syntax-table' on the overlays that cover different submode regions. With more overhead when setting but less overhead than accessing the values. > 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. It doesn't seem like it covers all problematic cases. Maybe not even the majority: - Would this win over "local" syntax-table properties as assigned by syntax-table? By the usual logic of how we implement property priorities, probably not. But it should, for this to work. - Some code can just be looking for certain characters instead of syntax classes with re-search-backward, etc. It wouldn't be fooled either. So this would likely require some "are we still in the same major mode" predicate. At which point we might get by without the space-syntax-table swapping entirely. So what are the exact scenarios that your aim is to fix with this? /Cc Vitalie, he could have some ideas, maybe even tell us how Polymode maybe solves this problem already.