Pedro Andres Aranda Gutierrez <[email protected]> writes:
> Enviado desde mi iPhone
>
>> El 26 jul 2026, a las 20:45, Ihor Radchenko <[email protected]> escribió:
>>
>> Morgan Smith <[email protected]> writes:
>>
>>> I often diff the elc files before and after making a change to see the
>>> effect. I do this with rx forms to make sure they still compile to
>>> constants. I forget my findings but I believe this helped me decide how
>>> to include other regex variables in a regex using the rx constructs
>>> literal, regexp, and eval.
>>
>> byte-compiler warnings are IMHO sufficient in such cases.
>
> Eval buffer and byte-compile are enough for me.
I think you misunderstand my intention.
There are two reasons I do this:
1. Sometimes I want to do a quick and dirty sanity check that I haven't
change the byte-code at all. Say I'm rewriting a regex using rx or
adding sharp quotes to lambdas.
2. To figure out what happens at compile time and what happens at
runtime.
In the org-mode code base we do clearly care about compile-time vs
runtime as can be seen by this odd and round about way of defining this
regex:
#+begin_src elisp
(defconst org-element-planning-line-re
(rx-to-string
`(seq line-start (0+ (any ?\s ?\t))
(group (regexp ,org-element-planning-keywords-re))))
"Regexp matching a planning line.")
#+end_src
I just quickly redid my lost rx experiments and rediscovered my runtime
vs compile-time results:
#+begin_src elisp
(disassemble
(lambda () (rx (regexp org-element-headline-re))))
;; => varref org-element-headline-re
(disassemble
(lambda () (rx (eval org-element-headline-re))))
;; => constant "\\^\\\\\\*\\+ "
#+end_src
Now compile time vs run time constructs are clearly described in the
docstring of `rx'. However, that is not always the case so it's nice to
be able to test it.
>>> It'd be pretty easy to do that to double check the sharp quote function
>>> stuff if you wanted. I'm not going to bother checking though.
>>
>> I do not think we really need such fine-granular checks.
>> The only real reason to look into byte-compiled vs not byte-compiled is
>> performance bottlenecks. Doing it everywhere is simply wasting time that
>> could otherwise be spend to improve other, more critical, areas in the code.
>
> +1
>
+1
If one is looking at byte-code to try and discover micro-optimizations,
they better be doing it to improve the byte-compiler itself. Doing
org-mode specific adjustments would indeed be a waste of time that could
be better spent.
