politza
`tablist-edit-filter` error on Emacs 27.0.90
Using tablist on Emacs 27.0.90 on a Macintosh, I'm finding if I try to edit a filter in a tablist (/ e) an error occurs:
replace-regexp-in-string: Wrong type argument: arrayp, nil
and I've traced the source of that error to tablist-filter-parser-init which calls, effectively
(wisent-compile-grammar tablist-filter-wisent-grammar)
If you open Emacs 27.0.90 and evaluate the following in *scratch* you should be able to reproduce the error:
(require 'semantic/wisent/comp)
(require 'semantic/wisent/wisent)
(defvar tablist-filter-wisent-grammar
'(
;; terminals
;; Use lowercase for better looking error messages.
(operand unary-operator binary-operator or and not)
;; terminal associativity & precedence
((left binary-operator)
(left unary-operator)
(left or)
(left and)
(left not))
;; rules
(filter-or-empty
((nil))
((?\( ?\)) nil)
((filter) $1))
(filter
((operand) $1) ;;Named filter
((operand binary-operator operand) `(,(intern $2) ,$1 ,$3))
((unary-operator operand) `(,(intern $1) ,$2))
((not filter) `(not ,$2))
((filter and filter) `(and ,$1 ,$3))
((filter or filter) `(or ,$1 ,$3))
((?\( filter ?\)) $2))))
(wisent-compile-grammar tablist-filter-wisent-grammar)
@Silex - fyi, I reproduced this using docker on 27.0.90 pretest and earlier 27.0.50 builds.
Appears to be bug upstream.
In https://github.com/emacs-mirror/emacs/commit/390b4bc1e25fe691548d7ec982eb2f7027fe26a3 the developer has updated wisent-total-conflicts with a new feature to allow "expected" conflicts. The expected conflicts are to be supplied by the caller as a symbol. The symbol is supposed to be based on a filename presumably where the grammar is defined:
(let* ((src (wisent-source))
(symbol (intern (format "wisent-%s--expected-conflicts"
(replace-regexp-in-string "\\.el$" "" src))
obarray)))
The code then checks if this symbol is bound and extracts a value. The bug is that tablist is compiling a grammar on the fly such that (wisent-source) yields nil, and the replace-regexp-in-string is handed a nil string.
I think this is enough of an explanation for the upstream developers to fix. I'll go report on emacs-devel and see what they say.
By the way the Emacs maintainers have a presumed fix for this on the 27 branch. I haven’t tested yet.
https://github.com/emacs-mirror/emacs/commit/3a671ad7ede0d1459ae60d7340632d8d210b4308
For the past week or so I have been running my own build of the “emacs-27” branch of the GNU Emacs sources, and this bug looks resolved in that branch.
Not sure when the upstream maintainers will build another pretest release.
They usually prepare rc candidates at some point. The docker image will pick the patch up then.
Maybe I should switch back to the emacs27 branch in the meantime?
That’s a judgment call. So far every local build I’ve generated from that branch has been stable, but I’ve also got option to roll things back if the build is broken. People using your docker images can’t do that as easily.
Right. Let's keep it at the tags for now, given it's supposedly more stable than the branch itself. Anyhow it's only a matter of weeks and then 27 will be out.