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: [PATCH] add compiled regexp primitive lisp object Date: Wed, 07 Aug 2024 18:23:24 +0300 Message-ID: <861q30nyqb.fsf@gnu.org> References: <87mslxxddk.fsf@protonmail.com> <5He97LtsyeyQoTLU7d91oP2CLO8s_2afdgcNxozsFjzu8qGbB_7nXmsZL5O6Ej7K-tuEmngCcPKJpDAjxeKz4jk1DvqSUbdOLpw5U1vo1SY=@hypnicjerk.ai> <87le1avopk.fsf@protonmail.com> <2LOLmIp1X8w4CGbqq3qDrzmKVA0KzYNL1N9lBtWdB-MtEv9oCuYgJMYprG170wMPjYxeQImAmWOPatGTTl4KxZMlptNo9A9hnHt84vdN9EA=@hypnicjerk.ai> <87ttfxtszi.fsf@protonmail.com> <86r0b1o5sr.fsf@gnu.org> <868qx8o83w.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17171"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, emacs-devel@gnu.org, mattiase@acm.org, acorallo@gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Danny McClanahan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 07 17:23:59 2024 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 1sbiW6-0004I5-L3 for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Aug 2024 17:23:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbiVg-0007q1-9n; Wed, 07 Aug 2024 11:23:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbiVe-0007p2-7A for emacs-devel@gnu.org; Wed, 07 Aug 2024 11:23:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbiVc-0003Rm-Er; Wed, 07 Aug 2024 11:23:29 -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=KsxadxYcXF6fg9L4GJGl50PHaC5fmsTY1D+4ZrCYiGI=; b=hb4gTCGcSE1Q 22N1aHh7aDVwnnEiJN1E7bxrGK5rhX6riDn21UdY0X1u208rxbe1n0fM2P2peXBLKcUPrT67HoSdn GTazjVF1RIjQK7rCOogvFP01WhcuKNZ/ZtdY5BC3Ze+grdITbDU0xucyfWNKKjaSI3uicTH3K4FaK hM5v66GilPTWjiEyOZgu1+a1wMg+EjkLSN6Bey/ItQgW7Wa22aQAlnqLQGI8mdA/H/Mr71OGKAck4 lJqtgMhEGX4DUERQ0e82ewqQ4R853OHkZzzGJlsPTo6LctA76j4RGj1uAphe+usoH5Fu2VI3gQ2ix 6akc/1lhsjE79g9MRsUY4g==; In-Reply-To: (message from Danny McClanahan on Wed, 07 Aug 2024 15:02:00 +0000) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322507 Archived-At: > Date: Wed, 07 Aug 2024 15:02:00 +0000 > From: Danny McClanahan > Cc: pipcet@protonmail.com, emacs-devel@gnu.org, mattiase@acm.org, acorallo@gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com > > > On Wednesday, August 7th, 2024 at 08:00, Eli Zaretskii wrote: > > > So these are two (or maybe even one) advantages, mainly in the > > convenience area. My counter-argument would be that the long history > > of using the current regexps in Emacs means that these advantages are > > relatively minor. I'm not sure they justify adding new objects into > > Emacs Lisp, with all its baggage. But maybe others will disagree with > > me. > > No, I think you are absolutely right here. Thanks for taking the time to say > this out loud. > > I will now take what I have learned from this investigation, and instead look > into optimizing the specific case of font-lock patterns. Andrea has provided > a wonderful benchmark harness for this, and font-lock is a highly constrained > use case that should be addressable without introducing a big new complex API. Thanks, but I'd recommend waiting with final conclusions until we hear from Stefan Kangas and Stefan Monnier, because they might have a different perspective and additional suggestions.