PB with auctex-11.54 (debian testing)

[Daniel Flipo]

Hi all,

I have upgraded my Debian testing system as usual
with "apt-get upgrade" and got auctex-11.54 installed
instead of 11.53.

Auctex doesn't get loaded now (it worked fine with 11.53)
I get the error message:

"Variable binding depth exceeds max-specspdl-size"

I have stripped off everything "personnal" (no hacked
site-start.el) and left one only line:
(require 'tex-site)
in my .emacs file.

Any clue of what is going on?

Thanks in advance!

====================================================================
Daniel Flipo ***@univ-lille1.fr
UFR de Mathématiques -- Bâtiment M2 Tél : [phone]
Université des Sciences et Technologies
F-59655 Villeneuve d'Ascq Cedex France
====================================================================

[David Kastrup]

Post by Daniel Flipo
Hi all,
I have upgraded my Debian testing system as usual
with "apt-get upgrade" and got auctex-11.54 installed
instead of 11.53.
Auctex doesn't get loaded now (it worked fine with 11.53)
"Variable binding depth exceeds max-specspdl-size"
I have stripped off everything "personnal" (no hacked
(require 'tex-site)
in my .emacs file.
Any clue of what is going on?

On Fedora Core 3, this was caused by an utterly outdated "Emacspeak"
package that shadowed regexp-opt.el with a buggy old file for Emacs-19
(!) compatibility purposes.

Do you have Emacspeak installed? And which versions? The current
version would be 21.0. If it turns out that Debian has the same
conflict, we should work on the package dependencies for it.

[Frank Küster]

Post by David Kastrup

Post by Daniel Flipo
"Variable binding depth exceeds max-specspdl-size"

[...]

Post by David Kastrup
On Fedora Core 3, this was caused by an utterly outdated "Emacspeak"
package that shadowed regexp-opt.el with a buggy old file for Emacs-19
(!) compatibility purposes.
Do you have Emacspeak installed? And which versions? The current
version would be 21.0.

The newest version in Debian is 17.0, and the maintainer doesn't seem
interested in the package any more - at least if you judge only from the
bug page.

Post by David Kastrup
If it turns out that Debian has the same
conflict, we should work on the package dependencies for it.

http://bugs.debian.org/291970

I was thinking about doing an NMU for this. But since then I have
discovered a more severe issue of this package:

http://bugs.debian.org/292322

The license situation is unclear, and the package might be non-free.

Hm, considering this, I think I should do the NMU anyway. It does break
auctex (and probably other packages) *now*, but a removal due to a bad
license might take time; it will take even more time if the author
promises to clear up the license situation.

Regards, Frank

[David Kastrup]

Post by Frank Küster

Post by David Kastrup

Post by Daniel Flipo
"Variable binding depth exceeds max-specspdl-size"

[...]

Post by David Kastrup
On Fedora Core 3, this was caused by an utterly outdated "Emacspeak"
package that shadowed regexp-opt.el with a buggy old file for Emacs-19
(!) compatibility purposes.
Do you have Emacspeak installed? And which versions? The current
version would be 21.0.

The newest version in Debian is 17.0, and the maintainer doesn't seem
interested in the package any more - at least if you judge only from the
bug page.

Post by David Kastrup
If it turns out that Debian has the same
conflict, we should work on the package dependencies for it.

http://bugs.debian.org/291970
I was thinking about doing an NMU for this. But since then I have
http://bugs.debian.org/292322
The license situation is unclear, and the package might be non-free.
Hm, considering this, I think I should do the NMU anyway. It does
break auctex (and probably other packages) *now*, but a removal due
to a bad license might take time; it will take even more time if the
author promises to clear up the license situation.

Well, it may be necessary to move the package to non-free, but this
does not affect the package itself. If an update to 21.0 is not
feasible, at least the package should take care not to install
packages into Emacs-21 that are older than what Emacs-21 has.

And the AUCTeX package should list the current Emacspeak package as a
package conflict.

[Peter S Galbraith]

Post by Frank Küster
I was thinking about doing an NMU for this. But since then I have
http://bugs.debian.org/292322
The license situation is unclear, and the package might be non-free.

Package: emacspeak
Version: 17.0-1
Severity: severity

Gotta love that "Severity: severity" :-)
People should use `M-x debian-bug' ;-)

At least are all the .el files under the GPL? If not, then it's not
even non-free, it's not distributable.

Peter

[Frank Küster]

Post by Peter S Galbraith

Post by Frank Küster
I was thinking about doing an NMU for this. But since then I have
http://bugs.debian.org/292322
The license situation is unclear, and the package might be non-free.

Package: emacspeak
Version: 17.0-1
Severity: severity
Gotta love that "Severity: severity" :-)
People should use `M-x debian-bug' ;-)

I did. I started with "normal", saying that the download location for
the upstream tarball had changed. I switched to important when I noticed
that it said "Author: T.V. Raman", but didn't tell at that place that
also DEC and Adobe hold a Copyright, and that it later mixed up license
and Copyright statement.

Then I read the license statement and noticed that it didn't allow
modification, which is why I switched to, ähem, severious?

Post by Peter S Galbraith
At least are all the .el files under the GPL? If not, then it's not
even non-free, it's not distributable.

I didn't check all 156, but at least some are. Why do you think it
wouldn't be distributable without?

Regards, Frank

[Peter S Galbraith]

Post by Frank Küster

Post by Peter S Galbraith
At least are all the .el files under the GPL? If not, then it's not
even non-free, it's not distributable.

I didn't check all 156, but at least some are. Why do you think it
wouldn't be distributable without?

Any elisp file is bound to use Emacs code as a library. Think of
`require' as loding other elisp code. Except that those libraries are
not LGPL'ed, they are GPL'ed. So that code must also be under the GPL.

This only applies to elisp files. Not to compiled binary invoked from
within Emacs in a shell.

Peter

[Daniel Flipo]

Post by David Kastrup
On Fedora Core 3, this was caused by an utterly outdated "Emacspeak"
package that shadowed regexp-opt.el with a buggy old file for

Emacs-19

Post by David Kastrup
(!) compatibility purposes.
Do you have Emacspeak installed? And which versions? The current
version would be 21.0. If it turns out that Debian has the same
conflict, we should work on the package dependencies for it.

I have checked:
# apt-cache search emacspeak
returns 4 packages, among them 'emacspeak' and 'emacspeak-ss',
# apt-get remove emacspeak and emacspeak-ss
says they are not installed on my system, the other two
'eflite' and 'yasr' are not installed either...

Daniel Flipo

[David Kastrup]

Post by David Kastrup

Post by David Kastrup
On Fedora Core 3, this was caused by an utterly outdated "Emacspeak"
package that shadowed regexp-opt.el with a buggy old file for

Emacs-19

Post by David Kastrup
(!) compatibility purposes.
Do you have Emacspeak installed? And which versions? The current
version would be 21.0. If it turns out that Debian has the same
conflict, we should work on the package dependencies for it.

# apt-cache search emacspeak
returns 4 packages, among them 'emacspeak' and 'emacspeak-ss',
# apt-get remove emacspeak and emacspeak-ss
says they are not installed on my system, the other two
'eflite' and 'yasr' are not installed either...

Try
M-x list-load-path-shadows RET

to figure out whether some old libraries are in your system.

[Frank Küster]

Post by David Kastrup

Post by Daniel Flipo
# apt-cache search emacspeak
returns 4 packages, among them 'emacspeak' and 'emacspeak-ss',
# apt-get remove emacspeak and emacspeak-ss
says they are not installed on my system, the other two
'eflite' and 'yasr' are not installed either...

Try
M-x list-load-path-shadows RET
to figure out whether some old libraries are in your system.

In addition, please send us the output of the command

dpkg -S regexp-opt.el

(it shows which packages have installed such a file)

Regards, Frank

[Daniel Flipo]

Post by Frank Küster

Post by David Kastrup
Try
M-x list-load-path-shadows RET
to figure out whether some old libraries are in your system.

I append the result (file Shadows)

Post by Frank Küster
In addition, please send us the output of the command
dpkg -S regexp-opt.el
(it shows which packages have installed such a file)

flipo% dpkg -S regexp-opt.el
emacs21-el: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.el
emacs21-common: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.elc
xemacs21-basesupport:
/usr/share/xemacs21/xemacs-packages/lisp/xemacs-base/regexp-opt.elc

Daniel Flipo.

Daniel Flipo

[Frank Küster]

Post by Daniel Flipo

Post by Frank Küster

Post by David Kastrup
Try
M-x list-load-path-shadows RET
to figure out whether some old libraries are in your system.

I append the result (file Shadows)

Post by Frank Küster
In addition, please send us the output of the command
dpkg -S regexp-opt.el
(it shows which packages have installed such a file)

flipo% dpkg -S regexp-opt.el
emacs21-el: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.el
emacs21-common: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.elc
/usr/share/xemacs21/xemacs-packages/lisp/xemacs-base/regexp-opt.elc

This is how it should be.

Also the shadowing list doesn't indicate any other regexp-opt.el. You
did list-load-path-shadows as the user who also gets the error, didn't
you?

Regards, Frank

[Daniel Flipo]

Frank Küster writes :

« > flipo% dpkg -S regexp-opt.el
« > emacs21-el: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.el
« > emacs21-common: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.elc
« > xemacs21-basesupport:
« > /usr/share/xemacs21/xemacs-packages/lisp/xemacs-base/regexp-opt.elc
«
« This is how it should be.
«
« Also the shadowing list doesn't indicate any other regexp-opt.el. You
« did list-load-path-shadows as the user who also gets the error, didn't
« you?

Yes. I did it again just now, to be sure.
There is again no occurence of regexp-opt.el in the list
produced by M-x list-load-path-shadows RET

Daniel Flipo.

[David Kastrup]

Post by Daniel Flipo
« > flipo% dpkg -S regexp-opt.el
« > emacs21-el: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.el
« > emacs21-common: /usr/share/emacs/21.3/lisp/emacs-lisp/regexp-opt.elc
« > /usr/share/xemacs21/xemacs-packages/lisp/xemacs-base/regexp-opt.elc
«
« This is how it should be.
«
« Also the shadowing list doesn't indicate any other regexp-opt.el. You
« did list-load-path-shadows as the user who also gets the error, didn't
« you?
Yes. I did it again just now, to be sure.
There is again no occurence of regexp-opt.el in the list
produced by M-x list-load-path-shadows RET

Please do C-h f regexp-opt-group RET

click with the middle mouse button on the underlined link "regexp-opt"
and post the first 30 lines of the function definition that this takes
you to.

We'll have to find out whether it is the same bug as the last one.

Also post any version information at the top of the file, and check
what directory it is in (M-x pwd RET, for example).

[David Kastrup]

[...]

Post by David Kastrup
Please do C-h f regexp-opt-group RET

Forget it, I just saw the traceback you posted. This problem is not
due to regexp-opt. Sorry, it looked so similar that I thought it was
a sure thing.

[Ralf Angeli]

Post by Daniel Flipo
I have upgraded my Debian testing system as usual
with "apt-get upgrade" and got auctex-11.54 installed
instead of 11.53.
Auctex doesn't get loaded now (it worked fine with 11.53)
"Variable binding depth exceeds max-specspdl-size"

Can you send a backtrace of this error? To do this, insert

(setq debug-on-error t)

as the first line into your init file, restart Emacs and open a LaTeX
file. When the error occurs, a buffer with the backtrace should
open.

[Daniel Flipo]

Ralf Angeli writes:

« > Auctex doesn't get loaded now (it worked fine with 11.53)
« > I get the error message:
« >
« > "Variable binding depth exceeds max-specspdl-size"
«
« Can you send a backtrace of this error? To do this, insert
«
« (setq debug-on-error t)
«
« as the first line into your init file, restart Emacs and open a LaTeX
« file. When the error occurs, a buffer with the backtrace should
« open.

My .emacs file now holds just these 2 lines
(setq debug-on-error t)
(require 'tex-site)

No *Backtrace* buffer is produced when I open a .tex file,
so I followed the advice I get in the *Messages* buffer:
I start emacs with

flipo% emacs --debug-init .&

Then I get a *Backtrace* buffer* which I append here.

Thanks a lot to all of you!

Daniel Flipo.

[Ralf Angeli]

Post by Daniel Flipo
No *Backtrace* buffer is produced when I open a .tex file,
I start emacs with
flipo% emacs --debug-init .&
Then I get a *Backtrace* buffer* which I append here.

| Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
| custom-add-to-group(TeX-file TeX-lisp-directory custom-variable)
| custom-handle-keyword(TeX-lisp-directory :group TeX-file custom-variable)
| custom-declare-variable(TeX-lisp-directory (concat "/usr/share/" (symbol-name debian-emacs-flavor) "/site-lisp/auctex/") ("/usr/local/share/emacs/site-lisp/tex-site.elc" . 625) :group TeX-file :type directory)
| require(tex-site)
| eval-buffer(#<buffer *load*<22>> nil "tex" nil t)
| load-with-code-conversion("/usr/share/emacs/site-lisp/auctex/tex.el" "tex" nil t)
| load("tex" nil t)
| require(tex-site)
[...]
| eval-buffer(#<buffer *load*<2>> nil "tex" nil t)
| load-with-code-conversion("/usr/share/emacs/site-lisp/auctex/tex.el" "tex" nil t)
| load("tex" nil t)
| require(tex-site)
| eval-buffer(#<buffer *load*> nil "~/.emacs" nil t)
| load-with-code-conversion("/home/flipo/.emacs" "~/.emacs" t t)
| load("~/.emacs" t t)

Something is rotten in the state of Denmark.

Why does tex-site.el try to load tex.el? Do you have a non-standard
tex-site.el? Maybe you could send the file for inspection. Please
locate it through Emacs by typing `M-x locate-libary RET tex-site
RET'.

In addition I don't understand why it tries to load tex.el and not
tex.elc. The result of `list-load-path-shadows' already showed that
/usr/share/emacs/site-lisp/auctex/... (which holds the source files)
shadows /usr/share/emacs21/site-lisp/auctex/... (which holds the
compiled files). I guess it should be the other way round.

[Frank Küster]

Post by Ralf Angeli
In addition I don't understand why it tries to load tex.el and not
tex.elc. The result of `list-load-path-shadows' already showed that
/usr/share/emacs/site-lisp/auctex/... (which holds the source files)
shadows /usr/share/emacs21/site-lisp/auctex/... (which holds the
compiled files). I guess it should be the other way round.

You're right, I didn't notice that. This is not a general Debian bug -
here it is different.

Regards, Frank

[Daniel Flipo]

Ralf Angeli writes:

� > flipo% emacs --debug-init .&
� >
� > Then I get a *Backtrace* buffer* which I append here.
�
� | Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
� | custom-add-to-group(TeX-file TeX-lisp-directory custom-variable)
� | custom-handle-keyword(TeX-lisp-directory :group TeX-file custom-variable)
� | custom-declare-variable(TeX-lisp-directory (concat "/usr/share/" (symbol-name debian-emacs-flavor) "/site-lisp/auctex/") ("/usr/local/share/emacs/site-lisp/tex-site.elc" . 625) :group TeX-file :type directory)
� | require(tex-site)
� | eval-buffer(#<buffer *load*<22>> nil "tex" nil t)
� | load-with-code-conversion("/usr/share/emacs/site-lisp/auctex/tex.el" "tex" nil t)
� | load("tex" nil t)
� | require(tex-site)
� [...]
� | eval-buffer(#<buffer *load*<2>> nil "tex" nil t)
� | load-with-code-conversion("/usr/share/emacs/site-lisp/auctex/tex.el" "tex" nil t)
� | load("tex" nil t)
� | require(tex-site)
� | eval-buffer(#<buffer *load*> nil "~/.emacs" nil t)
� | load-with-code-conversion("/home/flipo/.emacs" "~/.emacs" t t)
� | load("~/.emacs" t t)
�
� Something is rotten in the state of Denmark.

My system is rotten, I guess :-(

� Why does tex-site.el try to load tex.el? Do you have a non-standard
� tex-site.el? Maybe you could send the file for inspection. Please
� locate it through Emacs by typing `M-x locate-libary RET tex-site
� RET'.

M-x locate-libary RET tex-site RET says
/usr/local/share/emacs/site-lisp/tex-site.elc
!!!

I just can't figure out how emacs has found this one.
I do have a directory /usr/local/share/emacs/site-lisp/
with local .el(c) files.

Normally, I load my local file site-start.el file:
/usr/local/share/emacs/site-lisp/site-start.el(c)
by adding the line
(load "/usr/local/share/emacs/site-lisp/site-start")
to the standard /etc/emacs/site-start.el file (empty normally).

Then the local site-start.el loads my local tex-site.el(c).

But, before reporting my problem, I took care to move
out of the way the loading of my local file site-start.el file.
I thought it would hide all my local files for the test, but
it does not, as the *Backtrace* shows...
Emacs still finds the directory
/usr/local/share/emacs/site-lisp/
and the tex-site.el(c) files inside...
How is this possible?

Now, I have tar-gziped my /usr/local/share/emacs directory, Then
I removed and re-installed auctex from scratch.
It does work properly! of course my customizations are lost :-(

Sorry to have wasted your precious time with my local mess.
I am looking forward to David's talks at EuroTeX in March,
I hope I'll be able to learn the proper way of customizing auctex ;-)

� In addition I don't understand why it tries to load tex.el and not
� tex.elc. The result of `list-load-path-shadows' already showed that
� /usr/share/emacs/site-lisp/auctex/... (which holds the source files)
� shadows /usr/share/emacs21/site-lisp/auctex/... (which holds the
� compiled files). I guess it should be the other way round.

The file 50auctex.el installed by Debian says:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; This file is automatically generated.

(if (fboundp 'debian-pkg-add-load-path-item)
(progn (debian-pkg-add-load-path-item "/usr/share/emacs21/site-lisp/auctex/")
(debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/auctex/"))
(progn (add-to-list 'load-path "/usr/share/emacs21/site-lisp/auctex/" 'append)
(add-to-list 'load-path "/usr/share/emacs/site-lisp/auctex/" 'append)))

(require 'tex-site)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Is this correct?

Daniel Flipo.

[Ralf Angeli]

Post by Daniel Flipo
M-x locate-libary RET tex-site RET says
/usr/local/share/emacs/site-lisp/tex-site.elc
!!!
I just can't figure out how emacs has found this one.
I do have a directory /usr/local/share/emacs/site-lisp/
with local .el(c) files.
/usr/local/share/emacs/site-lisp/site-start.el(c)
by adding the line
(load "/usr/local/share/emacs/site-lisp/site-start")
to the standard /etc/emacs/site-start.el file (empty normally).
Then the local site-start.el loads my local tex-site.el(c).
But, before reporting my problem, I took care to move
out of the way the loading of my local file site-start.el file.
I thought it would hide all my local files for the test, but
it does not, as the *Backtrace* shows...
Emacs still finds the directory
/usr/local/share/emacs/site-lisp/
and the tex-site.el(c) files inside...
How is this possible?

That's due to the Debian misconduct of adding
"/usr/local/share/emacs/site-lisp" to `load-path'. It's specified
somewhere in their Emacs policy but dunno why. The XEmacs I am using
is provided by Debian and I was bitten twice by it not finding the
right AUCTeX installation due to this stupidity. I had to comment the
respective line in /etc/xemacs21/site-start.d/00debian.el. If I knew
more about load-paths, I'd probably written a bug report.

Post by Daniel Flipo
Now, I have tar-gziped my /usr/local/share/emacs directory, Then
I removed and re-installed auctex from scratch.
It does work properly! of course my customizations are lost :-(

The purpose of tex-site.el changed with the 11.5x series of AUCTeX.
It is no longer supposed to be edited by the user or an administrator.
Either do customizations in your user init file (e.g. via Emacs'
Customize facilities) or in a special site init file.

Post by Daniel Flipo
« In addition I don't understand why it tries to load tex.el and not
« tex.elc. The result of `list-load-path-shadows' already showed that
« /usr/share/emacs/site-lisp/auctex/... (which holds the source files)
« shadows /usr/share/emacs21/site-lisp/auctex/... (which holds the
« compiled files). I guess it should be the other way round.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; This file is automatically generated.
(if (fboundp 'debian-pkg-add-load-path-item)
(progn (debian-pkg-add-load-path-item "/usr/share/emacs21/site-lisp/auctex/")
(debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/auctex/"))
(progn (add-to-list 'load-path "/usr/share/emacs21/site-lisp/auctex/" 'append)
(add-to-list 'load-path "/usr/share/emacs/site-lisp/auctex/" 'append)))
(require 'tex-site)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Is this correct?

I don't know what `debian-pkg-add-load-path-item' does, but the
`add-to-list' stuff seems correct. Maybe some of your customizations
incorrectly altered `load-path'. Make sure that the paths for the
installed Emacs flavors are _before_ the independent paths. In the
example above /usr/share/emacs21/... has to be before
/usr/share/emacs/... when looking at the output of `C-h v load-path
RET'.

[Frank Küster]

Post by Ralf Angeli

Post by Daniel Flipo
But, before reporting my problem, I took care to move
out of the way the loading of my local file site-start.el file.
I thought it would hide all my local files for the test, but
it does not, as the *Backtrace* shows...
Emacs still finds the directory
/usr/local/share/emacs/site-lisp/
and the tex-site.el(c) files inside...
How is this possible?

That's due to the Debian misconduct of adding
"/usr/local/share/emacs/site-lisp" to `load-path'. It's specified
somewhere in their Emacs policy but dunno why. The XEmacs I am using
is provided by Debian and I was bitten twice by it not finding the
right AUCTeX installation due to this stupidity. I had to comment the
respective line in /etc/xemacs21/site-start.d/00debian.el. If I knew
more about load-paths, I'd probably written a bug report.

I don't see why this is stupid. How else can a local administrator
install newer versions of files? I think it's even possible to use
auctex installed in /usr/local/, just with a little tweaking of
/etc/emacs21/site-start-d/50auctex.el.

Post by Ralf Angeli

Post by Daniel Flipo
Is this correct?

I don't know what `debian-pkg-add-load-path-item' does,

,----
| This function will make sure that their additions end up in the right
| place -- before the emacs system directories, but after the
| /usr/local/ directories.
`----

Post by Ralf Angeli
but the
`add-to-list' stuff seems correct. Maybe some of your customizations
incorrectly altered `load-path'. Make sure that the paths for the
installed Emacs flavors are _before_ the independent paths. In the
example above /usr/share/emacs21/... has to be before
/usr/share/emacs/... when looking at the output of `C-h v load-path
RET'.

If this is not the case, it's a bug in a package that fails to use
debian-pkg-add-load-path-item.

Regards, Frank

[Ralf Angeli]

Post by Frank Küster

Post by Ralf Angeli
That's due to the Debian misconduct of adding
"/usr/local/share/emacs/site-lisp" to `load-path'. It's specified
somewhere in their Emacs policy but dunno why. The XEmacs I am using
is provided by Debian and I was bitten twice by it not finding the
right AUCTeX installation due to this stupidity. I had to comment the
respective line in /etc/xemacs21/site-start.d/00debian.el. If I knew
more about load-paths, I'd probably written a bug report.

I don't see why this is stupid. How else can a local administrator
install newer versions of files? I think it's even possible to use
auctex installed in /usr/local/, just with a little tweaking of
/etc/emacs21/site-start-d/50auctex.el.

The problem is that most software packages don't follow the separation
scheme Debian uses. AUCTeX and Gnus for example will install
themselves into /usr/local/share/emacs/site-lisp/ if configured for
Emacs and some XEmacs package directory if configured for XEmacs. But
the XEmacs shipped with Debian will look into
/usr/local/share/emacs/site-lisp/ and find a package not intended to
be run with it and files byte-compiled with Emacs. Assuming that
/usr/local/share/emacs/site-lisp/ is a directory holding only
uncompiled source files is out of touch with reality.

I think that administrators installing additional software for the
different Emacsen on their systems should be intelligent enough to
care for themselves about adapting load-path. If Debian really wants
to add the /usr/local/ tree to the default load-path then they should
at least refrain from adding /usr/local/share/emacs/site-lisp/ to
load-path in XEmacs as the path is traditionally used for installing
Elisp files for Emacs.

[Frank Küster]

Post by Ralf Angeli
The problem is that most software packages don't follow the separation
scheme Debian uses. AUCTeX and Gnus for example will install
themselves into /usr/local/share/emacs/site-lisp/ if configured for
Emacs and some XEmacs package directory if configured for XEmacs. But
the XEmacs shipped with Debian will look into
/usr/local/share/emacs/site-lisp/ and find a package not intended to
be run with it and files byte-compiled with Emacs. Assuming that
/usr/local/share/emacs/site-lisp/ is a directory holding only
uncompiled source files is out of touch with reality.

Yes, you are right - I didn't see this. It *is* worth a bug report, but
it can wait until sarge is released, or at least frozen.

Regards, Frank

[Frank Küster]

Post by Daniel Flipo
But, before reporting my problem, I took care to move
out of the way the loading of my local file site-start.el file.
I thought it would hide all my local files for the test, but
it does not, as the *Backtrace* shows...
Emacs still finds the directory
/usr/local/share/emacs/site-lisp/
and the tex-site.el(c) files inside...
How is this possible?

That's the usual setup in Debian: The load path always contains
/usr/local/share/emacs/site-lisp and
/usr/local/share/<emacs-flavor>/site-lisp. This enables the local
administrator to install newer versions than provided by Debian. By the
way, the tetex packages do the same: TEXMFLOCAL is searched before
TEXMFMAIN (and TEXMFVAR).

Post by Daniel Flipo
« In addition I don't understand why it tries to load tex.el and not
« tex.elc. The result of `list-load-path-shadows' already showed that
« /usr/share/emacs/site-lisp/auctex/... (which holds the source files)
« shadows /usr/share/emacs21/site-lisp/auctex/... (which holds the
« compiled files). I guess it should be the other way round.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; This file is automatically generated.
(if (fboundp 'debian-pkg-add-load-path-item)
(progn (debian-pkg-add-load-path-item "/usr/share/emacs21/site-lisp/auctex/")
(debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/auctex/"))
(progn (add-to-list 'load-path "/usr/share/emacs21/site-lisp/auctex/" 'append)
(add-to-list 'load-path "/usr/share/emacs/site-lisp/auctex/" 'append)))
(require 'tex-site)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Is this correct?

Yes, this should put the "<emacs-flavor>" directories (where the
byte-compiled files are) before the plain "emacs" directories. I guess
it could be shortened to

(progn (debian-pkg-add-load-path-item "/usr/share/emacs21/site-lisp/auctex/")
(debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/auctex/"))

because auctex depends on emacsen-common which defines this
function. Oh, it does _not_ depend directly on it, but that's a
different bug. At least emacs21 depends on it, and auctex depends on
emacs21, so that the function will be known every time 50auctex.el is
loaded.

Davide?

Regards, Frank

[Davide G. M. Salvetti]

Post by Daniel Flipo

FK == Frank Küster [2005-1-27]

(if (fboundp 'debian-pkg-add-load-path-item)
(progn (debian-pkg-add-load-path-item "/usr/share/emacs21/site-lisp/auctex/")
(debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/auctex/"))
(progn (add-to-list 'load-path "/usr/share/emacs21/site-lisp/auctex/" 'append)
(add-to-list 'load-path "/usr/share/emacs/site-lisp/auctex/" 'append)))
(require 'tex-site)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

FK> I guess it could be shortened to

FK> (progn (debian-pkg-add-load-path-item "/usr/share/emacs21/site-lisp/auctex/")
FK> (debian-pkg-add-load-path-item "/usr/share/emacs/site-lisp/auctex/"))

FK> because auctex depends on emacsen-common which defines this
FK> function. Oh, it does _not_ depend directly on it, but that's a
FK> different bug. At least emacs21 depends on it, and auctex depends on
FK> emacs21, so that the function will be known every time 50auctex.el
FK> is loaded.

FK> Davide?

The fact is 'debian-pkg-add-load-path-item has not always been provided
by emacsen-common; to shorten that elisp form, I would have to have a
versioned depends on emacsen-common or emacs21. Why bother?

[Frank Küster]

Post by Davide G. M. Salvetti
FK> because auctex depends on emacsen-common which defines this
FK> function. Oh, it does _not_ depend directly on it, but that's a
FK> different bug. At least emacs21 depends on it, and auctex depends on
FK> emacs21, so that the function will be known every time 50auctex.el
FK> is loaded.
FK> Davide?
The fact is 'debian-pkg-add-load-path-item has not always been provided
by emacsen-common; to shorten that elisp form, I would have to have a
versioned depends on emacsen-common or emacs21. Why bother?

Of course you are right. It was just a misconception by me.

Regards, Frank

[Frank Küster]

Post by Frank Küster
because auctex depends on emacsen-common which defines this
function. Oh, it does _not_ depend directly on it, but that's a
different bug. [...]
Davide?

Of course it's not a bug. I was fooled by the mess in the dependencies
of emacspeak.

Excuse me, Frank