Removing unloaded functions from auto-mode-alist.

Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

unload-feature removes functions it is unloading from hooks.  What
about removing these functions from auto-mode-alist as well?

Lute.


Index: lisp/loadhist.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/loadhist.el,v
retrieving revision 1.32
diff -c -r1.32 loadhist.el
*** lisp/loadhist.el	19 Apr 2005 15:08:05 -0000	1.32
--- lisp/loadhist.el	19 Apr 2005 15:15:19 -0000
***************
*** 189,195 ****
  			(memq x unload-feature-special-hooks)))	; Known abnormal hooks etc.
  	   (dolist (y unload-hook-features-list)
  	     (when (eq (car-safe y) 'defun)
! 	       (remove-hook x (cdr y))))))))
      (when (fboundp 'elp-restore-function) ; remove ELP stuff first
        (dolist (elt unload-hook-features-list)
  	(when (symbolp elt)
--- 189,200 ----
  			(memq x unload-feature-special-hooks)))	; Known abnormal hooks etc.
  	   (dolist (y unload-hook-features-list)
  	     (when (eq (car-safe y) 'defun)
! 	       (remove-hook x (cdr y)))))))
!       ;; Remove any feature-symbols from auto-mode-alist as well.
!       (dolist (elt unload-hook-features-list)
! 	(when (eq (car-safe elt) 'defun)
! 	  (setq auto-mode-alist 
! 		(rassq-delete-all (cdr elt) auto-mode-alist)))))
      (when (fboundp 'elp-restore-function) ; remove ELP stuff first
        (dolist (elt unload-hook-features-list)
  	(when (symbolp elt)

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> unload-feature removes functions it is unloading from hooks.  What
> about removing these functions from auto-mode-alist as well?
>
> Index: lisp/loadhist.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/loadhist.el,v
> retrieving revision 1.32
> diff -c -r1.32 loadhist.el
> *** lisp/loadhist.el	19 Apr 2005 15:08:05 -0000	1.32
> --- lisp/loadhist.el	19 Apr 2005 15:15:19 -0000
> ***************
> *** 189,195 ****
>   			(memq x unload-feature-special-hooks)))	; Known abnormal hooks etc.
>   	   (dolist (y unload-hook-features-list)
>   	     (when (eq (car-safe y) 'defun)
> ! 	       (remove-hook x (cdr y))))))))
>       (when (fboundp 'elp-restore-function) ; remove ELP stuff first
>         (dolist (elt unload-hook-features-list)
>   	(when (symbolp elt)
> --- 189,200 ----
>   			(memq x unload-feature-special-hooks)))	; Known abnormal hooks etc.
>   	   (dolist (y unload-hook-features-list)
>   	     (when (eq (car-safe y) 'defun)
> ! 	       (remove-hook x (cdr y)))))))
> !       ;; Remove any feature-symbols from auto-mode-alist as well.
> !       (dolist (elt unload-hook-features-list)
> ! 	(when (eq (car-safe elt) 'defun)
> ! 	  (setq auto-mode-alist 
> ! 		(rassq-delete-all (cdr elt) auto-mode-alist)))))
>       (when (fboundp 'elp-restore-function) ; remove ELP stuff first
>         (dolist (elt unload-hook-features-list)
>   	(when (symbolp elt)

Actually, _both_ sound like a spectacularly bad idea if the unloaded
function gets replaced by a restored autoload.  I don't know the code
well enough.

Actually, stupid question in that area: does anybody think the
following code more than duely insane?  This is at the start of a file
with generated autoloads:

(provide 'auctex)
;;;###autoload (defmacro TeX-define () (read (current-buffer)) nil)
(defmacro TeX-define ()
  (let ((form (read (current-buffer))) symbol)
    (if (stringp (nth 3 form))
	(setcar (nthcdr 3 form)
		(format (nth 3 form) "AUCTeX 11.3")))
    (if (and (eq (car form) 'autoload)
	     (fboundp (setq symbol (nth 1 (nth 1 form))))
	     (eq (car (symbol-function symbol)) 'autoload))
	`(progn (defalias ',symbol '(autoload ,@(nthcdr 2 form)))
		(put ',symbol 'autoload ',(cdr (symbol-function symbol))))
      form)))


And the autoloads in the original are then something like

;;;###autoload
(TeX-define)
;;;###autoload
(defun tex-mode (arg)
   "This is a function from %s"
   ...)

Here is the rationale: I want people to be able to put AUCTeX into the
TeX tree and have it preloaded.  The TeX-define autoloads are placed
before definitions that are potentially _conflicting_ with
tex-mode.el.  I want to give people the option of having AUCTeX in the
tree, and enabled by default on the site (with require 'auctex), while
people that don't like it can get rid of it of the autoloads for
AUCTeX completely with (unload-feature 'auctex).  The Doc string gets
salted with version info.

Does anybody see any problems with that approach apart from the fact
that it is crazy as anything?

The autoload cookie in the above file is just for the purpose that
somebody actually extracts autoloads from the AUCTeX tree.  In that
case, the cookie (auctex.el is conveniently alphabetically first and
gets extracted as the first package) will disable _all_ autoload
actions for such conflicting functions: they only spring into action
when (require 'auctex) is actually executed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

> Does anybody see any problems with that approach apart from the fact
> that it is crazy as anything?

Well, for one thing, it's crazy as anything.

What about the following:

- make all auctex thingies use the TeX- and LaTeX- prefix (i.e. no conflict
  at all with the other tex-mode), with autoload cookies and stuff.

- make a `auctex-override.el' file which does:

     (defalias 'tex-mode 'TeX-mode)
     (defalias 'latex-mode 'LaTeX-mode)
     ...
     (provide 'auctex-override.el)

Then (require 'auctex-override) makes AUCTeX the default, and hopefully an
(unload-feature 'auctex-override) will restore the default autloads for the
other tex-mode.  Completely untested, of course.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Does anybody see any problems with that approach apart from the fact
>> that it is crazy as anything?
>
> Well, for one thing, it's crazy as anything.
>
> What about the following:
>
> - make all auctex thingies use the TeX- and LaTeX- prefix (i.e. no
> conflict at all with the other tex-mode),

Forget it, Bub.  TeX-mode and LaTeX-mode are already taken as aliases.
Who was the smart guy responsible for that?  The annotations show:

1.3          (jimb     13-May-91): ;;;###autoload
1.17         (eric     23-Apr-93): (defalias 'TeX-mode 'tex-mode)
1.3          (jimb     13-May-91): ;;;###autoload
1.99         (rms      16-Feb-99): (defalias 'plain-TeX-mode 'plain-tex-mode)
1.99         (rms      16-Feb-99): ;;;###autoload
1.17         (eric     23-Apr-93): (defalias 'LaTeX-mode 'latex-mode)
1.1          (root     28-Aug-90): 

Ok, so it was "eric".  At that time AUCTeX started to be sort of a
contender, and AUCTeX used TeX-mode and LaTeX-mode, quite likely with
the intent not to conflict.  And maybe "eric" switched between
computers and was surprised that TeX-mode worked on one system, and
barfed on another.

Anyway, this is not much as an option: as a package prefix, TeX and
LaTeX are fine, but local variable blocks declaring a major mode
should of course have the preference AUCTeX/tex-mode _not_ be decided
by the _document_, but by the writer.  So a document should just state
"Ok, I am plain TeX rather than LaTeX" but not "ok, you have to edit
me with tex-mode.el, or with AUCTeX".  So the major mode put into the
major-mode variable will be lowercased always, and thus the major mode
calling function must work lowercased according to the preference of
the user.

Also auto-mode-alist will demand lowercase modes, and this makes
sense.

Now it turns out that for 90% of the unsuspecting users (that would
never actually stoop to reading a manual), AUCTeX as a default
installation is a much more appreciated choice than tex-mode.el.  So I
want Emacs distributions and system administrators have no qualms of
preinstalling and activating it.

However, people come in different flavors, and one flavor that prefers
writing its documents in plain TeX rather than in LaTeX will also tend
to prefer the small tex-mode solution over AUCTeX: if they wanted
complex and convenient systems, they would not use plain TeX, anyway.
And those people will get insulted if they get confronted with a
default mode against their personal tastes that is hard to rip out of
the system again.  And frankly, the plain TeX mode of AUCTeX is not
really exciting.

So people should be free to get rid of AUCTeX easily.  And if
(unload-feature 'auctex) works, that would be perfect.  Now
unload-feature will not restore stuff that has been overwritten, like
autoloads exchanged for different autoloads or overwritten with a
function or alias that was not what the autoload was intended for.

And that is what my stuff tries to fix: restoring autoloads at
unload-feature that have been overwritten with conflicting info.

Apparently, it works reasonably.  Even better would be (I'll probably
try doing this) if a file, when being loaded, only attached itself to
those possibly conflicting function cells that had the correctly
corresponding autoload.  Then the user could arrange the autoloads for
his favorite combination of AUCTeX and tex-mode, and even though both
might get loaded, they would only occupy the space they were
customized for.

However, for this to play along, tex-mode.el would probably have to be
changed as well.  Or some eval-after-load cleans up after it.

> with autoload cookies and stuff.
>
> - make a `auctex-override.el' file which does:
>
>      (defalias 'tex-mode 'TeX-mode)
>      (defalias 'latex-mode 'LaTeX-mode)
>      ...
>      (provide 'auctex-override.el)
>
> Then (require 'auctex-override) makes AUCTeX the default, and hopefully an
> (unload-feature 'auctex-override) will restore the default autloads for the
> other tex-mode.

Won't work.  Autoloads corresponding to a different file than the
loaded one don't get restored.  I have not found the exact place that
causes this, but only the "right" definitions cause the autoload to be
saved in the autoload property of the corresponding function.

Since I am using the "wrong" definitions in my approach, I have to
manually put the autoload properties on.  Which is what I do with the
above code.

> Completely untested, of course.

Unfortunately, I tested this already.  That's why I had to come up
with a better scheme.  Not "better" as in "nicer", but in "reckless
enough to stand a chance of attaining its goal".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

> Forget it, Bub.  TeX-mode and LaTeX-mode are already taken as aliases.
> Who was the smart guy responsible for that?  The annotations show:

> 1.3          (jimb     13-May-91): ;;;###autoload
> 1.17         (eric     23-Apr-93): (defalias 'TeX-mode 'tex-mode)
> 1.3          (jimb     13-May-91): ;;;###autoload
> 1.99         (rms      16-Feb-99): (defalias 'plain-TeX-mode 'plain-tex-mode)
> 1.99         (rms      16-Feb-99): ;;;###autoload
> 1.17         (eric     23-Apr-93): (defalias 'LaTeX-mode 'latex-mode)
> 1.1          (root     28-Aug-90): 

Duh, this sucks!
Any objection to removing those aliases?
These names belong to AUCTeX and are just wrong in tex-mode.el.
[ In the text below, I'll asume we remove those atrocities ]

>> - make a `auctex-override.el' file which does:
>> 
>> (defalias 'tex-mode 'TeX-mode)
>> (defalias 'latex-mode 'LaTeX-mode)
>> ...
>> (provide 'auctex-override.el)
>> 
>> Then (require 'auctex-override) makes AUCTeX the default, and hopefully an
>> (unload-feature 'auctex-override) will restore the default autloads for the
>> other tex-mode.

> Won't work.  Autoloads corresponding to a different file than the
> loaded one don't get restored.

That's a bug which we should fix.
In the mean time, you can use an auctex-override-unload-hook to re-install
the autoloads.

>> Completely untested, of course.
> Unfortunately, I tested this already.  That's why I had to come up
> with a better scheme.  Not "better" as in "nicer", but in "reckless
> enough to stand a chance of attaining its goal".

I'd rather try and make my suggestion work than to follow down your
insane path.

I.e. we should remove those atrocities in tex-mode.el and we should fix the
unload-feature to properly re-install autoloads.

In the mean time, you should be able make my suggestion work by using the
following autoload-override.el file:

   ;; Override the atrocities in tex-mode.el.
   (fmakunbound 'TeX-mode)
   (autoload 'TeX-mode "...")
   ...

   (defvar TeX-saved-other-tex-autoloads
     (mapcar (lambda (f) (cons f (symbol-function f)))
             '(tex-mode latex-mode ...)))

   (add-hook 'auctex-override-unload-hook
             (lambda ()
               (dolist (x TeX-saved-other-tex-autoloads)
                 (fset (car x) (cdr x)))))

   ;; Give preference to our
   (defalias 'tex-mode 'TeX-mode)
   ...

Then users/admins can (require 'auctex-override) to make AUCTeX be the
default, and if the admin made it the default, users can
(unload-feature 'auctex-override) to make the other tex-mode be the default.

Of course, you can name this file something else than `auctex-override'.

It seems much less insane than your current code.  WDYT?


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Forget it, Bub.  TeX-mode and LaTeX-mode are already taken as
>> aliases.  Who was the smart guy responsible for that?  The
>> annotations show:
>
>> 1.3          (jimb     13-May-91): ;;;###autoload
>> 1.17         (eric     23-Apr-93): (defalias 'TeX-mode 'tex-mode)
>> 1.3          (jimb     13-May-91): ;;;###autoload
>> 1.99         (rms      16-Feb-99): (defalias 'plain-TeX-mode 'plain-tex-mode)
>> 1.99         (rms      16-Feb-99): ;;;###autoload
>> 1.17         (eric     23-Apr-93): (defalias 'LaTeX-mode 'latex-mode)
>> 1.1          (root     28-Aug-90): 
>
> Duh, this sucks!
> Any objection to removing those aliases?

Not here.

> These names belong to AUCTeX and are just wrong in tex-mode.el.

Well, that is my opinion, too.

> [ In the text below, I'll asume we remove those atrocities ]

I guess that they make handling the case where somebody has put
mode: LaTeX
in his local variable section easier.  When the text then gets edited
by somebody without AUCTeX.  AUCTeX itself uses 'latex-mode in
major-mode, and consequently also stores that in the mode variable
when it writes out local variables.

>>> - make a `auctex-override.el' file which does:
>>> 
>>> (defalias 'tex-mode 'TeX-mode)
>>> (defalias 'latex-mode 'LaTeX-mode)
>>> ...
>>> (provide 'auctex-override.el)
>>> 
>>> Then (require 'auctex-override) makes AUCTeX the default, and hopefully an
>>> (unload-feature 'auctex-override) will restore the default autloads for the
>>> other tex-mode.
>
>> Won't work.  Autoloads corresponding to a different file than the
>> loaded one don't get restored.
>
> That's a bug which we should fix.

I am not sure it is a bug.  If I load several packages redefining one
symbol, and then unload _one_ of those packages, is it a good idea if
the symbol gets restored to an autoload?

> In the mean time, you can use an auctex-override-unload-hook to
> re-install the autoloads.

This hook is not available in XEmacs or in Emacs 21.3.  And the normal
auctex-unload-hook is getting run before symbols are fmakunbound, so
can't restore the autoloads permanently.

>>> Completely untested, of course.
>>
>> Unfortunately, I tested this already.  That's why I had to come up
>> with a better scheme.  Not "better" as in "nicer", but in "reckless
>> enough to stand a chance of attaining its goal".
>
> I'd rather try and make my suggestion work than to follow down your
> insane path.
>
> I.e. we should remove those atrocities in tex-mode.el

It won't change that AUCTeX has to redefine tex-mode and latex-mode in
order to be a useful default mode, and that this needs to get reverted
by unload-feature.

> and we should fix the unload-feature to properly re-install
> autoloads.

I am not sure that reinstalling some old autoloads from some previous
time is "proper" here.

> In the mean time, you should be able make my suggestion work by using the
> following autoload-override.el file:
>
>    ;; Override the atrocities in tex-mode.el.
>    (fmakunbound 'TeX-mode)
>    (autoload 'TeX-mode "...")
>    ...
>
>    (defvar TeX-saved-other-tex-autoloads
>      (mapcar (lambda (f) (cons f (symbol-function f)))
>              '(tex-mode latex-mode ...)))
>
>    (add-hook 'auctex-override-unload-hook
>              (lambda ()
>                (dolist (x TeX-saved-other-tex-autoloads)
>                  (fset (car x) (cdr x)))))

Works only in Emacs 22.  We'll talk about that solution in four years
or so.

>    ;; Give preference to our
>    (defalias 'tex-mode 'TeX-mode)
>    ...
>
> Then users/admins can (require 'auctex-override) to make AUCTeX be
> the default, and if the admin made it the default, users can
> (unload-feature 'auctex-override) to make the other tex-mode be the
> default.
>
> Of course, you can name this file something else than
> `auctex-override'.
>
> It seems much less insane than your current code.  WDYT?

I just remembered another reason for my insane approach: it gives me
working function documentation in the generated autoloads.  Manual
autoloads don't give me that, and the string replacements in the DOC
string previously required using TeX-defun instead of just defun, and
that means manual autoloads.

Anyway, I spent about a day fixing this approach.  For example, the
first version had just (read) in it instead of (read
(current-buffer)).

That was fine, until I ran the batch byte compiler for the first
time...

I guess I don't have the nerve just now to go for another approach
that would need extensive testing again.  The current approach works
under HEAD, 21.3 and XEmacs-21.17 or something.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

>>> Won't work.  Autoloads corresponding to a different file than the
>>> loaded one don't get restored.
>> That's a bug which we should fix.
> I am not sure it is a bug.

Maybe not the problem described in the text I quoted, but if I have function
FOO autoloaded and (require 'blabla) replaces that with some other
definition, than an immediately following (unload-feature 'blabla) should
restore the autoload, no matter whether the autoload was pointing to
blabla.el or not.

> If I load several packages redefining one symbol, and then unload _one_ of
> those packages, is it a good idea if the symbol gets restored to
> an autoload?

That's a different scenario.  We'll cross that bridge when we get there.

>> In the mean time, you can use an auctex-override-unload-hook to
>> re-install the autoloads.

> This hook is not available in XEmacs or in Emacs 21.3.  And the normal
> auctex-unload-hook is getting run before symbols are fmakunbound, so
> can't restore the autoloads permanently.

As mentioned in another email, if you define with `fset' instead of
`defalias', the modification is not recorded, so the unload won't do any
`fmakunbound'.

> It won't change that AUCTeX has to redefine tex-mode and latex-mode in
> order to be a useful default mode, and that this needs to get reverted
> by unload-feature.

Of course.

>> and we should fix the unload-feature to properly re-install
>> autoloads.

> I am not sure that reinstalling some old autoloads from some previous
> time is "proper" here.

Can't be much worse than leaving those functions undefined, can it?

>> In the mean time, you should be able make my suggestion work by using the
>> following autoload-override.el file:
>> 
>> ;; Override the atrocities in tex-mode.el.
>> (fmakunbound 'TeX-mode)
>> (autoload 'TeX-mode "...")
>> ...
>> 
>> (defvar TeX-saved-other-tex-autoloads
>> (mapcar (lambda (f) (cons f (symbol-function f)))
>> '(tex-mode latex-mode ...)))
>> 
>> (add-hook 'auctex-override-unload-hook
>> (lambda ()
>> (dolist (x TeX-saved-other-tex-autoloads)
>> (fset (car x) (cdr x)))))

> Works only in Emacs 22.  We'll talk about that solution in four years
> or so.

It should be adaptable to other emacsen.

> I just remembered another reason for my insane approach: it gives me
> working function documentation in the generated autoloads.  Manual
> autoloads don't give me that, and the string replacements in the DOC
> string previously required using TeX-defun instead of just defun, and
> that means manual autoloads.

My suggestion uses plain `defun' and normal auto-generated autoloads.
It concentrates all the icky bits in one file which does nothing else than
the icky bits of dealing with the conflict between AUCTeX and tex-mode on
the few toplevel functions like `tex-mode', `latex-mode', `texinfo-mode',
and `doctex-mode'.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[...]

> if I have function FOO autoloaded and (require 'blabla) replaces
> that with some other definition, than an immediately following
> (unload-feature 'blabla) should restore the autoload, no matter
> whether the autoload was pointing to blabla.el or not.

I have thought about this some more and there's more to it than just
autoloads.

What currently happens when you do (require 'blabla) and then
(unload-feature 'blabla) is that all functions that "blabla" defined
are unbound.  Maybe not the right thing to do, but quite consistent.

(There is only one case where (unload-feature 'blabla) will do
anything else then fmakunbound a function that "blabla" defined and
that is when a function was autoloaded and that function was defined
when do_autoload loaded "blabla".)

Consider the following situation:

function 'a is autoloaded: (autoload "blabla" ...).
function 'b is autoloaded: (autoload "other" ...).
function 'c is defined.
function 'd is unbound.

"blabla" defines 'a, 'b, 'c, and 'd as functions.

Do (require 'blabla) and then (unload-feature 'blabla).

Currently, all four functions will be unbound by unload-feature.  You
propose to let unload-feature restore both 'a and 'b to their previous
autoloads [1].  But what should be done with 'c?

I think restoring 'c to its previous definition would be the right
thing to do.  But that would be quite a substantial change.  It's
probably best to leave this alone until after the release.

Lute.



[1] I have actually implemented this for Frequire; it's quite simple:

Index: src/fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/fns.c,v
retrieving revision 1.389
diff -c -r1.389 fns.c
*** src/fns.c	22 Apr 2005 07:11:08 -0000	1.389
--- src/fns.c	24 Apr 2005 20:06:44 -0000
***************
*** 3482,3487 ****
--- 3482,3488 ----
  
    if (NILP (tem))
      {
+       Lisp_Object first, second;
        int count = SPECPDL_INDEX ();
        int nesting = 0;
  
***************
*** 3528,3533 ****
--- 3529,3551 ----
  	error ("Required feature `%s' was not provided",
  	       SDATA (SYMBOL_NAME (feature)));
  
+       /* Save the old autoloads, in case we ever do an unload.  */
+       tem = Vautoload_queue;
+       while (CONSP (tem))
+ 	{
+ 	  first = XCAR (tem);
+ 	  second = Fcdr (first);
+ 	  first = Fcar (first);
+ 	  
+ 	  /* Note: This test is subtle.  The cdr of an autoload-queue entry
+ 	     may be an atom if the autoload entry was generated by a defalias
+ 	     or fset.  */
+ 	  if (CONSP (second))
+ 	    Fput (first, Qautoload, (XCDR (second)));
+ 
+ 	  tem = XCDR (tem);
+ 	}
+ 
        /* Once loading finishes, don't undo it.  */
        Vautoload_queue = Qt;
        feature = unbind_to (count, feature);

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Consider the following situation:
>
> function 'a is autoloaded: (autoload "blabla" ...).
> function 'b is autoloaded: (autoload "other" ...).
> function 'c is defined.
> function 'd is unbound.
>
> "blabla" defines 'a, 'b, 'c, and 'd as functions.
>
> Do (require 'blabla) and then (unload-feature 'blabla).
>
> Currently, all four functions will be unbound by unload-feature.  You
> propose to let unload-feature restore both 'a and 'b to their previous
> autoloads [1].

Sure.

> But what should be done with 'c?
>
> I think restoring 'c to its previous definition would be the right
> thing to do.

Not at all.  The purpose of unload-feature is to be able to restore a
state, most particular to conserve memory.  So unload-feature should
not waste memory by keeping in effect a history of load sequences
around.  Its purpose should be confined to unloading those features
that _can_ reasonably be unloaded.  And that means no functions
whatsoever that _redefine_ stuff.  The main purpose of the autoload
restoration is to restore autoloads into the package itself, not
foreign autoloads.

I think that unload-feature should in the case of c being redefined
simply barf and refuse to unload the feature.

> But that would be quite a substantial change.  It's probably best to
> leave this alone until after the release.

Lute, _any_ change in that area is best left alone.  Richard has
already clearly stated that we are not going to fiddle with it before
the release, and I can only agree.  The current state of brokenness
has been there for a long time, and nobody really complained.  We
can't hope to get a serious amount of testing for this sort of stuff
in before the release.  And the effects might be memory leakage and
similar hard to find things that take people months to figure out.

We can't invest the time to make sure that nothing like this will
happen.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> Consider the following situation:
>>
>> function 'a is autoloaded: (autoload "blabla" ...).
>> function 'b is autoloaded: (autoload "other" ...).
>> function 'c is defined.
>> function 'd is unbound.
>>
>> "blabla" defines 'a, 'b, 'c, and 'd as functions.
>>
>> Do (require 'blabla) and then (unload-feature 'blabla).
>>
>> Currently, all four functions will be unbound by unload-feature.  You
>> propose to let unload-feature restore both 'a and 'b to their previous
>> autoloads [1].
>
> Sure.
>
>> But what should be done with 'c?
>>
>> I think restoring 'c to its previous definition would be the right
>> thing to do.
>
> Not at all.  The purpose of unload-feature is to be able to restore a
> state, most particular to conserve memory.  So unload-feature should
> not waste memory by keeping in effect a history of load sequences
> around.  Its purpose should be confined to unloading those features
> that _can_ reasonably be unloaded.  And that means no functions
> whatsoever that _redefine_ stuff.  The main purpose of the autoload
> restoration is to restore autoloads into the package itself, not
> foreign autoloads.

For me, it is most intuitive/logical that unload-feature tries to undo
the effects of loading the feature.  It is very uncommon that a
feature redefines a function (or a variable), so keeping track of such
cases will not waste much memory.

> I think that unload-feature should in the case of c being redefined
> simply barf and refuse to unload the feature.

That's quite extreme.  And it would require you too keep track of
redefinitions.  Why not use that tracking machinery to just restore
these rare cases?

>> But that would be quite a substantial change.  It's probably best to
>> leave this alone until after the release.
>
> Lute, _any_ change in that area is best left alone.  Richard has
> already clearly stated that we are not going to fiddle with it before
> the release, and I can only agree.  The current state of brokenness
> has been there for a long time, and nobody really complained.  We
> can't hope to get a serious amount of testing for this sort of stuff
> in before the release.  And the effects might be memory leakage and
> similar hard to find things that take people months to figure out.
>
> We can't invest the time to make sure that nothing like this will
> happen.

Ok.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>>
>>> Consider the following situation:
>>>
>>> function 'a is autoloaded: (autoload "blabla" ...).
>>> function 'b is autoloaded: (autoload "other" ...).
>>> function 'c is defined.
>>> function 'd is unbound.
>>>
>>> "blabla" defines 'a, 'b, 'c, and 'd as functions.
>>>
>>> Do (require 'blabla) and then (unload-feature 'blabla).
>>>
>>> Currently, all four functions will be unbound by unload-feature.
>>> You propose to let unload-feature restore both 'a and 'b to their
>>> previous autoloads [1].
>>
>> Sure.
>>
>>> But what should be done with 'c?
>>>
>>> I think restoring 'c to its previous definition would be the right
>>> thing to do.
>>
>> Not at all.  The purpose of unload-feature is to be able to restore
>> a state, most particular to conserve memory.  So unload-feature
>> should not waste memory by keeping in effect a history of load
>> sequences around.  Its purpose should be confined to unloading
>> those features that _can_ reasonably be unloaded.  And that means
>> no functions whatsoever that _redefine_ stuff.  The main purpose of
>> the autoload restoration is to restore autoloads into the package
>> itself, not foreign autoloads.
>
> For me, it is most intuitive/logical that unload-feature tries to
> undo the effects of loading the feature.

If it can.

> It is very uncommon that a feature redefines a function (or a
> variable), so keeping track of such cases will not waste much
> memory.

But it is very common that one loads and evals one and the same file
over and over.  We don't want to keep a history of that.

>> I think that unload-feature should in the case of c being redefined
>> simply barf and refuse to unload the feature.
>
> That's quite extreme.  And it would require you too keep track of
> redefinitions.

Of the fact that they happened.  That is about one cons cell worth of
data.  Old definitions, in contrast, can take any amount of data.

> Why not use that tracking machinery to just restore these rare
> cases?

They don't seem exactly rare to me.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>>>
>>>> Consider the following situation:
>>>>
>>>> function 'a is autoloaded: (autoload "blabla" ...).
>>>> function 'b is autoloaded: (autoload "other" ...).
>>>> function 'c is defined.
>>>> function 'd is unbound.
>>>>
>>>> "blabla" defines 'a, 'b, 'c, and 'd as functions.
>>>>
>>>> Do (require 'blabla) and then (unload-feature 'blabla).
>>>>
>>>> Currently, all four functions will be unbound by unload-feature.
>>>> You propose to let unload-feature restore both 'a and 'b to their
>>>> previous autoloads [1].
>>>
>>> Sure.
>>>
>>>> But what should be done with 'c?
>>>>
>>>> I think restoring 'c to its previous definition would be the right
>>>> thing to do.
>>>
>>> Not at all.  The purpose of unload-feature is to be able to restore
>>> a state, most particular to conserve memory.  So unload-feature
>>> should not waste memory by keeping in effect a history of load
>>> sequences around.  Its purpose should be confined to unloading
>>> those features that _can_ reasonably be unloaded.  And that means
>>> no functions whatsoever that _redefine_ stuff.  The main purpose of
>>> the autoload restoration is to restore autoloads into the package
>>> itself, not foreign autoloads.
>>
>> For me, it is most intuitive/logical that unload-feature tries to
>> undo the effects of loading the feature.
>
> If it can.
>
>> It is very uncommon that a feature redefines a function (or a
>> variable), so keeping track of such cases will not waste much
>> memory.
>
> But it is very common that one loads and evals one and the same file
> over and over.  We don't want to keep a history of that.

I had not considered that.  Does loading the same file more than once
really happen often?  On purpose?  For what reason?

If files do get reloaded often (for good reasons), then recording old
values of functions and variables should probably be done only if
require loads a file.  That wouldn't happen twice.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> David Kastrup <dak@gnu.org> writes:

> If files do get reloaded often (for good reasons), then recording
> old values of functions and variables should probably be done only
> if require loads a file.  That wouldn't happen twice.

Well, I still think that when we are concerned about a working
unload-feature, the decisive criterion is that we want to be able to
restore the state before a load that actually first provided a
feature, and it does not really matter whether this load was initiated
by load, by an autoload, or by require.

All that matters is that a recognizable load added the feature, and so
we want to have unload-feature restore the state before that
particular load where feasible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    > But it is very common that one loads and evals one and the same file
    > over and over.  We don't want to keep a history of that.

    I had not considered that.  Does loading the same file more than once
    really happen often?  On purpose?  For what reason?

To load a file multiple times is fairly common when one is changing
and debugging the file.  It would be good if this did not fool
unload-feature.

I don't think unload-feature should try to handle strange practices
where a file redefines things that come from some other file.  If we
don't try to handle that, it should not be terribly hard to avoid
confusion when a tame and clean file is loaded more than once.

    Well, I still think that when we are concerned about a working
    unload-feature, the decisive criterion is that we want to be able to
    restore the state before a load that actually first provided a
    feature, and it does not really matter whether this load was initiated
    by load, by an autoload, or by require.

I agree with that.  If a file is well-behaved, unload-feature should
handle unloading it regardless of how the file was loaded.
That should not be too hard.

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

[...]

>>> Won't work.  Autoloads corresponding to a different file than the
>>> loaded one don't get restored.
>>
>> That's a bug which we should fix.
>
> I am not sure it is a bug.  If I load several packages redefining one
> symbol, and then unload _one_ of those packages, is it a good idea if
> the symbol gets restored to an autoload?

To be sure we're talking about the same thing: The problem is not that
"autoloads corresponding to a different file than the loaded one don't
get restored."  The problem is that loading a file (either by means of
load or by means of require) doesn't record the old autoloads.

Consider this case: apropos is autoloaded; something does (require
'apropos) and apropos.el gets loaded without recording the autoload;
you do (unload-feature 'apropos); apropos is now not bound as a
function.

>> In the mean time, you can use an auctex-override-unload-hook to
>> re-install the autoloads.
>
> This hook is not available in XEmacs or in Emacs 21.3.  And the normal
> auctex-unload-hook is getting run before symbols are fmakunbound, so
> can't restore the autoloads permanently.

FEATURE-unload-hook is called by (unload-feature FEATURE).  It is used
in Emacs since version 20.4.  You can use it to restore autoloads by
setting the autoload property of function symbols.  But you're using
undocumented inside knowledge in that case.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

>    (add-hook 'auctex-override-unload-hook
>              (lambda ()
>                (dolist (x TeX-saved-other-tex-autoloads)
>                  (fset (car x) (cdr x)))))

Hmm... that won't work because the unload-hook is run before unload-feature
calls fmakunbound on the functions.
I guess in the mean time you'll have to use `fset' instead of `defalias'
in order to prevent unload-feature from doing the fmakunbound after running
the unload-hook.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[...]

>> Won't work.  Autoloads corresponding to a different file than the
>> loaded one don't get restored.
>
> That's a bug which we should fix.

unload-feature restores the (autoload ...) form that is present in the
autoload property of the symbol.  As I understand it, that autoload
property only gets set by do_autoload.  do_autoload is called when an
autoloaded function is first called by the lisp interpreter.
(do_autoload also loads the file that defines that function.)  So if
something other than do_autoload loads a file that defines a function
that had an autoload definition before, that old autoload definition
won't be recorded.

Maybe we can shift recording the old autoload definition from
do_autoload to Fload?

> In the mean time, you can use an auctex-override-unload-hook to re-install
> the autoloads.

Don't you mean auctex-unload-hook?

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> [...]
>
>>> Won't work.  Autoloads corresponding to a different file than the
>>> loaded one don't get restored.
>>
>> That's a bug which we should fix.
>
> unload-feature restores the (autoload ...) form that is present in
> the autoload property of the symbol.  As I understand it, that
> autoload property only gets set by do_autoload.

Ah, that sounds like a more plausible explanation for the effect I
see.  That would mean that (require 'feature) can't be undone with
(unload-feature 'feature) concerning the autoloads.  And also all hook
variables are cleared.  This behavior has some sort of usefulness,
namely "get rid of that package and I don't want to ever see it
again", but I think the normal use pattern without extra options for
unload-feature would probably to restore the stuff to dormant, not
dead.

> do_autoload is called when an autoloaded function is first called by
> the lisp interpreter.  (do_autoload also loads the file that defines
> that function.)  So if something other than do_autoload loads a file
> that defines a function that had an autoload definition before, that
> old autoload definition won't be recorded.
>
> Maybe we can shift recording the old autoload definition from
> do_autoload to Fload?
>
>> In the mean time, you can use an auctex-override-unload-hook to
>> re-install the autoloads.
>
> Don't you mean auctex-unload-hook?

Probably.  I assumed Stefan was talking about a different hook, but I
can't see anything but the normal unload-hook, at least in
loadhist.el.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

>>> In the mean time, you can use an auctex-override-unload-hook to
>>> re-install the autoloads.
>> Don't you mean auctex-unload-hook?
> Probably.

No.  I was talking about a new file auctex-override.el which provides the
feature auctex-override and whose unloading runs thus the
auctex-override-unload-hook.  This file would be the only one fiddling with
non-mixed-case functions and variables.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> In the mean time, you can use an auctex-override-unload-hook to
>>>> re-install the autoloads.
>>> Don't you mean auctex-unload-hook?
>> Probably.
>
> No.  I was talking about a new file auctex-override.el which
> provides the feature auctex-override and whose unloading runs thus
> the auctex-override-unload-hook.  This file would be the only one
> fiddling with non-mixed-case functions and variables.

That's pretty much useless.  An installation of AUCTeX that does not
occupy the function cells of tex-mode and latex-mode and other
lowercase names is essentially dead as it won't get invoked on file
names and mode line cookies.  And if tex-mode.el is loaded after
AUCTeX files, it will even wipe out the native TeX-mode and LaTeX-mode
definitions of AUCTeX.

So auctex.el without auctex-override.el would be a waste of time.  In
the rare case that you want a mixture of TeX modes, you can just
require auctex (which only sets up autoloads and aliases) and then
overwrite the autoloads/aliases you don't want, letting them refer to
tex-mode.el again.

But to get something even close to working, you'll need to do the
equivalent of

(flet (LaTeX-mode)
  (require 'tex-mode))

so that tex-mode does not permanently remove AUCTeX's LaTeX-mode.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

> So auctex.el without auctex-override.el would be a waste of time.

I can't see any auctex.el in auctex's CVS repository, so I'll assume it's
autogenerated file and I guess what I called auctex-override.el could be
called auctex.el.  I used a different name specifically because I have no
idea what auctex.el is so I didn't want to confuse matters even more.
All that matters is that it's a file that does nothing more than redirect
tex-mode to TeX-mode and it can be unloaded cleanly.

> But to get something even close to working, you'll need to do the
> equivalent of

> (flet (LaTeX-mode)
>   (require 'tex-mode))

Hopefully we can convince RMS to fix this part.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So auctex.el without auctex-override.el would be a waste of time.
>
> I can't see any auctex.el in auctex's CVS repository, so I'll assume
> it's autogenerated file and I guess what I called auctex-override.el
> could be called auctex.el.

It will be autogenerated, with input from auctex.el.in which is
currently tex-site.el.in, but quite different.  In short, I am talking
about a structure that will take at least a week until it is visible
in the CVS.  It is still cooking right now.

> I used a different name specifically because I have no idea what
> auctex.el is so I didn't want to confuse matters even more.

Autoloads, load-path and other directory setup.  Pretty much
everything to get it to run.

> All that matters is that it's a file that does nothing more than
> redirect tex-mode to TeX-mode and it can be unloaded cleanly.

It also defines a few other variables, and the clean unloading is what
I have been asking about here.  Making it unload painlessly is
important so that providers of precompiled packages have no qualms
autostarting it.  If you can answer to a complaint just
"(unload-feature 'auctex)", then administrators will not get worried
about the 5% of their users that have a strong preference, and for
tex-mode.el.

>> But to get something even close to working, you'll need to do the
>> equivalent of
>
>> (flet (LaTeX-mode)
>>   (require 'tex-mode))
>
> Hopefully we can convince RMS to fix this part.

I'll worry about that once AUCTeX becomes part of Emacs proper and we
will not have to cater for backward compatibility, anyway.  And there
are a few years before we are there.

In the mean time, Emacs provides enough ways for unsuspecting users to
shoot themselves in the foot, and the alias configuration of a
pristine Emacs is probably the least of our worries.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Don't you mean auctex-unload-hook?
>
> No.  I was talking about a new file auctex-override.el which
> provides the feature auctex-override and whose unloading runs thus
> the auctex-override-unload-hook.

Whoops, my mistake.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    Maybe we can shift recording the old autoload definition from
    do_autoload to Fload?

Fload has no information about this.
It would have to be done in Fdefun, etc.

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

Richard Stallman <rms@gnu.org> writes:

>     Maybe we can shift recording the old autoload definition from
>     do_autoload to Fload?
>
> Fload has no information about this.
> It would have to be done in Fdefun, etc.

>From what I understand, the way it works now is that Ffset records the
old definition of a function in Vautoload_queue if that var is
non-nil.  do_autoload sets Vautoload_queue to t before it calls Fload
and then uses the information recorded in Vautoload_queue to set the
autoload property of function symbols.  The information in
Vautoload_queue is also used to restore things when Fload fails.

Is there a reason why Fload can't do like do_autoload and use the
information recorded in Vautoload_queue to set the autoload property
of function symbols?  (I'm not saying that doing the recording in
Fload is the best/right way, but I think it could be done.)

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    Is there a reason why Fload can't do like do_autoload and use the
    information recorded in Vautoload_queue to set the autoload property
    of function symbols?

Maybe it could work.

I think it would be better not to try changing this now.

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

Richard Stallman <rms@gnu.org> writes:

>     Is there a reason why Fload can't do like do_autoload and use the
>     information recorded in Vautoload_queue to set the autoload property
>     of function symbols?
>
> Maybe it could work.
>
> I think it would be better not to try changing this now.

Agreed; changing this would be tricky.  I'll put it on my post-release
todo list.  ;-)

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     Is there a reason why Fload can't do like do_autoload and use the
>>     information recorded in Vautoload_queue to set the autoload property
>>     of function symbols?
>>
>> Maybe it could work.
>>
>> I think it would be better not to try changing this now.
>
> Agreed; changing this would be tricky.  I'll put it on my post-release
> todo list.  ;-)

I have thought about it somewhat.  I have come to the opinion that it
is a bad idea if load-file does this sort of recording since load-file
is often used equivalently to eval-buffer and similar things.

The function that _clearly_ should trigger/use the recorded
information, however, is "require".

I don't think we need to make
(load "filename") (unload-feature 'filename)
do anything sensible (and indeed it is legal to load the same file
several times in succession), but it seems desirable to have
(require 'filename) (unload-feature 'filename)
form a proper pair.

Unfortunately, this does not work well with the site-lisp.el construct
(mapc 'load-file (directory-files "site-start.d" t ".el\\'"))

So a better expedient would be to have
(provide 'xxx)

turn on the necessary action at the end of the current load file in
case that the feature is provided the first time.

This should be a pretty reliable way to do the recordings for files
that are connected with a "feature".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>>     Is there a reason why Fload can't do like do_autoload and use the
>>>     information recorded in Vautoload_queue to set the autoload property
>>>     of function symbols?
>>>
>>> Maybe it could work.
>>>
>>> I think it would be better not to try changing this now.
>>
>> Agreed; changing this would be tricky.  I'll put it on my post-release
>> todo list.  ;-)
>
> I have thought about it somewhat.  I have come to the opinion that it
> is a bad idea if load-file does this sort of recording since load-file
> is often used equivalently to eval-buffer and similar things.
>
> The function that _clearly_ should trigger/use the recorded
> information, however, is "require".

Agreed.

> I don't think we need to make (load "filename") (unload-feature
>'filename) do anything sensible (and indeed it is legal to load the
>same file several times in succession), but it seems desirable to
>have (require 'filename) (unload-feature 'filename) form a proper
>pair.

I'm not sure if it's the best solution not to let (load "filename")
record autoloads.  But letting only (require 'filename) record
autoloads would be a big improvement.  My guess is that the vast
majority of files get loaded by do_autoload and Frequire.
Furthermore, it seems quite easy to implement the recording of
autoloads in Frequire.  I'll give it a try and experiment with it for
a while...

> Unfortunately, this does not work well with the site-lisp.el construct 
> (mapc 'load-file (directory-files "site-start.d" t ".el\\'"))
>
> So a better expedient would be to have
> (provide 'xxx)
>
> turn on the necessary action at the end of the current load file in
> case that the feature is provided the first time.
>
> This should be a pretty reliable way to do the recordings for files
> that are connected with a "feature".

I'm not familiar with this.  Could you elaborate?

When is this used?  Does it load files that define functions that
replace autoloads?

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The function that _clearly_ should trigger/use the recorded
>> information, however, is "require".
>
> Agreed.
>
>> I don't think we need to make (load "filename") (unload-feature
>>'filename) do anything sensible (and indeed it is legal to load the
>>same file several times in succession), but it seems desirable to
>>have (require 'filename) (unload-feature 'filename) form a proper
>>pair.
>
> I'm not sure if it's the best solution not to let (load "filename")
> record autoloads.

Well, the idea explored a bit later later was that "load" will record
autoloads, but not do anything with them by itself, instead letting
"provide" handle it.

> But letting only (require 'filename) record autoloads would be a big
> improvement.  My guess is that the vast majority of files get loaded
> by do_autoload and Frequire.  Furthermore, it seems quite easy to
> implement the recording of autoloads in Frequire.  I'll give it a
> try and experiment with it for a while...
>
>> Unfortunately, this does not work well with the site-lisp.el
>> construct
>> (mapc 'load-file (directory-files "site-start.d" t ".el\\'"))
>>
>> So a better expedient would be to have
>> (provide 'xxx)
>>
>> turn on the necessary action at the end of the current load file in
>> case that the feature is provided the first time.
>>
>> This should be a pretty reliable way to do the recordings for files
>> that are connected with a "feature".
>
> I'm not familiar with this.  Could you elaborate?

Many Emacs installations have a site-lisp/site-start.d directory.  If
you want some code executed automatically (usually a bunch of
autoloads), then you'll drop the .el file in that directory.

> When is this used?  Does it load files that define functions that
> replace autoloads?

I guess the most common case would be loading files that _place_
autoloads and add stuff to hook functions.

And it usually is a bunch of stuff that the system administrator
thought good for you.  For example, if you install a prepackaged
foobar package from your favorite distribution, then this will drop
foobar.el into site-lisp/site-start.d/ and foobar.el will then setup
the package foobar with autoloads and similar.

If the wisdom of the system provider did not match your personal
tastes, being able to (unload-feature 'foobar) would be definitely
nice.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

[...]

> Well, the idea explored a bit later later was that "load" will record
> autoloads, but not do anything with them by itself, instead letting
> "provide" handle it.

Ah, now I understand your post.  I think letting provide record
autoloads is a bad idea.  provide can occur anywhere in a file.  So
when provide records autoloads it won't record the autoloads that get
replaced after that position.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> David Kastrup <dak@gnu.org> writes:
>
> [...]
>
>> Well, the idea explored a bit later later was that "load" will
>> record autoloads, but not do anything with them by itself, instead
>> letting "provide" handle it.
>
> Ah, now I understand your post.  I think letting provide record
> autoloads is a bad idea.  provide can occur anywhere in a file.  So
> when provide records autoloads it won't record the autoloads that
> get replaced after that position.

No, the idea was that load initiates the recording of autoload data
alright, but will throw the recorded data away at the end of the load
unless a `provide' occured at its top level.  If the provide occured
at the top level of the load, then the end of the load will tag all
the functions with the autoload data, like do_autoload does now at the
end of its load sequence.

So the "provide" merely sets a flag, and this flag causes the
encompassing load not to throw the collected previous autoload data
away at the end of the load sequence, but use it for marking the
changed functions with the old autoloads in their properties.

Clearer now?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>> [...]
>>
>>> Well, the idea explored a bit later later was that "load" will
>>> record autoloads, but not do anything with them by itself, instead
>>> letting "provide" handle it.
>>
>> Ah, now I understand your post.  I think letting provide record
>> autoloads is a bad idea.  provide can occur anywhere in a file.  So
>> when provide records autoloads it won't record the autoloads that
>> get replaced after that position.
>
> No, the idea was that load initiates the recording of autoload data
> alright, but will throw the recorded data away at the end of the load
> unless a `provide' occured at its top level.  If the provide occured
> at the top level of the load, then the end of the load will tag all
> the functions with the autoload data, like do_autoload does now at the
> end of its load sequence.
>
> So the "provide" merely sets a flag, and this flag causes the
> encompassing load not to throw the collected previous autoload data
> away at the end of the load sequence, but use it for marking the
> changed functions with the old autoloads in their properties.
>
> Clearer now?

Yup.  (I hope so.  ;-))

But you want that autoloads are recorded in Fload, after loading the
file is complete, right?  That would be a complicated change, best
done after the release.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    So the "provide" merely sets a flag, and this flag causes the
    encompassing load not to throw the collected previous autoload data
    away at the end of the load sequence, but use it for marking the
    changed functions with the old autoloads in their properties.

    Clearer now?

Why make this depend on the presence of `provide' in the file?
If we implement this feature, it would be simpler and probably
more useful to do it for all files, whether or not they include
a `provide' call.

The other issues make this a complex matter.  I tend to think
that unload-feature should be designed for well-behaved
packages that do not redefine functions defined elsewhere.

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    So a better expedient would be to have
    (provide 'xxx)

    turn on the necessary action at the end of the current load file in
    case that the feature is provided the first time.

I am not sure if this really solves any part of the question of
how we might try to implement better unloading.  It isn't a design
for an implementation.

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    Any objection to removing those aliases?
    These names belong to AUCTeX and are just wrong in tex-mode.el.

I don't see any reason to consider them "wrong", or to think they
"belong" to anything other than tex-mode.el.

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

>     Any objection to removing those aliases?
>     These names belong to AUCTeX and are just wrong in tex-mode.el.

> I don't see any reason to consider them "wrong", or to think they
> "belong" to anything other than tex-mode.el.

- tex-mode.el uses the "tex-" and "latex-" prefix for all its functions
  and variables.

- AUCTeX uses the "TeX-" and "LaTeX-" (and a few more) prefixes for all its
  functions and variables.

I think the above is a good reason why "TeX-mode" and "LaTeX-mode" belong to
AUCTeX rather than to tex-mode.el.

So I think it's wrong for tex-mode.el to define
(defalias 'TeX-mode 'tex-mode) unless it explicitly intends to override the
AUCTeX definition.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     Any objection to removing those aliases?
>>     These names belong to AUCTeX and are just wrong in tex-mode.el.
>
>> I don't see any reason to consider them "wrong", or to think they
>> "belong" to anything other than tex-mode.el.
>
> - tex-mode.el uses the "tex-" and "latex-" prefix for all its functions
>   and variables.
>
> - AUCTeX uses the "TeX-" and "LaTeX-" (and a few more) prefixes for all its
>   functions and variables.
>
> I think the above is a good reason why "TeX-mode" and "LaTeX-mode" belong to
> AUCTeX rather than to tex-mode.el.
>
> So I think it's wrong for tex-mode.el to define
> (defalias 'TeX-mode 'tex-mode) unless it explicitly intends to override the
> AUCTeX definition.

Which would be pretty pointless, since TeX-mode is never explicitly
called by auto-mode-alist or mode specifications in files (which get
downcased before getting applied), not even when AUCTeX is active.

Indeed, AUCTeX's own TeX-mode function (which can recognize more
formats than tex-mode.el) then calls plain-tex-mode, latex-mode,
context-mode and so on based on its decision, so that the user's
preference for tex-mode.el or AUCTeX can be decided by assigning the
proper meaning to those function names, and those names only.

Where a mode in AUCTeX is required functionally instead of as a user
preference, again the mixed case variants are used.  ConTeXt-mode, for
example, is derived from plain-TeX-mode.

The whole separation has been maintained rather meticulously.  For
historical reasons AUCTeX will need to override the mixed mode aliases
in tex-mode.el, so there are no purely technical reasons that would
require removing them.  But I think that their presence in tex-mode.el
is not a good idea since it encourages unsuspecting users to do things
that will cause undesirable results when AUCTeX is installed in
parallel.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

> The whole separation has been maintained rather meticulously.  For

Actually, it seems to still use lowercase for the "main" major mode
functions (like latex-mode, ...), which I think is wrong.
If you followed my auctex-override approach (where all of auctex, except
for this auctex-override file, defines only mixed-case functions and
variables), then it would be possible to have both auctex and tex-mode
loaded and in use in the vary same Emacs, as is the case with perl-mode and
cperl-mode.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The whole separation has been maintained rather meticulously.  For
>
> Actually, it seems to still use lowercase for the "main" major mode
> functions (like latex-mode, ...), which I think is wrong.

I explained already why nothing else makes sense.  AUCTeX makes
extensive use of mode cookies in local variables, and those are only
obeyed in the lowercase version.  The choice of AUCTeX vs tex-mode is
a user preference and should not be embedded into files.

I am still thinking about whether to keep the current scheme which has
tex-mode as the main function and TeX-mode as an alias into it, or
switch that around.

The problem with a switch is that "autoload" will not replace aliases,
and so I can't replace the Emacs default scheme by just specifying new
autoloads.

> If you followed my auctex-override approach (where all of auctex,
> except for this auctex-override file, defines only mixed-case
> functions and variables), then it would be possible to have both
> auctex and tex-mode loaded and in use in the vary same Emacs, as is
> the case with perl-mode and cperl-mode.

You don't have the same problems with Perl as with TeX/LaTeX, namely
that the same file ending ".tex" is used for incompatible major modes
TeX and LaTeX, and so it becomes a good idea to specify the major mode
in local file variables.

Anyway, I am not interested in continuing this discussion.  AUCTeX has
to deal with aliases in existing Emacs versions, however imprudent,
anyway.  If you are concerned about or interested in how it is going
to do that, the right forum would be auctex-devel@gnu.org.

While I agree with your original assessment that the presence of those
aliases within tex-mode.el does more harm than good, we have to deal
with it anyway.  Removing them is no requirement, but just a breath of
sanity.

There is far more important work to get done in AUCTeX development
than to fuss around about such details.  As long as we don't have the
luxury of more than a single person offering to do any particular
task, there is no point in wasting that single person's time on
defending his decisions.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

> I explained already why nothing else makes sense.  AUCTeX makes
> extensive use of mode cookies in local variables, and those are only
> obeyed in the lowercase version.  The choice of AUCTeX vs tex-mode is
> a user preference and should not be embedded into files.

I of course understand why it would override them, but not why it would set
major-mode to `latex-mode' rather than to `LaTeX-mode'.

In my opinion, LaTeX-mode is the AUCTeX major mode, while latex-mode can be
either, depending on the user's preference.

> I am still thinking about whether to keep the current scheme which has
> tex-mode as the main function and TeX-mode as an alias into it, or
> switch that around.

I'll very much vote in favor of switching it around.

> The problem with a switch is that "autoload" will not replace aliases,
> and so I can't replace the Emacs default scheme by just specifying new
> autoloads.

Indeed, as shown in my sample auctex-override.el you just have to explicitly
fmakunbound them before setting up the autoload.  No biggie, tho.

> You don't have the same problems with Perl as with TeX/LaTeX, namely
> that the same file ending ".tex" is used for incompatible major modes
> TeX and LaTeX, and so it becomes a good idea to specify the major mode
> in local file variables.

Doesn't make any significant difference.  People still want perl-mode
cookies to use cperl-mode, just not as often.  They also want the default
auto-mode-alist to use cperl-mode (even tho it links .perl to perl-mode), so
people typically do (defalias 'perl-mode 'cperl-mode).

The real difference is that perl-modes have only one entry point
(i.e. `perl-mode') whereas TeX modes have tex-mode, latex-mode, ...
so instead of a single defalias, you have to setup a separate file,
which I called auctex-override.el.

> Anyway, I am not interested in continuing this discussion.  AUCTeX has
> to deal with aliases in existing Emacs versions, however imprudent,
> anyway.  If you are concerned about or interested in how it is going
> to do that, the right forum would be auctex-devel@gnu.org.

I was just answering your own question about the current insanity of your
solution.  I'm not particularly concerned about AUCTeX, tho I am interested
in coming up with a plan for what a clean solution would look like and what
is currently missing in Emacs to get that solution working.  I think my
suggestion of auctex-override is a solution which can be made clean (with
some bugfixing in Emacs), so I'm satisfied and will try to fix the
corresponding problems.  The fact that my solution can also be made to work
right now, using some ugly workarounds is not that interesting to me, I just
thought you might like to try it.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I explained already why nothing else makes sense.  AUCTeX makes
>> extensive use of mode cookies in local variables, and those are only
>> obeyed in the lowercase version.  The choice of AUCTeX vs tex-mode is
>> a user preference and should not be embedded into files.
>
> I of course understand why it would override them, but not why it
> would set major-mode to `latex-mode' rather than to `LaTeX-mode'.
>
> In my opinion, LaTeX-mode is the AUCTeX major mode, while latex-mode
> can be either, depending on the user's preference.

You are confusing the value of the major-mode variable with the
invocation.  The invocation "LaTeX-mode" installs latex-mode with
AUCTeX keybindings, syntax tables, mode hooks and variables.

>> I am still thinking about whether to keep the current scheme which
>> has tex-mode as the main function and TeX-mode as an alias into it,
>> or switch that around.
>
> I'll very much vote in favor of switching it around.

Noted in case that my indecision is not resolved by other
considerations.

>> The problem with a switch is that "autoload" will not replace
>> aliases, and so I can't replace the Emacs default scheme by just
>> specifying new autoloads.
>
> Indeed, as shown in my sample auctex-override.el you just have to
> explicitly fmakunbound them before setting up the autoload.  No
> biggie, tho.

Except that it makes it harder to have unload-feature restore the
state previous to the loading.

In short, it seems to complicate achieving a clean switch between
tex-mode.el and AUCTeX, but it seems like a somewhat more natural
starting positiong when one indeed wants to employ both modes in a
single session.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Stefan Monnier]

>> I of course understand why it would override them, but not why it
>> would set major-mode to `latex-mode' rather than to `LaTeX-mode'.
>> 
>> In my opinion, LaTeX-mode is the AUCTeX major mode, while latex-mode
>> can be either, depending on the user's preference.

> You are confusing the value of the major-mode variable with the
> invocation.

No such confusion: I'm quite aware of the difference.  I may be
misrepresenting things because looking at the current auctex CVS code
I can't see where LaTeX-mode is defined.

The variable `major-mode' *should* hold the function corresponding to this
invocation, so you can return to the current major mode by calling it.
It's used for C-h m for example, and probably by other things
(e.g. clone-buffer, maybe mmm-mode, some hacks to "temporarily switch major
mode", ...).

> The invocation "LaTeX-mode" installs latex-mode with
> AUCTeX keybindings, syntax tables, mode hooks and variables.

In my opinion, calling LaTeX-mode should install LaTeX-mode.
Calling latex-mode might either install latex-mode or LaTeX-mode depending
on the user's preference.

>> Indeed, as shown in my sample auctex-override.el you just have to
>> explicitly fmakunbound them before setting up the autoload.  No
>> biggie, tho.

> Except that it makes it harder to have unload-feature restore the
> state previous to the loading.

Yes, but you can't rely on unload-feature restoring the previous state
anyway because it's broken, so it's not like it makes things worse.


        Stefan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I of course understand why it would override them, but not why it
>>> would set major-mode to `latex-mode' rather than to `LaTeX-mode'.
>>> 
>>> In my opinion, LaTeX-mode is the AUCTeX major mode, while
>>> latex-mode can be either, depending on the user's preference.
>
>> You are confusing the value of the major-mode variable with the
>> invocation.
>
> No such confusion: I'm quite aware of the difference.  I may be
> misrepresenting things because looking at the current auctex CVS code
> I can't see where LaTeX-mode is defined.
>
> The variable `major-mode' *should* hold the function corresponding
> to this invocation, so you can return to the current major mode by
> calling it.

There is no point in using both latex-mode and LaTeX-mode to mean
something differently.  There is a (albeit minor) point to using both
plain-tex-mode from tex-mode.el and LaTeX-mode from AUCTeX, though.

> It's used for C-h m for example, and probably by other things
> (e.g. clone-buffer, maybe mmm-mode, some hacks to "temporarily
> switch major mode", ...).
>
>> The invocation "LaTeX-mode" installs latex-mode with AUCTeX
>> keybindings, syntax tables, mode hooks and variables.
>
> In my opinion, calling LaTeX-mode should install LaTeX-mode.

That would mean that pretty much all mode-sensitive functions from
AUCTeX would break if you tried using them in a latex-mode started
session and vice versa.  I don't see the point in providing different
function bindings to latex-mode and LaTeX-mode.

>> Except that it makes it harder to have unload-feature restore the
>> state previous to the loading.
>
> Yes, but you can't rely on unload-feature restoring the previous
> state anyway because it's broken, so it's not like it makes things
> worse.

I am relying on that part of the behavior that is not broken.  If I
insisted on using and programming for only systems that are completely
unbroken in all respects, I'd not be using a computer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think the above is a good reason why "TeX-mode" and "LaTeX-mode" belong to
> AUCTeX rather than to tex-mode.el.

tex-mode.el is using TeX-mode since the beginning, and LaTeX-mode since
1986.

1985-09-29  Richard M. Stallman  (rms@mit-prep)

	* tex-mode.el:
	New file, containing TeX-mode.

1986-08-28  Richard M. Stallman  (rms@prep)

	* loaddefs.el: Autoload plain-TeX-mode and LaTeX-mode.
	Define aliases for them.  Fix doc for TeX-mode.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I think the above is a good reason why "TeX-mode" and "LaTeX-mode"
>> belong to AUCTeX rather than to tex-mode.el.
>
> tex-mode.el is using TeX-mode since the beginning, and LaTeX-mode since
> 1986.

"Is using" is an exaggeration.  I checked out version 1.1 (from 1990),
and the only "uses" for it are the aliases.  I doubt that this has
ever been different (in spite of the following changelog entries), but
if somebody has older versions around, he can check this for
historical accuracy.

Even if at one time before 1990 it might have been the case that the
mode was not merely aliased, I doubt that pre-1990 compatibility is a
major concern nowadays.

> 1985-09-29  Richard M. Stallman  (rms@mit-prep)
>
> 	* tex-mode.el:
> 	New file, containing TeX-mode.
>
> 1986-08-28  Richard M. Stallman  (rms@prep)
>
> 	* loaddefs.el: Autoload plain-TeX-mode and LaTeX-mode.
> 	Define aliases for them.  Fix doc for TeX-mode.
>
> Andreas.

So do you have _any_ positive evidence that _anybody_ is using these
aliases these days?  They are not mentioned in the documentation, and
retaining them for the mere purpose to maybe fool people into doing
something imprudent does not seem really that useful.

As I said already: for historical reasons I have to deal with those
aliases anyway, so I don't depend on this being changed.  But can you
really think of a single actual case where they would be or have been
of actual advantage to anybody?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> "Is using" is an exaggeration.  I checked out version 1.1 (from 1990),
> and the only "uses" for it are the aliases.  I doubt that this has ever
> been different (in spite of the following changelog entries), but if
> somebody has older versions around, he can check this for historical
> accuracy.

The old RCS history was once available on fencepost, but unfortunately I
can't find it any more.  The text of the changelog suggests a different
use in former days.

> Even if at one time before 1990 it might have been the case that the
> mode was not merely aliased, I doubt that pre-1990 compatibility is a
> major concern nowadays.

But you can't claim that AUCTeX is "owning" the names either, since they
are clearly older.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Even if at one time before 1990 it might have been the case that
>> the mode was not merely aliased, I doubt that pre-1990
>> compatibility is a major concern nowadays.
>
> But you can't claim that AUCTeX is "owning" the names either, since
> they are clearly older.

I didn't claim any such thing.  I just pointed out that the only
conceivable effect of the aliases in our times is to cause trouble and
confusion.  If people need a historic excuse for blaming the bad
effects of their current decisions on somebody else, this is fine with
me.  Have fun.

Can we find something less ridiculous and irrelevant for the purpose
of bashing our heads in?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> I didn't claim any such thing.  I just pointed out that the only
> conceivable effect of the aliases in our times is to cause trouble and
> confusion.  If people need a historic excuse for blaming the bad
> effects of their current decisions on somebody else, this is fine with
> me.  Have fun.

I didn't blame anyone, it's just that both tex-mode and TeX-mode are
natural ways to name the mode for processing TeX input files, independent
of who is implementing it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I didn't claim any such thing.  I just pointed out that the only
>> conceivable effect of the aliases in our times is to cause trouble
>> and confusion.  If people need a historic excuse for blaming the
>> bad effects of their current decisions on somebody else, this is
>> fine with me.  Have fun.
>
> I didn't blame anyone, it's just that both tex-mode and TeX-mode are
> natural ways to name the mode for processing TeX input files, independent
> of who is implementing it.

So why don't we have aliases for C-mode, C++-mode, Perl-mode,
Emacs-Lisp-mode, Lisp-mode and so on?

In all of those cases, the proper name of the language in question
would be capitalized.

Why do we desperately need a special alias just in exactly that case
where it really is likely to cause problems?

Again: do you have knowledge of even a single instance where this
alias has been used, promoted, or found convenient for or by as much
as a single person?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Andreas Schwab]

You wrote in an earlier mail:

> Ok, so it was "eric".  At that time AUCTeX started to be sort of a
> contender, and AUCTeX used TeX-mode and LaTeX-mode, quite likely with
> the intent not to conflict.  And maybe "eric" switched between
> computers and was surprised that TeX-mode worked on one system, and
> barfed on another.

This is what I object to.  You blame ERS for introducing a conflict with
AuCTeX, even though he had nothing at all to do with the original
definition of TeX-mode which happened even before AUCTeX even existed.  So
I tried to get the history right.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    Why do we desperately need a special alias just in exactly that case
    where it really is likely to cause problems?

The idea that it "causes problems" is based on a mistaken idea of
how things ought to work.  ALL the usual ways of invoking a mode
for TeX should be defined by both AUCTeX and tex-mode.el.  It woulod
be a bug if they were different.

    Again: do you have knowledge of even a single instance where this
    alias has been used, promoted, or found convenient for or by as much
    as a single person?

If these names are not really used by users, maybe we could these
names in both AUCTeX and tex-mode.el.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Why do we desperately need a special alias just in exactly that
>     case where it really is likely to cause problems?
>
> The idea that it "causes problems" is based on a mistaken idea of
> how things ought to work.  ALL the usual ways of invoking a mode for
> TeX should be defined by both AUCTeX and tex-mode.el.  It woulod be
> a bug if they were different.
>
>     Again: do you have knowledge of even a single instance where
>     this alias has been used, promoted, or found convenient for or
>     by as much as a single person?
>
> If these names are not really used by users, maybe we could these
> names in both AUCTeX and tex-mode.el.

Well, people use LaTeX-mode and TeX-mode quite a bit when intending to
call AUCTeX explicitly, so I would not want to give those bindings up.
If I can get a _definite_ promise that tex-mode's aliases on TeX-mode
and LaTeX-mode will stay in place (as long as the AUCTeX maintainer of
the day is throwing a tantrum when necessary to remind people), then I
would be fine with letting AUCTeX merely overload tex-mode, latex-mode
and plain-tex-mode and not touching the aliases (which makes unloading
cleaner as that does not then automatically and inappropriately
undefine aliases unnecessarily duplicated by AUCTeX).

May I build a scheme around that assumption?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    If I can get a _definite_ promise that tex-mode's aliases on TeX-mode
    and LaTeX-mode will stay in place (as long as the AUCTeX maintainer of
    the day is throwing a tantrum when necessary to remind people), then I
    would be fine with letting AUCTeX merely overload tex-mode, latex-mode
    and plain-tex-mode and not touching the aliases

Ok.  Please put comments into tex-mode.el to remind people
that AUCTeX depends on these aliases.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     If I can get a _definite_ promise that tex-mode's aliases on
>     TeX-mode and LaTeX-mode will stay in place (as long as the
>     AUCTeX maintainer of the day is throwing a tantrum when
>     necessary to remind people), then I would be fine with letting
>     AUCTeX merely overload tex-mode, latex-mode and plain-tex-mode
>     and not touching the aliases
>
> Ok.  Please put comments into tex-mode.el to remind people that
> AUCTeX depends on these aliases.

Will do.  Thanks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

I wrote:

	Again: do you have knowledge of even a single instance where this
	alias has been used, promoted, or found convenient for or by as much
	as a single person?

    If these names are not really used by users, maybe we could these
    names in both AUCTeX and tex-mode.el.

I meant to write:

    If these names are not really used by users, maybe we could
    eliminate these names in both AUCTeX and tex-mode.el.

Re: Removing unloaded functions from auto-mode-alist.

[Johan Vromans]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
> I didn't blame anyone, it's just that both tex-mode and TeX-mode are
> natural ways to name the mode for processing TeX input files, independent
> of who is implementing it.

AFAIK, no mode command uses capitalization.

-- Johan

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Any objection to removing those aliases?
>     These names belong to AUCTeX and are just wrong in tex-mode.el.
>
> I don't see any reason to consider them "wrong", or to think they
> "belong" to anything other than tex-mode.el.

To put a bit more perspective on this: they serve no purpose within
Emacs or tex-mode.el, are referenced nowhere and documented nowhere.

The only conceivable way they could be called unwittingly by a user is
if a TeX file from somebody else contained a "mode: TeX" or "mode:
LaTeX" specification.  However, not even this case applies since mode
specs in local variables are downcased before use.

Now it also is the case that all the prefixes for variables and
functions in tex-mode.el are lowercase.

In contrast, all of the prefixes for variables and functions in AUCTeX
are mixed case.  This is especially true for hook variables and
everything else pertaining to modes, with the sole exception of the
setting of major-mode itself (which is indicated by lower case mode
names).

I have grepped through the Emacs tree right now for "TeX-".  The only
locations where it is found is when there is an explicit reference to
AUCTeX functions, and in the doc string for "define-derived-mode"
which is, in my opinion, misguided at least.

Then there some occurences in add-log-tex-like-modes that allow
major-mode to be "LaTeX-mode" or "TeX-mode", presumably because they
want to accommodate AUCTeX.  AUCTeX itself never sets major-mode to a
mixed spelled symbol, so this courtesy is, while appreciated, wasted.

The only unavoidable symbol clashes that exist are the major mode
invocation functions: obviously the user has to make the choice
whether he prefers AUCTeX or tex-mode for editing TeX and LaTeX files,
and this preference has to be reflected in the meaning of tex-mode and
latex-mode, since those are what gets invoked for TeX and LaTeX
files.

Now while the conflicts for tex-mode and latex-mode are a necessary
consequence of AUCTeX being an alternative implementation of TeX
modes, there is no fathomable reason to have this conflict for
TeX-mode and LaTeX-mode as well.  All of the hook variables and
internals of AUCTeX are carefully designed to work with _those_
spellings in order to allow a parallel installation with tex-mode.el,
and there really is no conceivable reason I can see for the aliases in
tex-mode.el.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    The only conceivable way they could be called unwittingly by a user is
    if a TeX file from somebody else contained a "mode: TeX" or "mode:
    LaTeX" specification.

The reason they would be used if some users types M-x TeX mode.
It seemed plausible to me that some users would do that.
It could be that nobody ever does.

In any case, it seems clear to me that AUCTeX and tex-mode.el are
alternative implementations of the same feature.  It is right that the
same names are used to invoke them both.  Some users choose AUCTeX,
some choose tex-mode.el, but they all want the same set of files to be
handled by their choice.

So they SHOULD be invoked by the same names.

    I explained already why nothing else makes sense.  AUCTeX makes
    extensive use of mode cookies in local variables, and those are only
    obeyed in the lowercase version.  The choice of AUCTeX vs tex-mode is
    a user preference and should not be embedded into files.

That is right.

It would be feasible to set up AUCTeX and tex-mode.el so that they
have no overlap except for the primary entry points, which are
tex-mode etc. and TeX-mode etc.  However, it makes no sense for their
primary entry points to be different.  Whichever primary entry points
are right for one of them are right for the other.  They should all
invoke whichever package the user prefers.


Someone has suggested a separate package that would "select" AUCTeX,
and to unload it to select tex-mode.el.  The goal make sense, but
there should be no need to ever unload this package.  Once loaded, it
could select one package or the other according to one or more user
option variables.  To select one package or the other, you would just
set the variables, so you would not need to unload it.

However, this package and its user options could just as well be
included in AUCTeX.  I see no benefit in making it a separate file.

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> So they SHOULD be invoked by the same names.
>
>     I explained already why nothing else makes sense.  AUCTeX makes
>     extensive use of mode cookies in local variables, and those are only
>     obeyed in the lowercase version.  The choice of AUCTeX vs tex-mode is
>     a user preference and should not be embedded into files.
>
> That is right.
>
> It would be feasible to set up AUCTeX and tex-mode.el so that they
> have no overlap except for the primary entry points, which are
> tex-mode etc. and TeX-mode etc.

That is already the case: AUCTeX uses the mixed case variants
exclusively, _except_ when it calls one of its modes that _might_ be
subjected to user choice.  All of AUCTeX's mode hooks and variables
also use the lowercase version.  So if one bothers fiddling with load
order and realiasing, one can indeed choose plain-tex-mode from
tex-mode.el, but LaTeX-mode from AUCTeX.

> However, this package and its user options could just as well be
> included in AUCTeX.  I see no benefit in making it a separate file.

Yes.  That's the current setup, anyway: requiring tex-site.el will
make AUCTeX replace the respective variables.  I am at the moment just
concerned with creating a setup where Emacs packagers would have no
qualms enabling AUCTeX as the default mode by preloading "auctex.el"
(to be created).  And this goal can be achieved if (unload-feature
'auctex) or something similar will remove it again.

Another possibility would be to have a customizable variable
AUCTeX-modes which contains all modes that should be provided by
AUCTeX.  Psychologically however, (setq AUCTeX-modes nil) means that
you have to beg AUCTeX to be gone, whereas (unload-feature 'AUCTeX)
commands it to be gone.  People objecting to AUCTeX might prefer the
second variant on principle as long as one does not tell them that it
only works because it wants to...  Maybe I'll try combining both
approaches: if I am saving the function cells of both the AUCTeX modes
and tex-mode.el after loading, restoring via auctex-unload-hook should
also be possible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

      I am at the moment just
    concerned with creating a setup where Emacs packagers would have no
    qualms enabling AUCTeX as the default mode by preloading "auctex.el"
    (to be created).  And this goal can be achieved if (unload-feature
    'auctex) or something similar will remove it again.

There would be no need for something as drastic as using unload-feature.
If there is a user option to select between AUCTeX and the standard
TeX modes, a user who wants the latter just has to set the option.

      Psychologically however, (setq AUCTeX-modes nil) means that
    you have to beg AUCTeX to be gone, whereas (unload-feature 'AUCTeX)
    commands it to be gone.

I don't see why a user would care which, as long as it has the same
practical result: to use the standard TeX modes.

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

[...]

> Won't work.  Autoloads corresponding to a different file than the
> loaded one don't get restored.  I have not found the exact place that
> causes this, but only the "right" definitions cause the autoload to be
> saved in the autoload property of the corresponding function.

When the lisp interpreter tries to call a function that is autoloaded,
it calls do_autoload (in src/eval.c) to load the actual definition and
then tries again.  do_autoload saves the old definition of the
function in the autoload property.

Lute.

Re: Removing unloaded functions from auto-mode-alist.

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Forget it, Bub.  TeX-mode and LaTeX-mode are already taken as aliases.
> Who was the smart guy responsible for that?  The annotations show:
>
> 1.3          (jimb     13-May-91): ;;;###autoload
> 1.17         (eric     23-Apr-93): (defalias 'TeX-mode 'tex-mode)
> 1.3          (jimb     13-May-91): ;;;###autoload
> 1.99         (rms      16-Feb-99): (defalias 'plain-TeX-mode 'plain-tex-mode)
> 1.99         (rms      16-Feb-99): ;;;###autoload
> 1.17         (eric     23-Apr-93): (defalias 'LaTeX-mode 'latex-mode)
> 1.1          (root     28-Aug-90): 
>
> Ok, so it was "eric".

It's much older than that, see lisp/ChangeLog.1.

> At that time AUCTeX started to be sort of a contender, and AUCTeX used
> TeX-mode and LaTeX-mode, quite likely with the intent not to conflict.

Did AUCTeX already exist in 1985?  I don't think so.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Removing unloaded functions from auto-mode-alist.

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Forget it, Bub.  TeX-mode and LaTeX-mode are already taken as aliases.
>> Who was the smart guy responsible for that?  The annotations show:
>>
>> 1.3          (jimb     13-May-91): ;;;###autoload
>> 1.17         (eric     23-Apr-93): (defalias 'TeX-mode 'tex-mode)
>> 1.3          (jimb     13-May-91): ;;;###autoload
>> 1.99         (rms      16-Feb-99): (defalias 'plain-TeX-mode 'plain-tex-mode)
>> 1.99         (rms      16-Feb-99): ;;;###autoload
>> 1.17         (eric     23-Apr-93): (defalias 'LaTeX-mode 'latex-mode)
>> 1.1          (root     28-Aug-90): 
>>
>> Ok, so it was "eric".
>
> It's much older than that, see lisp/ChangeLog.1.
>
>> At that time AUCTeX started to be sort of a contender, and AUCTeX used
>> TeX-mode and LaTeX-mode, quite likely with the intent not to conflict.
>
> Did AUCTeX already exist in 1985?  I don't think so.

@node Ancient History
@comment  node-name,  next,  previous,  up
@section Ancient History

The origin of AUC @TeX{} is @file{tex-mode.el} from Emacs 16.  Lars
Peter Fischer @samp{<fischer@@iesd.auc.dk>} wrote the first functions to
insert font macros and Danish characters back in 1986.  Per Abrahamsen
@samp{<abraham@@iesd.auc.dk>} wrote the functions to insert environments
and sections, to indent the text, and the outline minor mode in 1987.
Kresten Krab Thorup @samp{<krab@@iesd.auc.dk>} wrote the buffer handling
and debugging functions, the macro completion, and much more, including
much improved indentation and text formatting functions.  He also made
the first public release in 1991, and was the main author and
coordinator of every release up to and including 6.0.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Removing unloaded functions from auto-mode-alist.

[Lute Kamstra]

David Kastrup <dak@gnu.org> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> unload-feature removes functions it is unloading from hooks.  What
>> about removing these functions from auto-mode-alist as well?

[...]

> Actually, _both_ sound like a spectacularly bad idea if the unloaded
> function gets replaced by a restored autoload.  I don't know the code
> well enough.

Good point.

I don't thinks it's that simple, though.  The idea of (unload-feature
x) is to undo the changes introduced by feature x.  If feature x puts
a function on a hook or in auto-mode-alist, then unload-feature should
remove it; even if that function is replaced by a restored autoload.
Unfortunately, there is no way to tell how that function got on a hook
or in auto-mode-alist.

I guess it can't hurt to leave a function on a hook or in
auto-mode-alist if it is replaced by a restored autoload. (Even if
feature x actually put it there.)  See patch below.  Erring on the
other side seems more damaging: removing a function from a hook when
that function was put there by a user's init file or something.

What do others think?

Lute.


Index: lisp/loadhist.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/loadhist.el,v
retrieving revision 1.32
diff -C2 -r1.32 loadhist.el
*** lisp/loadhist.el	19 Apr 2005 15:08:05 -0000	1.32
--- lisp/loadhist.el	19 Apr 2005 20:27:30 -0000
***************
*** 189,194 ****
  			(memq x unload-feature-special-hooks)))	; Known abnormal hooks etc.
  	   (dolist (y unload-hook-features-list)
! 	     (when (eq (car-safe y) 'defun)
! 	       (remove-hook x (cdr y))))))))
      (when (fboundp 'elp-restore-function) ; remove ELP stuff first
        (dolist (elt unload-hook-features-list)
--- 189,201 ----
  			(memq x unload-feature-special-hooks)))	; Known abnormal hooks etc.
  	   (dolist (y unload-hook-features-list)
! 	     (when (and (eq (car-safe y) 'defun)
! 			(not (get (cdr y) 'autoload)))
! 	       (remove-hook x (cdr y)))))))
!       ;; Remove any feature-symbols from auto-mode-alist as well.
!       (dolist (y unload-hook-features-list)
! 	(when (and (eq (car-safe y) 'defun)
! 		   (not (get (cdr y) 'autoload)))
! 	  (setq auto-mode-alist
! 		(rassq-delete-all (cdr y) auto-mode-alist)))))
      (when (fboundp 'elp-restore-function) ; remove ELP stuff first
        (dolist (elt unload-hook-features-list)

Re: Removing unloaded functions from auto-mode-alist.

[Richard Stallman]

    I guess it can't hurt to leave a function on a hook or in
    auto-mode-alist if it is replaced by a restored autoload. (Even if
    feature x actually put it there.)  See patch below.  Erring on the
    other side seems more damaging: removing a function from a hook when
    that function was put there by a user's init file or something.

Usually when a package defines a function and puts it on hooks, that
function will not be autoloaded.  If the function is autoloaded, that
means it is meant to be used when the package is not loaded.  So that
function might be put on hooks by users before the package is loaded.

So I think what you're proposing is the right criterion.
It would be right most of the time.