GNU bug report logs -
#33414
27.0.50; inhibit-changing-match-data can be t in syntax-propertize functions, breaking backtrace and looking-at
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Sat, 17 Nov 2018 13:31:02 UTC
Severity: normal
Found in version 27.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Yes, using a public dynamic variable (i.e., public global mutable
> state) to influence the behavior of a function is normally a bad idea.
Define "normally". Yes, it presents problems.
Lots of things in a language like Lisp present
problems.
> Effectively, the dynamic variable becomes a hidden parameter to the
> function, and robust code has to bind it explicitly do override any
> surprising binding up the call stack.
Correct.
> You normally don't see such a coding style in
> other programming languages,
You don't see _lots_ of Lisp things in most other
programming languages.
> and ELisp would be better off without it, too.
Even Common Lisp is better off _having_ it. For
Elisp that's 1000 times truer.
Users of Emacs as an interactive application,
an editor (and more) _use Lisp_, including to
customize out-of-the-box behavior.
Elisp's designer - and Emacs's designer - pointed
out the reasons why dynamic binding is important
for Emacs Lisp, _in particular_.
https://www.gnu.org/software/emacs/emacs-paper.html#SEC17
https://www.gnu.org/software/emacs/emacs-paper.html#SEC18
Those reasons are as important today as they
were when that was written. Elisp invites and
encourages user tweaking - with Lisp - the OOTB
code. Monkey patching is part of that, in spite
of its negative connotation, and in spite of the
(quite real) drawbacks.
Lisp (even for batch uses) has a ton of things
that offer both possibilities and drawbacks.
Lisp isn't Haskell. (Even Scheme isn't Haskell.)
This bug report was last modified 3 years and 287 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.