From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Mon, 30 Mar 2020 04:04:08 +0900 Message-ID: <297439B1-85C8-429D-9387-935429EA3F47@icloud.com> References: <837dz35j30.fsf@gnu.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="112011"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , cpitclaudel@gmail.com, Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 29 21:05:12 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 1jIdFA-000T1w-Nh for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 21:05:12 +0200 Original-Received: from localhost ([::1]:40536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdF9-0006Ce-Nh for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 15:05:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32980) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdEG-0005Qf-9M for emacs-devel@gnu.org; Sun, 29 Mar 2020 15:04:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIdEE-0007xR-Rt for emacs-devel@gnu.org; Sun, 29 Mar 2020 15:04:16 -0400 Original-Received: from pv50p00im-ztdg10021101.me.com ([17.58.6.44]:55641) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jIdEE-0007uU-KQ for emacs-devel@gnu.org; Sun, 29 Mar 2020 15:04:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1585508652; bh=J/RuLmBPoQ7vbt9VriIQ2U0k1lHbfO+xLbw6OgBynAw=; h=Content-Type:From:Subject:Date:Message-Id:To; b=lW8EBiUXuCEfucn54bGhniiIunIeICNi7WERFnsCRGVAfXH5xFvl6eMsDakodjKeS fNqmu/QniCmCTcI86PeC2SdXxdhI4O+J7xFUooAUDixu/nSuxbLIU5njomRljkI0Dz AMxcctLDLktw6xM5SS7uOsDeV6QHv5SP9Tqj5MBdIuSIGN90w0ktJJZtsdHTG4V4YY OKqvrdjqU1I/GOU9AD5OYwXW8qal0O1UA+u16AK78zG3oWLnw296Egj6hWOHHtpOaq InIjsHwU3YTW+uxJAEN7RPt2keK2ZMFasmUb6SsweBQ+7z2By+SMWVbEM+e54vymNC XUS0YPyIUVWJg== Original-Received: from [192.168.0.3] (unknown [1.230.108.64]) by pv50p00im-ztdg10021101.me.com (Postfix) with ESMTPSA id DA9D2180484; Sun, 29 Mar 2020 19:04:11 +0000 (UTC) In-Reply-To: <837dz35j30.fsf@gnu.org> X-Mailer: iPhone Mail (17E255) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-29_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003290179 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.44 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:245963 Archived-At: > 2020. 3. 29. =EC=98=A4=ED=9B=84 11:32, Eli Zaretskii =EC=9E= =91=EC=84=B1: >=20 > =EF=BB=BF >>=20 >> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org >> From: Dmitry Gutov >> Date: Sat, 28 Mar 2020 18:43:13 +0200 >>=20 >>>>> 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=C3=A9ment's question about modules. >>=20 >> Apparently they aim to replace it with a new specialized jit-highlighter:= >>=20 >> https://github.com/ubolonton/emacs-tree-sitter/issues/4 >> https://github.com/ubolonton/emacs-tree-sitter/pull/16 >>=20 >> But that's not due to modules' limitations, but because of font-lock's=20= >> limitations (allegedly). >=20 > 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=E2=80=99t 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 f= unctions for each grammar available and let font-lock use them instead of th= e defaults. Unless, of course, I'm missing something. >=20 > 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-highligh= ted, when. I don=E2=80=99t know about font-lock enough to say whether this is true or n= ot.=20 > 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. >=20 > 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. >=20 > 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=E2=80=99m surprised that people here on the mailing list expects p= eople to ask here =E2=80=94 I think most people aren=E2=80=99t even aware of= this list, and even if they do, they prefer working on Github + MELPA, with= the community.=20 I=E2=80=99m pretty sure they aren=E2=80=99t aiming to merge the code into Em= acs =E2=80=94 they=E2=80=99re in to write another external package, like lsp= -mode or magit.=