GNU bug report logs - #58950
[PATCH] * lisp/subr.el (buffer-match-p): Optimise performance

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Mattias Engdegård <mattiase <at> acm.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 58950 <at> debbugs.gnu.org
Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
Date: Thu, 5 Jan 2023 14:55:06 +0200

On 05/01/2023 12:31, Mattias Engdegård wrote:
> 5 jan. 2023 kl. 05.31 skrev Stefan Monnier<monnier <at> iro.umontreal.ca>:
> 
>> I don't much like the kind of mini-language we invented for
>> `buffer-match-p`.  I'd prefer we just used plain old ELisp for that.
> Yes, I sort of wondered whether we were going full Greenspun here. We haven't added many embedded languages into our embedded language lately.
> 
> The usual DSL worthiness criteria:
> 
> - more expressive than plain code for the domain
> - potential for significantly better performance
> - better error-checking, statically or dynamically
> - structured editing
> 
> etc, don't really seem to be met here but I'm not deeply familiar with the problem and perhaps the author could make a better case for it.

Note that we already had ah-hoc and informally-specified pieces of such 
DSL before, in font-lock-global-modes and display-buffer-alist. The new 
use in show-paren-predicate seems fitting too.

I'm not sure how we'd reach the same goals with plain old Elisp 
(structured editing in particular -- in Customize).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.