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 22:12:53 +0300 Message-ID: <83pncv3rgq.fsf@gnu.org> References: <837dz35j30.fsf@gnu.org> <297439B1-85C8-429D-9387-935429EA3F47@icloud.com> 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="27434"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, Emacs-devel@gnu.org, dgutov@yandex.ru To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 29 21:16:52 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 1jIdQR-00072Q-J7 for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 21:16:51 +0200 Original-Received: from localhost ([::1]:40720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdQQ-0004iJ-K4 for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 15:16:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34523) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdMd-00034C-H0 for Emacs-devel@gnu.org; Sun, 29 Mar 2020 15:12:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jIdMd-0002FY-47; Sun, 29 Mar 2020 15:12:55 -0400 Original-Received: from [176.228.60.248] (port=2720 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jIdMa-0006rv-0T; Sun, 29 Mar 2020 15:12:53 -0400 In-Reply-To: <297439B1-85C8-429D-9387-935429EA3F47@icloud.com> (message from =?utf-8?B?7KGw7ISx67mI?= on Mon, 30 Mar 2020 04:04:08 +0900) 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:245969 Archived-At: > From: 조성빈 > Date: Mon, 30 Mar 2020 04:04:08 +0900 > Cc: Dmitry Gutov , cpitclaudel@gmail.com, > Emacs-devel@gnu.org > > > 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? > > According to them, font-lock doesn’t provide enough control. This is the exact text quoted from the linked issue: > > >> so, we don't need to reinvent the wheel but neither rely on font-lock in a way that limit us, as I see it, we can implement our own syntax highlight functions for each grammar available and let font-lock use them instead of the defaults. Unless, of course, I'm missing something. > > > > That only covers how to highlight a region. I think the main complexity is in the change-handling mechanisms, i.e. which regions should be re-highlighted, when. But that's exactly the problem that jit-lock solves, and solves well. Because only the display engine knows exactly what parts need to be re-highlighted and when. IOW, this problem is already solved, all that's needed is to play by jit-lock's rules. > > 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? > > Actually I’m surprised that people here on the mailing list expects people to ask here — I think most people aren’t even aware of this list, and even if they do, they prefer working on Github + MELPA, with the community. I'm quite sure that everyone knows where the Emacs maintainers can be contacted. > I’m pretty sure they aren’t aiming to merge the code into Emacs — they’re in to write another external package, like lsp-mode or magit. As I wrote in another message, I don't believe doing so is viable for a core feature such as font-lock or major-mode support in general. Magit is different, since it's an application, not a core feature designed to be basis for applications. And if LSP mode wants a long life and many applications built upon it, it should come to Emacs core as well, at least IMNSHO.