Recent changes to dired.el and info.el

Recent changes to dired.el and info.el

[Luc Teirlinck]

Can you tell how to reproduce the bugs these changes are supposed to fix:

2005-08-14  Thien-Thi Nguyen  <ttn@gnu.org>

	    * dired.el: Fix dependency bug: Wrap `desktop-buffer-mode-handlers'
	    modification in `eval-after-load' form.
	    * info.el: Likewise.

In general, use of eval-after-load should be avoided.

Sincerely,

Luc.

Recent changes to dired.el and info.el

[Luc Teirlinck]

One more remark on the following change:

2005-08-14  Thien-Thi Nguyen  <ttn@gnu.org>

            * dired.el: Fix dependency bug: Wrap `desktop-buffer-mode-handlers'
            modification in `eval-after-load' form.
            * info.el: Likewise.

I am suspicious about this because somebody else reported bugs
concerning `desktop-buffer-mode-handlers', info and dired that
definitely were only due to failure to update loaddefs.el.

Assuming the bugs your changes are supposed to fix are real and not
just a local problem (I can not understand why there should be a
dependency bug given the fact that `desktop-buffer-mode-handlers'
is autoloaded), there would very likely be similar problems in
hilit-chg.el, mh-e/mh-e.el and mail/rmail.el.  But let us first make
sure that the bugs you experience are not just a local problem and
that using `eval-after-load' is really necessary.

Sincerely,

Luc.

Re: Recent changes to dired.el and info.el

[Thien-Thi Nguyen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Can you tell how to reproduce the bugs these changes are supposed to fix:

dired.el, info.el, (and i just noticed) mail/rmail.el fail to load
because the variable `desktop-buffer-mode-handlers' is not defined.
the scenario occurs when one doesn't load desktop.el ever.

> In general, use of eval-after-load should be avoided.

what is a better way to avoid the error thrown by `add-to-list' (in
this specific case), then?

thi

Re: Recent changes to dired.el and info.el

[Thien-Thi Nguyen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I am suspicious about this because somebody else reported bugs
> concerning `desktop-buffer-mode-handlers', info and dired that
> definitely were only due to failure to update loaddefs.el.
> 
> Assuming the bugs your changes are supposed to fix are real and not
> just a local problem (I can not understand why there should be a
> dependency bug given the fact that `desktop-buffer-mode-handlers'
> is autoloaded), there would very likely be similar problems in
> hilit-chg.el, mh-e/mh-e.el and mail/rmail.el.  But let us first make
> sure that the bugs you experience are not just a local problem and
> that using `eval-after-load' is really necessary.

the desired behavior is ability to load/use info, dired, rmail, without
having to load desktop.el.  if i don't use desktop.el, i don't want it
loaded (or autoloaded), *ever*.  if neighborly callback bits are deemed
necessary to be placed in these other files, that's fine, as long as
loading desktop.el is not a requirement for or a by-product of their
use.  (basically, the autoload mechanism answers a timing question, with
the dependency implicitly agreed-upon, but here we have a dependency
that is not agreed-upon -- that is the bug.)

as for how to fix the bug, one way is `eval-after-load'.  another is to
do more drastic re-org (like removing the `add-to-list' calls entirely).
what other options exist for expressing such "subjunctive dependency"?

thi

Re: Recent changes to dired.el and info.el

[Luc Teirlinck]

Thien-Thi Nguyen wrote:

   dired.el, info.el, (and i just noticed) mail/rmail.el fail to load
   because the variable `desktop-buffer-mode-handlers' is not defined.
   the scenario occurs when one doesn't load desktop.el ever.

`desktop-buffer-mode-handlers' is defined, even if desktop is never loaded.
That is what autoload cookies are for.  It is defined by loaddefs.el:

(defvar desktop-buffer-mode-handlers nil "\
  ...

If your loaddefs.el does not contain this line, it is out of date.

   > In general, use of eval-after-load should be avoided.

   what is a better way to avoid the error thrown by `add-to-list' (in
   this specific case), then?

`make bootstrap' (maybe with `make maintainer-clean' first, but I do not
believe that is necessary) or else:

$ cd lisp
$ make autoloads EMACS=../src/emacs

I do not get these errors, because my loaddefs.el is up to date.

   the desired behavior is ability to load/use info, dired, rmail, without
   having to load desktop.el.  if i don't use desktop.el, i don't want it
   loaded (or autoloaded), *ever*.

`desktop-buffer-mode-handlers' is a variable.  Autoloading a variable
does not load its file.  The definition in loaddefs.el suffices:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> desktop-buffer-mode-handlers
nil
ELISP> (featurep 'desktop)
nil

I believe that you should revert your changes.

Sincerely,

Luc.

Re: Recent changes to dired.el and info.el

[Luc Teirlinck]

   the desired behavior is ability to load/use info, dired, rmail, without
   having to load desktop.el.

After doing `C-x d', `C-h i' and `M-x rm' without any problems and
_without having your recent changes installed_, I get:

ELISP> desktop-buffer-mode-handlers
((Info-mode . Info-restore-desktop-buffer)
 (rmail-mode . rmail-restore-desktop-buffer)
 (dired-mode . dired-restore-desktop-buffer))

ELISP> (featurep 'desktop)
nil

Sincerely,

Luc.

Re: Recent changes to dired.el and info.el

[Thien-Thi Nguyen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I do not get these errors, because my loaddefs.el is up to date.
> 
>    the desired behavior is ability to load/use info, dired, rmail, without
>    having to load desktop.el.  if i don't use desktop.el, i don't want it
>    loaded (or autoloaded), *ever*.
> 
> `desktop-buffer-mode-handlers' is a variable.  Autoloading a variable
> does not load its file.  The definition in loaddefs.el suffices:
> 
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> desktop-buffer-mode-handlers
> nil
> ELISP> (featurep 'desktop)
> nil
> 
> I believe that you should revert your changes.

ok, thanks for the explanation.  i will update the local loaddefs.el.
(i see the changes have already been reverted.)

thi