unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Basic question about autoload function
@ 2017-12-06 18:55 Kaushal Modi
  2017-12-06 19:04 ` Drew Adams
  0 siblings, 1 reply; 5+ messages in thread
From: Kaushal Modi @ 2017-12-06 18:55 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list

Hello,

I have recently realized that

  (autoload #'foo-fn "bar-pkg")

works even if foo-fn is *not* defined inside bar-pkg. The documentation
also doesn't say that it has to be that way.

So I was just pleasantly surprised that that did the right thing. I looked
at src/eval.c to confirm if that was the case (that it didn't matter if
foo-fn was or wasn't inside bar-pkg).. but I don't understand what's going
on in there (don't understand C).

Can someone confirm?
-- 

Kaushal Modi


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Basic question about autoload function
  2017-12-06 18:55 Basic question about autoload function Kaushal Modi
@ 2017-12-06 19:04 ` Drew Adams
  2017-12-06 19:14   ` Kaushal Modi
  0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2017-12-06 19:04 UTC (permalink / raw)
  To: Kaushal Modi, Help Gnu Emacs mailing list

> I have recently realized that (autoload #'foo-fn "bar-pkg")
> works even if foo-fn is *not* defined inside bar-pkg.

What do you mean by "works"?

All that does is cause file bar-pkg.el[c] to be loaded
whenever someone or something tries to invoke/use function,
macro, or keymap `foo-fn'.  (But it does nothing if `foo-fn'
is a function already defined.)

Yes, nothing implies that `foo-fn' is defined in bar-pkg.el.

> The documentation also doesn't say that it has to be that way.

What doesn't have to be what way?

> So I was just pleasantly surprised that that did the right thing.

The right thing being ___?  I guess you wanted Emacs to
load that file when that function is invoked?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Basic question about autoload function
  2017-12-06 19:04 ` Drew Adams
@ 2017-12-06 19:14   ` Kaushal Modi
  2017-12-08 13:39     ` Michael Heerdegen
  0 siblings, 1 reply; 5+ messages in thread
From: Kaushal Modi @ 2017-12-06 19:14 UTC (permalink / raw)
  To: Drew Adams; +Cc: Help Gnu Emacs mailing list

On Wed, Dec 6, 2017 at 2:04 PM Drew Adams <drew.adams@oracle.com> wrote:

> > I have recently realized that (autoload #'foo-fn "bar-pkg")
> > works even if foo-fn is *not* defined inside bar-pkg.
>
> What do you mean by "works"?
>

By "works", I meant that bar-pkg got loaded when I called foo-fn. Sorry, I
myself hate the "works" and "does not work" phrases and I ended up using
those.

All that does is cause file bar-pkg.el[c] to be loaded
> whenever someone or something tries to invoke/use function,
> macro, or keymap `foo-fn'.  (But it does nothing if `foo-fn'
> is a function already defined.)
>
> Yes, nothing implies that `foo-fn' is defined in bar-pkg.el.
>

Thanks.

> The documentation also doesn't say that it has to be that way.
>
> What doesn't have to be what way?
>

I meant to say that the documentation does not imply that the FUNCTION has
to be defined inside FILE. I was wondering if that was intentional i.e.
FUNCTION can or cannot be defined inside FILE.

> So I was just pleasantly surprised that that did the right thing.
>
> The right thing being ___?  I guess you wanted Emacs to
> load that file when that function is invoked?
>

Yes, bar-pkg got loaded even when I called foo-fn (where foo-fn was defined
outside bar-pkg).. no errors, nothing.. it just worked as I thought.
-- 

Kaushal Modi


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Basic question about autoload function
  2017-12-06 19:14   ` Kaushal Modi
@ 2017-12-08 13:39     ` Michael Heerdegen
  2017-12-08 18:59       ` Kaushal Modi
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Heerdegen @ 2017-12-08 13:39 UTC (permalink / raw)
  To: Kaushal Modi; +Cc: Help Gnu Emacs mailing list

Kaushal Modi <kaushal.modi@gmail.com> writes:

> I meant to say that the documentation does not imply that the FUNCTION
> has to be defined inside FILE. I was wondering if that was intentional
> i.e.  FUNCTION can or cannot be defined inside FILE.

Looking at the DEFUN of `autoload-do-load' in eval.c, it is only checked
whether after loading the FILE, the `indirect-function' of the symbol
FUNCTION has changed.  So AFAICT yes, it doesn't matter where the
function is defined, as long as it has been defined after loading the
FILE.  Which is also what I would expect, since "the file which defined
some function" is not necessarily well-defined.


Michael.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Basic question about autoload function
  2017-12-08 13:39     ` Michael Heerdegen
@ 2017-12-08 18:59       ` Kaushal Modi
  0 siblings, 0 replies; 5+ messages in thread
From: Kaushal Modi @ 2017-12-08 18:59 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Help Gnu Emacs mailing list

On Fri, Dec 8, 2017 at 8:39 AM Michael Heerdegen <michael_heerdegen@web.de>
wrote:

> Looking at the DEFUN of `autoload-do-load' in eval.c, it is only checked
> whether after loading the FILE, the `indirect-function' of the symbol
> FUNCTION has changed.  So AFAICT yes, it doesn't matter where the
> function is defined, as long as it has been defined after loading the
> FILE.  Which is also what I would expect, since "the file which defined
> some function" is not necessarily well-defined.
>

Thank you.
-- 

Kaushal Modi


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-12-08 18:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-06 18:55 Basic question about autoload function Kaushal Modi
2017-12-06 19:04 ` Drew Adams
2017-12-06 19:14   ` Kaushal Modi
2017-12-08 13:39     ` Michael Heerdegen
2017-12-08 18:59       ` Kaushal Modi

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).