[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emac
From: |
Alan Mackenzie |
Subject: |
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? |
Date: |
Mon, 28 Aug 2023 21:46:46 +0000 |
Hello, Ulrich.
On Mon, Aug 28, 2023 at 23:01:53 +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 28 Aug 2023, Alan Mackenzie wrote:
> >> > (when (< emacs-major-version 24)
> >> > (defadvice .....))
> >> I believe (eval-when-compile (< emacs-major-version 24)) would work?
> > I've twisted my head into knots in the past trying to work out how to
> > use eval-when/and-compile for this purpose. The point is, I don't want
> > the defadvice to be evaluated at compile time; I just want it to be
> > compiled (or not).
> Sorry, I should have been clearer. The full construct would look like
> this:
> (when (eval-when-compile (< emacs-major-version 24))
> (defadvice .....))
Ah! So the eval-when-compile gets compiled to a constant nil or t, and
the byte compiler optimises the test of this out, either compiling or
not compiling the (defadvice .....). Thanks! I hadn't been aware of
that little detail.
> So only the test would be evaluated at compile time, the defadvice
> itself would be compiled normally (or not, if the test fails).
However, when evaluating the containing defun/defmacro rather than byte
compiling it, the irritating warning message will appear with the e-w-c
strategem, but not with hash-if. ;-)
--
Alan Mackenzie (Nuremberg, Germany).
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Emanuel Berg, 2023/08/28
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Philip Kaludercic, 2023/08/29