unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: [External] : Re: Native compilation
Date: Tue, 11 Jan 2022 14:18:55 +0100	[thread overview]
Message-ID: <87czkys94w.fsf@zoho.eu> (raw)
In-Reply-To: 831r1fa37q.fsf@gnu.org

Eli Zaretskii wrote:

>>>>>> Here is what it said during the native compile:
>>>>>> 
>>>>>> Warning (comp): Cannot look-up eln file as no source file
>>>>>> was found for /home/incal/.emacs.elc
>>>>> 
>>>>> The former means your .emacs was not natively compiled
>>>>> (which is generally a Good Thing).
>>>> 
>>>> Thanks, you mean not to compile it natively or not compile
>>>> it at all?
>>>
>>> Natively.
>> 
>> Okay, it is interesting that you say so because didn't you
>> use (?) to say that byte-compiling of the .emacs and
>> supplemental files was disencouraged?
>
> I did, but how is that relevant to the issue at hand?

Because I would like to know if this new (?) attitude to a new
thing - is that actually a new attitude, or is it an old
attitude ("don't byte-compile your own Elisp") applied to
a new thing? (native byte-compilation)

Or, if it indeed is a new attitude, what is the basis of
that attitude? 

>> Why is it that while it makes sense to natively
>> byte-compile the Elisp of GNU Emacs it doesn't make sense
>> to natively byte-compile all other Elisp?
>
> Because the gains will be null and void.

OK, so that's the basis, but then I again ask, why are there
gains doing this to the GNU Emacs (vanilla Emacs) Elisp, but
not to the local (HOME) Elisp?

>> But OK, just byte-compiling the old what, that doesn't make
>> it natively byte-compiled, right?
>
> No.

Right, it doesn't look like it, either. So how do you natively
byte-compile the file x.el?

>> That happens automatically when Emacs is run, after being
>> configured --with-native-compilation [1], and it only
>> affects GNU Emacs Elisp, right?
>
> What is "that" in this case?

Native byte-compilation of GNU Emacs (vanilla Emacs) Elisp.

>> Or what about [M]ELPA Elisp, that natively byte-compiled
>> as well?
>
> What do you mean by "MELPA Elisp"?

The Elisp you get from ELPA and MELPA and possibly other
places with the package manager.

>> If so, even more so, then why not all Elisp?
>
> Why not what?

_If_ there is an advantage, and I agree it is, both in theory
and in practice, to natively byte-compile the GNU Emacs
(vanilla Emacs) Elisp, then how can it be that "the gains will
be null and void" to do the same with the local (HOME) Elisp?

And, as asked, the [M]ELPA Elisp?

Why/how can it makes sense to do this on some Elisp but not all?

-- 
underground experts united
https://dataswamp.org/~incal




  reply	other threads:[~2022-01-11 13:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-24  0:44 [External] : Re: Native compilation Drew Adams
2021-12-24  2:53 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-24  4:06   ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-29 13:52 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31  8:59 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31  9:04   ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31 12:18   ` Eli Zaretskii
2021-12-31 12:31     ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31 12:46       ` Eli Zaretskii
2021-12-31 13:00         ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31 13:08           ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31 13:37           ` Eli Zaretskii
2021-12-31 13:02         ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-12-31 13:38           ` Eli Zaretskii
2022-01-09  5:26             ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-09  7:13               ` Eli Zaretskii
2022-01-10 13:23                 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-10 17:51                   ` Eli Zaretskii
2022-01-11 13:18                     ` Emanuel Berg via Users list for the GNU Emacs text editor [this message]
2022-01-11 17:04                       ` Eli Zaretskii
2022-01-12 22:38                         ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-12 22:49                           ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-13  7:07                             ` Eli Zaretskii
2022-01-13  7:31                               ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-13  7:34                               ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-13  7:05                           ` Eli Zaretskii
2022-01-13  7:28                             ` Emanuel Berg via Users list for the GNU Emacs text editor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czkys94w.fsf@zoho.eu \
    --to=help-gnu-emacs@gnu.org \
    --cc=moasenwood@zoho.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).