From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Sun, 29 Mar 2020 17:30:59 +0300 Message-ID: <837dz35j30.fsf@gnu.org> References: <86tv2h2vww.fsf@gmail.com> <20200322123818.GB32470@ACM> <87eetk5swm.fsf@gnu.org> <20200326193128.GC14092@ACM> <86d08y4zsx.fsf@gmail.com> <83sghs7qdz.fsf@gnu.org> <7ee94ed4-7a11-90bd-df69-c0eeacaf191c@gmail.com> <835zeo7c92.fsf@gnu.org> <05de335b-383e-b32d-2e7e-e79192d364de@yandex.ru> <03981ead-3aca-c238-a9d0-88407ffae451@yandex.ru> <83wo745tw6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="29625"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 29 16:31:54 2020 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 1jIYyg-0007dN-De for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 16:31:54 +0200 Original-Received: from localhost ([::1]:38198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIYyf-0007bZ-EH for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 10:31:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35407) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIYxm-0007AN-P7 for emacs-devel@gnu.org; Sun, 29 Mar 2020 10:30:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jIYxm-00065E-2L; Sun, 29 Mar 2020 10:30:58 -0400 Original-Received: from [176.228.60.248] (port=4943 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jIYxg-0007uL-Cw; Sun, 29 Mar 2020 10:30:54 -0400 In-Reply-To: (message from Dmitry Gutov on Sat, 28 Mar 2020 18:43:13 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245940 Archived-At: > Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 28 Mar 2020 18:43:13 +0200 > > >>> Apparently so:https://github.com/karlotness/tree-sitter.el > >> Sorry, this one is more active: > >> https://github.com/ubolonton/emacs-tree-sitter > > Do any of those support font-lock? Because I think that's the context > > of Clément's question about modules. > > Apparently they aim to replace it with a new specialized jit-highlighter: > > https://github.com/ubolonton/emacs-tree-sitter/issues/4 > https://github.com/ubolonton/emacs-tree-sitter/pull/16 > > But that's not due to modules' limitations, but because of font-lock's > limitations (allegedly). I'm not sure what limitations they have in mind: font-lock supports functions, not just regular expressions. Why does it have to be replaced? In any case, tossing JIT font-lock and going back to using all kinds of hooks is a non-starter. Emacs 19 and 20 did that, and we found this method to have fundamental problems which couldn't be resolved in satisfactory ways. That is why Emacs 21 introduced jit-lock.el and the associated support in the display engine for fontifying what is about to be displayed. Going back to hooks (if that is what they intend to do; I couldn't be sure from reading the discussion) is a step in the wrong direction. Likewise using overlays instead of text properties (again, not sure they actually intend doing that, maybe they just talked about it) is wrong even if we assume the tree-based implementation that sits on a branch. More generally, I'm surprised, to say the least, that such a significant job is being done without saying even a single word here, let alone making sure the basic design is deemed reasonable by the core developers. Do they really think this will make the acceptance of the code easier?