bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#68931: 30.0.50; Gnus byte-compilation error with (display . [not exp


From: Eric Abrahamsen
Subject: bug#68931: 30.0.50; Gnus byte-compilation error with (display . [not expire]) with git emacs
Date: Mon, 05 Feb 2024 07:42:41 -0800
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mattias Engdegård <mattias.engdegard@gmail.com>
>> Date: Mon, 5 Feb 2024 15:00:36 +0100
>> Cc: Dan Christensen <jdc@uwo.ca>,
>>  68931@debbugs.gnu.org,
>>  Stefan Monnier <monnier@iro.umontreal.ca>
>> 
>> >> Debugger entered--returning value: "Malformed function ‘#[0
>> >> \"\\301\\300!\\207\" [expire gnus-article-marked-p] 2]’"
>> ...
>> >> * gnus-summary-display-make-predicate((not expire))
>> 
>> Apparently, gnus-category-make-function-1 creates code that isn't
>> really valid Lisp but that we have previously allowed anyway: (F
>> ...) where F is a (non-symbol) function value, instead of using
>> `funcall`.
>> 
>> We could (and probably should) allow this for compatibility but
>> perhaps it's time to at least start warning about it? It makes the
>> quirky semantics of a Lisp-2 even quirkier.
>
> I think the offending function should be fixed not to produce invalid
> code, rather than support such code.

For my information: the problem here is that
`gnus-category-make-function' runs `gnus-byte-compile' on a form like
this:

(lambda nil (not (#f(compiled-function () #<bytecode 0x1980ad44c232>))))

And the extra parens around (#f(compiled-function...)) are not strictly legal?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]