Define autoloads how that is normally done

- Avoid defining autoload definitions in a central location.
  Instead add autoload cookies to the forms/definitions that should
  be autoloaded, in the locations where the actual definitions are
  located.

  - Do this for `geiser-mode', `turn-on-geiser-mode',
    `geiser-mode--maybe-activate' (including adding that to
    `scheme-mode-hook'), `geiser', `geiser-connect',
    `geiser-connect-local' and `geiser-repl-switch'.

  - Also do this for `run-geiser', even though it is only an obsolete
    function alias for `geiser', which might make it desirable to drop
    the autoload altogether.

  Some unusual autoload definitions remain in "geiser.el", see below.

- One issue with defining autoloads in a central location is that it
  is easy to forget to remove such autoloads when the real definition
  is removed.

  No longer autoload `geiser-version' because since [1: 847d2ad]
  there no longer exists a proper definition of that function.

- No longer autoload `geiser-unload', `geiser-reload' and
  `turn-off-geiser-mode', because they are only useful if Geiser has
  already been loaded, at which point any autoloaded definitions are
  no longer relevant.

However,

- Keep autoloading `geiser-activate-implementation' and
  `geiser-implementation-extension', even though I doubt that this
  is actually useful.

- Keep using `custom-add-load' to specify dependencies of Custom
  groups and keep autoloading that.  I don't know if this is actually
  necessary, and while it seems really weird, it might served a legit
  purpose, that I am not aware of.

1: 2020-07-19 847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2
   scheme and autotools removals

0 files changed, 0 insertions, 0 deletions