Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Rob Browning <rlb@defaultvalue.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  Eli Zaretskii <eliz@gnu.org>,
>   david@tethera.net,  emacs-devel@gnu.org
> Date: Wed, 05 Oct 2022 15:16:31 +0200
> 
> Andrea Corallo <akrl@sdf.org> writes:
> 
> > IIUC this would just control `load-no-native' and
> > `native-comp-deferred-compilation'?  I think these two are doing what
> > you suggest here no?
> 
> The latter yes -- nobody has discussed doing anything with
> `load-no-native' (which is another variable that's difficult to discover
> due to how it's named, and isn't documented anywhere, either).

Variables that are "hard to discover" are intentionally named like
that: we didn't intend them to be discoverable, because we didn't
think they should be used except internally.

During the last stages of native-comp development, we went through the
variables in comp.c and comp.el with Andrea, and renamed those we
thought would be useful so that they are easily discoverable.  Please
don't assume that the names you see are due to omission or negligence
or ineptitude.  Maybe additional ones should be renamed/aliased to be
more discoverable, but before we do that, we need to understand the
problems we are solving.  That requires careful consideration and
discussion, whereas rushing with installing changes in the area where
you don't have enough prior knowledge and history ends up wreaking
havoc, to say nothing of personal aggravation.