;;;###autoload declarations

;;;###autoload declarations

[uzibalqa]

Have been looking at the ;;;###autoload declaration.  Reading through the manual,
the cookie just before the real definition of a function, indicates that a specific
function exists.  Without such declaration, the function call would generate an error
because the required function has not been properly included in the code before 
attempting to call the function.  This is done so that emacs would not consume system
resources and slow down.

Yet, one still needs a call to "require" which loads the file and all its deffun's and
defvar's even without any use of the ;;;###autoload declaration.

It then seems to me that although autoloading is intended as described, technically 
it is untrue, because everything seems to be evaluated all in one go.

What is going on ?

Re: ;;;###autoload declarations

[Michael Heerdegen]

uzibalqa <uzibalqa@proton.me> writes:

> It then seems to me that although autoloading is intended as
> described, technically
> it is untrue, because everything seems to be evaluated all in one go.
>
> What is going on ?

You need to generate a loaddefs file.

Michael.

Re: ;;;###autoload declarations

[uzibalqa]

------- Original Message -------
On Saturday, June 24th, 2023 at 4:08 AM, Michael Heerdegen <michael_heerdegen@web.de> wrote:


> uzibalqa uzibalqa@proton.me writes:
> 
> > It then seems to me that although autoloading is intended as
> > described, technically
> > it is untrue, because everything seems to be evaluated all in one go.
> > 
> > What is going on ?
> 
> 
> You need to generate a loaddefs file.
> 
> Michael.

What is the procedure of using a loaddefs.el ?  The loaddefs.el is supposed to get executed
while building Emacs.  What does "building emacs" mean ?  Does it mean running an emacs instance ?

Re: ;;;###autoload declarations

[Michael Heerdegen]

uzibalqa <uzibalqa@proton.me> writes:

> What is the procedure of using a loaddefs.el?

It's a file containing the autoload references.  It's normally build
automatically - when building Emacs, installing packages, etc.  And
normally loaded automatically at startup.

So it's a quite low-level mechanism not really useful for the end user.
Unless maybe, you generate a loaddefs file for a bunch of third-party
libraries that you want to use and you did not install them with package
manager or the OS.  Then it may make sense to build a loaddefs file
yourself.

Michael.

Re: ;;;###autoload declarations

[uzibalqa]

------- Original Message -------
On Saturday, June 24th, 2023 at 2:02 PM, Michael Heerdegen <michael_heerdegen@web.de> wrote:


> uzibalqa uzibalqa@proton.me writes:
> 
> > What is the procedure of using a loaddefs.el?
> 
> 
> It's a file containing the autoload references. It's normally build
> automatically - when building Emacs, installing packages, etc. And
> normally loaded automatically at startup.
> 
> So it's a quite low-level mechanism not really useful for the end user.
> Unless maybe, you generate a loaddefs file for a bunch of third-party
> libraries that you want to use and you did not install them with package
> manager or the OS. Then it may make sense to build a loaddefs file
> yourself.
> 
> Michael.

Would you see benefits in using a loaddefs file for those writing their own
minor modes and customisation files ?  Autoloading could be useful if things
could be made easier to set up.

Re: ;;;###autoload declarations

[Michael Heerdegen]

uzibalqa <uzibalqa@proton.me> writes:

> Would you see benefits in using a loaddefs file for those writing their own
> minor modes and customisation files ?  Autoloading could be useful if things
> could be made easier to set up.

Not really, unless you have tons of such stuff and want to avoid to load
all of it.  Even then, explicit `require' calls or manually added
`autoload' calls may be better/simpler.

Keep in mind that the only thing you get is that you avoid that some
files are loaded into memory in sessions that don't need them.  If you
are the only user of this stuff this is not such a big win.  And the
disadvantage is that you have to remember to rebuild the loaddefs-file
after changing any of the affected files.

If you want to experiment in that direction, a better idea is probably
to build you own packages and install them with the package manager
using a local source (I never tried that myself, though).  Still, I
doubt it's worth the time until your goal is to share that stuff sooner
or later or learn something new.

Michael.

Re: ;;;###autoload declarations

[Emanuel Berg]

Michael Heerdegen wrote:

>> It then seems to me that although autoloading is intended
>> as described, technically it is untrue, because everything
>> seems to be evaluated all in one go.
>>
>> What is going on ?
>
> You need to generate a loaddefs file.
  
If we change "all in one go" into "sequentially" or "in the
order specified by the Lisp syntax" then - that's the natural
order of things.

So ;;;###autoload is obviously an exception ... but anyway, it
works like this, as described in the documentation -

  The autoload facility lets you register the existence of
  a function or macro, but put off loading the file that
  defines it. The first call to the function automatically
  loads the proper library, in order to install the real
  definition and other associated code, then runs the real
  definition as if it had been loaded all along.
  <https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html>

(info "(elisp) Autoload")

However, what I can see it fails to address why this is at all
desirable to do and, assuming it is, in what cases more
precisely it is useful.

Which I think is a candidate for the second if not
first paragraph! If you agree.

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

RE: [External] : Re: ;;;###autoload declarations

[Drew Adams]

> (info "(elisp) Autoload")
> 
> However, what I can see it fails to address why this is at all
> desirable to do and, assuming it is, in what cases more
> precisely it is useful.

If you never use anything from some library
then it isn't loaded.  That's the idea: load
code only if and when you need it.

Autoloaded commands (typically) and other
things (not so typically) are available to
the Help system, so you can see what they
do etc., even though their definitions
haven't been loaded.

If/when you invoke an autoloaded command,
_then_ the file defining it is loaded
(which often defines other commands etc.).
___

Another example of late binding - one of the
most important software ideas and practices.

Lazy evaluation (think purely functional
languages) is a prime example of late binding.
___

Beyond normal-order (i.e., outermost-first)
evaluation, which is used for lazy languages,
there's a more stringent on-need evaluation,
which is defined for some rewrite systems.
It needs costly analysis of code to determine
exactly what really needs to be evaluated when.

Re: [External] : Re: ;;;###autoload declarations

[Emanuel Berg]

Drew Adams wrote:

>> However, what I can see it fails to address why this is at
>> all desirable to do and, assuming it is, in what cases more
>> precisely it is useful.
>
> If you never use anything from some library then it isn't
> loaded. That's the idea: load code only if and when you need
> it [..]

So it isn't loaded automatically, it is loaded when needed?

Is that the same as just-in-time or lazy evaluation?

Maybe just different context/points of emphasis ...

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

RE: [External] : Re: ;;;###autoload declarations

[Drew Adams]

> > If you never use anything from some library then it isn't
> > loaded. That's the idea: load code only if and when you need
> > it [..]
> 
> So it isn't loaded automatically, it is loaded when needed?

It's loaded when you first invoke the command.

> Is that the same as just-in-time or lazy evaluation?

Lazy evaluation usually refers to expression evaluation, particularly in the context of functional, logic, or constraint programming languages.

> Maybe just different context/points of emphasis ...

Yes, you can say that.  Another, usually more general, term is "late binding": Don't fix/set/define something before you need to.  Keep your options open...