[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: |
Ihor Radchenko |
Subject: |
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? |
Date: |
Sun, 10 Sep 2023 08:36:15 +0000 |
Richard Stallman <rms@gnu.org> writes:
> > Because there are cases when `fboundp' should be checked at runtime.
> > For example, some parts of Org use `fboundp' to check if certain
> > third-party optional dependencies are loaded. If `fboundp' is resolved
> > at compile time, such checks will be broken.
>
> I am confident there is a convenient way to distinguish the cases
> where you want run-time tests from those where you would like
> compile-time tests. But I can't try to look for it until I see
> what the former cases look like. Can you show me an example?
Org mode uses `fboundp' check to fontify arbitrary source blocks:
#+begin_src language
...
#+end_src
The corresponding code does the following:
(defun org-src-font-lock-fontify-block (lang start end)
"Fontify code block between START and END using LANG's syntax.
This function is called by Emacs' automatic fontification, as long
as `org-src-fontify-natively' is non-nil."
...
(let ((lang-mode (org-src-get-lang-mode lang)))
(when (fboundp lang-mode)
<fontify using LANG-MODE's native fontification>
This cannot be optimized on compile time because we cannot know in
advance which languages are to be fontified by user.
Another example is Org mode optional inlinetask library "org-inlinetask".
When the library is loaded, certain constructs are parsed differently in
Org files:
(defun org-back-to-heading (&optional invisible-ok)
"Go back to beginning of heading or inlinetask."
(forward-line 0)
(or (and (org-at-heading-p (not invisible-ok))
(not (and (featurep 'org-inlinetask)
(fboundp 'org-inlinetask-end-p) ; <----
(org-inlinetask-end-p))))
This must also be a runtime check, because it is up to the users whether
this optional library is to be used or not.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, (continued)
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Richard Stallman, 2023/09/05
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Richard Stallman, 2023/09/05
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Andreas Schwab, 2023/09/06
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Alan Mackenzie, 2023/09/06
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Alan Mackenzie, 2023/09/06
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Richard Stallman, 2023/09/08
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Ihor Radchenko, 2023/09/09
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Richard Stallman, 2023/09/09
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?,
Ihor Radchenko <=
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Richard Stallman, 2023/09/13
- Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Ihor Radchenko, 2023/09/20
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, Ulrich Mueller, 2023/09/05