From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lower-level change hook immune to with-silent-modifications Date: Fri, 17 Jun 2022 14:03:19 +0300 Message-ID: <837d5fpn60.fsf@gnu.org> References: <2c2746e5f2558a87e8eab6f0914264a020173a9d.camel@pm.me> <27630AA3-8026-4E24-8852-ACCD9325B99D@gmail.com> <0E9E702B-B07C-4794-8498-29B9320E14CC@gmail.com> <871qvorqvv.fsf@localhost> <5D6F74DB-79C2-4D7E-B830-B529C3A5CD16@gmail.com> <83sfo3q2nw.fsf@gnu.org> <87v8sz7g7t.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2070"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, casouri@gmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 17 13:08:31 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o29q0-0000GA-Tw for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 13:08:29 +0200 Original-Received: from localhost ([::1]:33572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o29pz-0007Li-Mn for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jun 2022 07:08:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o29ld-000497-Dl for emacs-devel@gnu.org; Fri, 17 Jun 2022 07:04:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45504) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o29lK-0002YS-07; Fri, 17 Jun 2022 07:03:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RZZbBmsUEU4JZBS1eQIlu3Zs40BCRGGWEKLBm7DKTZM=; b=fRK9C3MBKHyZ EK1+8AWC5tGOTXV/L+c+5bTJzqRBVp6dg1UnstFGKBL+hKNhG5Nu8RS5oD7NMOHRKup5t5rEw6NT0 3LkSOuxTkhBw5JrynEGUFL5ZoIcdLaVe7/K6abLSuT4dmMjLyJd/4VpYbM7QOj54E09jSkYJVLoqB tqdISc8lIXBYVKR5mfC0c8K9AR12o/Cs9ykwciS98XEovDqbMXgMvWH3AbpoOKM8iX47drU1sTlTt 6d8/B3C1kFMF/bETwaxh0Lq6pYvl+JqZA0bhMs/9zkYVhuhJjTDcoHQPoyXGS0lEYpcELB1trT/AW BFPrRpJrDzwhDstYtCwaVw==; Original-Received: from [87.69.77.57] (port=4930 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o29l6-0008GO-Eg; Fri, 17 Jun 2022 07:03:32 -0400 In-Reply-To: <87v8sz7g7t.fsf@localhost> (message from Ihor Radchenko on Fri, 17 Jun 2022 18:10:46 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291290 Archived-At: > From: Ihor Radchenko > Cc: Stefan Monnier , casouri@gmail.com, > emacs-devel@gnu.org > Date: Fri, 17 Jun 2022 18:10:46 +0800 > > Eli Zaretskii writes: > > >> As I just argued in bug#51766, I don't think it makes sense to try to > >> have such "a lower-level after-change-functions that is immune to > >> with-silent-modifications". > > > > I tend to agree. We can discuss the specific needs that triggered > > that request, but by and large, we have a good reason to have > > inhibit-modification-hooks that affects any Lisp program that wants to > > know about buffer modifications. That's the difference between the > > Lisp level and the lower-level code in C, which "knows everything", > > including when it isn't safe to use some data or some objects. > > Now I am wondering why tree-sitter should be any different. > Apparently the existing after-change-functions functionality was not > sufficient for tree-sitter. Probably because of issues similar to > bug#51766. Can more fine-grained modification info be exposed to Elisp? tree-sitter isn't different: it does that in C, as part of the low-level Emacs code which manipulates changes in buffer text. My response above was about exposing that to Lisp, not about letting features access buffer text in general. after-change-functions is not the right tool for accessing buffer text, they are a means to signal to Lisp that _some_ change happened in buffer text which Lisp program _may_ wish to know about, and the core reserves the right not to tell Lisp about some of the changes via that hook. Programs that _must_ know about each and every change in buffer text cannot be written in Lisp, because there are changes that I don't even know how to tell to a Lisp program in terms it will understand. For example, what if the buffer was changed from multibyte to unibyte, or vice versa? Or how to describe efficiently a change in text properties? Asking to have every aspect of the Emacs internals be exposed to Lisp is NOT the right way of implementing features in Emacs! Instead, whenever the existing facilities are insufficient or don't allow you to do the job, please describe the job you need to do, and let's discuss how best to divide the implementation between the C primitives (whether existing or new) and the Lisp application code. Most of Emacs is written in Lisp to allow flexibility and safety, not because we don't like C. So the line that divides the C from the Lisp parts of the implementation should consider which parts need to be easily modified and which don't, and also which internals, if exposed to Lisp, could easily lead to runaway applications wedging or crashing Emacs. These are non-trivial aspects, and the decision is not always self-evident (though sometimes it is).