smerge fix

smerge fix

[Dave Love]

This fixes font-lock variables appearing to be loaded from smerge-mode
according to loadhist.  It's confusing anyhow, but disastrous if you
unload smerge-mode.

*** smerge-mode.el.~1.14.4.1.~	Fri Nov 30 18:57:07 2001
--- smerge-mode.el	Sun Aug 18 23:26:31 2002
***************
*** 181,188 ****
  - `diff3-A'")
  
  ;; Compiler pacifiers
! (defvar font-lock-mode)
! (defvar font-lock-keywords)
  (eval-when-compile
    (unless (fboundp 'font-lock-fontify-region)
      (autoload 'font-lock-fontify-region "font-lock")))
--- 181,189 ----
  - `diff3-A'")
  
  ;; Compiler pacifiers
! (eval-when-compile
!   (defvar font-lock-mode)
!   (defvar font-lock-keywords))
  (eval-when-compile
    (unless (fboundp 'font-lock-fontify-region)
      (autoload 'font-lock-fontify-region "font-lock")))

Re: smerge fix

[Richard Stallman]

Using defvar inside eval-when-compile is rather a nuisance.
Whatever we recommend for preventing warnings about unknown
variables, it should be more convenient than that.

What we actually recommend for the purpose is a plain defvar.

Whatever we recommend for preventing warnings about unknown variables,
it should not cause anything to happen when the file is unloaded.

So either we should change unloading of packages to ignore
defvars that didn't specify a value,
or we should recommend something other than defvar
as the way to say it's ok to reference a certain variable
without defining it.

The easiest thing to do is to say that simple (defvar foo)
does not count as a definition.  Deleting the following code
in Fdefvar seems to be enough:

  else
    /* A (defvar <var>) should not take precedence in the load-history over
       an earlier (defvar <var> <val>), so only add to history if the default
       value is still unbound.  */
    if (NILP (tem))
      LOADHIST_ATTACH (sym);

There was another bug report saying that unloading a file
would do makunbound on the function names defined in the file.
That is not right either.  I decided to fix them both.

Re: smerge fix

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Using defvar inside eval-when-compile is rather a nuisance.
> Whatever we recommend for preventing warnings about unknown
> variables, it should be more convenient than that.

[I don't see why it's more inconvenient than using it around `require',
and code that has to be portable to older versions and XEmacs will
need to carry on doing that.]

> What we actually recommend for the purpose is a plain defvar.

The example in (elisp)Tips uses eval-when-compile, and the text was
meant to caution explicitly to use it.

> The easiest thing to do is to say that simple (defvar foo)
> does not count as a definition.

When this came up before, you said that should not be done.  I think
you said that construct was intentionally used to declare variables
per se.

Re: smerge fix

[Richard Stallman]

    > The easiest thing to do is to say that simple (defvar foo)
    > does not count as a definition.

    When this came up before, you said that should not be done.  I think
    you said that construct was intentionally used to declare variables
    per se.

Yes, occasionally it is, but no great harm will result from this
change.  It only means that those definitions won't be recognized by
certain Emacs features.  You can correct it by changing the definition
to provide a value.

There is no harm in providing an initial value, and a real definition
really ought to provide a doc string.

Re: smerge fix

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> There is no harm in providing an initial value, and a real definition
> really ought to provide a doc string.

That's what I'd have thought.  I was just recalling the previous
discussion, which went differently and led to me writing some doc.