emacs-devel
[Top][All Lists]
Advanced

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

Re: Suppressing native compilation (short and long term)


From: Lars Ingebrigtsen
Subject: Re: Suppressing native compilation (short and long term)
Date: Wed, 05 Oct 2022 18:12:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Andrea Corallo <akrl@sdf.org> writes:

> The naming went first to `inhibit-native-compilation', this was really
> just sooo wrong in so many levels :/ So many as many knobs we have to
> control and disable different parts of the native compiler.  I can't
> really think of one understanding all this machinery and then picking up
> this name sorry, I can't.

Naming is the most difficult thing in computing, after all.

The doc string to the variable explained what it does just fine, so I
think your understanding needs a check-up.  (And I don't appreciated
being talked to in this tone, in case you wondered.)

>>   1) It allows testing without writing to $HOME.  (This has nothing to
>>   do with --batch -- testing happens in interactive Emacsen, too.)
>
> The user request is for non interactive sessions AFAIU.  And still I've
> to understand exactly what the user wants to solve.  Most importantly I
> feel I'm not alone here.

And I'm telling you that's not all that was requested for...  the third
time?  I'm not sure I'm getting any further here by repeating myself, so
I think I'll stop.

>>   2) It allows people to run an AOT Emacs without triggering further
>>   compilation.
>
> Sorry as changeset I meant 5fec9182db + f97993ee66.  I'm not against
> e245c4f226.
>
>> If you have a suggestion for an alternative change that achieves these
>> two things, I'm all ears.  (But if your objection is "people shouldn't
>> want those two things", I'm down to just two ears again.)
>
> Again 5fec9182db + f97993ee66 are IMO not useful / wrong, they were not
> discussed and are just a step backward.  The best change I can suggest
> is to revert them now.

You're just repeating that you're against it without proposing an
alternative, which is not helpful, so I think we've come to the of the
discussion on this point, too.




reply via email to

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