Too much shell-escaping (was:[preview-latex-devel] rel-0-8-1; make breaks)

[Jan-Ake Larsson]

Peter Dyballa wrote:
> Today I spent some time with installing preview-latex in
> /Library/Application Support/Emacs and I found that already during make
> an error occurs:
>
> /sw/bin/emacs -batch -q -no-site-file -no-init-file --eval (setq
> load-path (cons "." load-path)) -eval (let ((dir (pop
> command-line-args-left))) (if (not (string-equal dir "")) (push dir
> load-path))) /Library/Application Support/Emacs -f batch-byte-compile
> preview.el
>
> In toplevel form:
> preview.el:57:11:Error: Cannot open load file: tex-buf
> make: *** [prv-emacs.elc] Error 1

You would get this if a vanilla Emacs can load tex-site.el but
tex-site does not contain the correct load-path to tex-buf.el(c).
tex-site sets the load-path, so this is a symptom that there is
something wrong with your AUCTeX installation.

> tex-buf.el is in
>
> pete 51 /\ ls -l /Library/Application\ Support/Emacs/auctex/tex-buf*
> -rw-r--r-- 1 pete admin 69293 23 Dez 00:16 /Library/Application
> Support/Emacs/auctex/tex-buf.el
> -rw-r--r-- 1 pete admin 58774 23 Dez 00:16 /Library/Application
> Support/Emacs/auctex/tex-buf.elc
>
> Reason might be that Makefile has as line #25:
>
> auctexdir = /Library/Application\ Support/Emacs#
>
> which is definitely wrong!

No, it is correct. tex-site.el is in that directory, is it not? The
auctexdir variable is used to give the load-path to tex-site.el for an
Emacs which is not loading any site or user init files. That is, so
that tex-site.el can be found, even with -no-site-file -no-init-file.
And it works! tex-site.el is loaded first during the compilation, and
it is found since the warning is not for tex-site.el.

But the next file to be loaded is tex-buf.el and this file is not
found, even though the load-path to that file (and all other AUCTeX
files) is set in tex-site.el. There is definetly something wrong with
the value of TeX-lisp-directory in there.

> I invoked configure in any of these two:
>
> ./configure --with-emacs=/sw/bin/emacs
> --with-lispdir=/Library/Application Support/Emacs
> ./configure --with-emacs=/sw/bin/emacs
> --with-lispdir=/Library/Application Support/Emacs
> --with-tex-site=/Library/Application Support/Emacs

You did something to it to keep the spaces, I think. A backslash or
perhaps quotes?

> tex-site.el right now can't give a correct answer because it has
> learned:
>
> (defvar TeX-lisp-directory "/Library/Application\ Support/Emacs/auctex"
> "*The directory where the AUCTeX lisp files are located.")
>
> which is later re-used as:
>
> (add-to-list 'load-path TeX-lisp-directory)
>
> Erroneously. "/Library/Application Support/Emacs/auctex" becomes
> "/Library/ApplicationSupport/Emacs/auctex" and so AUCTeX installation
> can't be found.

A-ha! There is too much shell-escaping here.

<technical mumbo-jumbo>
ISTR writing code in aclocal.m4 with _two_ variables, one to be
shell-escaped and one to be used in the lisp code. This code seems to
have gone. Either I never checked it in (but I doubt that) or
something else has happened. Perhaps this business of sync'ing AUCTeX
and prewiew-latex aclocal.m4. It is too late now (I need some sleep to
fend off this cold I got from my kids), I'll have a look some other
time.
</technical mumbo-jumbo>

> Can it be that the INSTALL file has an incorrect
> description?

No.

> Because when I configure
>
> ./configure --with-emacs=/sw/bin/emacs
> --with-lispdir=/Library/Application Support/Emacs
> --with-tex-site=/Library/Application Support/Emacs/auctex
>
> line #25 of Makefile now has:
>
> auctexdir = /Library/Application\ Support/Emacs/auctex#
>
> Which does not help either because
>
> /sw/bin/emacs -batch -q -no-site-file -no-init-file --eval (setq
> load-path (cons "." load-path)) -eval (let ((dir (pop
> command-line-args-left))) (if (not (string-equal dir "")) (push dir
> load-path))) /Library/Application Support/Emacs/auctex -f
> batch-byte-compile preview.el
>
> In toplevel form:
> preview.el:57:11:Error: Cannot open load file: tex-site
> make: *** [preview.elc] Error 1

Now you'll get the warning about tex-site not being found, as I expected.
See above.

> Maybe configure itself needs an update near line# 1737. And/Or
> Makefile/Makefile.in.

Not really. aclocal.m4 does, and tex-site.el.in (in AUCTeX). Not
configure.ac, though. Note that configure is a generated file.

> Letting GNU Emacs do its batch runs without '-no-site-file' (on ELCC)
> makes everything right.

Sure. Probably you have some customization in the site init file that
allows AUCTeX to run. Do you manually add something to load-path?

This is an AUCTeX bug report, really, no fault of preview-latex.
Cc'ing the auctex list. I'll fix it, but not today.

/JÅ

[David Kastrup]

Jan-Ake Larsson <***@mai.liu.se> writes:

>> Maybe configure itself needs an update near line# 1737. And/Or
>> Makefile/Makefile.in.
>
> Not really. aclocal.m4 does, and tex-site.el.in (in AUCTeX). Not
> configure.ac, though. Note that configure is a generated file.
>
>> Letting GNU Emacs do its batch runs without '-no-site-file' (on ELCC)
>> makes everything right.
>
> Sure. Probably you have some customization in the site init file that
> allows AUCTeX to run. Do you manually add something to load-path?
>
> This is an AUCTeX bug report, really, no fault of preview-latex.
> Cc'ing the auctex list. I'll fix it, but not today.

Too late. I changed aclocal.m4, Makefile.in, doc/Makefile.in,
configure.in. Maybe it would be more appropriate to move the changes
from aclocal.m4 over to configure.in so that the Elisp-variables are
only generated when required by configure.in. Whatever. I don't
think we have any Lisp-quotified autoconf variables in preview-latex,
though.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[David Kastrup]

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

> Jan-Ake Larsson <***@mai.liu.se> writes:
>
>> This is an AUCTeX bug report, really, no fault of preview-latex.
>> Cc'ing the auctex list. I'll fix it, but not today.
>
> Too late. I changed aclocal.m4, Makefile.in, doc/Makefile.in,
> configure.in. Maybe it would be more appropriate to move the
> changes from aclocal.m4 over to configure.in so that the
> Elisp-variables are only generated when required by configure.in.
> Whatever. I don't think we have any Lisp-quotified autoconf
> variables in preview-latex, though.

And the changes have another advantage: they make tex-site.el.in
illegal Lisp. So maybe we'll get fewer reports that after some forth
and back end in "well, I copied tex-site.el.in to tex-site.el since I
don't want to install make. Why wouldn't this work?".

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Jan-Ake Larsson]

David Kastrup wrote:
> David Kastrup <***@gnu.org> writes:
> Too late.

Good, thanks.

> And the changes have another advantage: they make tex-site.el.in
> illegal Lisp. So maybe we'll get fewer reports that after some forth
> and back end in "well, I copied tex-site.el.in to tex-site.el since I
> don't want to install make. Why wouldn't this work?".

Enlighten me: what would be the danger of using something like

(defvar TeX-lisp-directory (expand-file-name
"auctex"
(file-name-directory (locate-library
"tex-site")))
"*The directory where most of the AUCTeX lisp files are located.
tex-site.el (wherein this variable is defined) resides in its
parent directory. For the location of lisp files associated with
styles, see the variables TeX-style-* (hand-generated lisp) and
TeX-auto-* (automatically generated lisp).")

We want as much automated things inside the lisp code as possible,
anyway.

/JÅ


--
The box said "Windows 95, Windows NT 4.0, or better", so I installed Linux.

[Jan-Ake Larsson]

Jan-Ake Larsson wrote:
> (defvar TeX-lisp-directory (expand-file-name
> "auctex"
> (file-name-directory (locate-library
> "tex-site")))
> "*The directory where most of the AUCTeX lisp files are located.
> tex-site.el (wherein this variable is defined) resides in its
> parent directory. For the location of lisp files associated with
> styles, see the variables TeX-style-* (hand-generated lisp) and
> TeX-auto-* (automatically generated lisp).")

Perhaps some other auctex is in load-path than the one for which we
are loading tex-site.el. Would the following work?

(defvar TeX-lisp-directory (expand-file-name
"auctex"
(file-name-directory load-file-name))
"*The directory where most of the AUCTeX lisp files are located.
tex-site.el (wherein this variable is defined) resides in its
parent directory. For the location of lisp files associated with
styles, see the variables TeX-style-* (hand-generated lisp) and
TeX-auto-* (automatically generated lisp).")

There must be *some* way to do this.
/JÅ


--
SIGSIG -- signature too long (core dumped)

[Jan-Ake Larsson]

Jan-Ake Larsson wrote:
> Perhaps some other auctex is in load-path than the one for which we
> are loading tex-site.el. Would the following work?
>
> (defvar TeX-lisp-directory (expand-file-name
> "auctex"
> (file-name-directory load-file-name))
> "*The directory where most of the AUCTeX lisp files are located.
> tex-site.el (wherein this variable is defined) resides in its
> parent directory. For the location of lisp files associated with
> styles, see the variables TeX-style-* (hand-generated lisp) and
> TeX-auto-* (automatically generated lisp).")

After some simple testing here, it seems to work. Are there problems
with using this, anyone?

/JÅ


--
Unix, MS-DOS, and Windows NT
(also known as the Good, the Bad, and the Ugly).

[David Kastrup]

Jan-Ake Larsson <***@mai.liu.se> writes:

> Jan-Ake Larsson wrote:
>> Perhaps some other auctex is in load-path than the one for which we
>> are loading tex-site.el. Would the following work?
>>
>> (defvar TeX-lisp-directory (expand-file-name
>> "auctex"
>> (file-name-directory load-file-name))
>> "*The directory where most of the AUCTeX lisp files are located.
>> tex-site.el (wherein this variable is defined) resides in its
>> parent directory. For the location of lisp files associated with
>> styles, see the variables TeX-style-* (hand-generated lisp) and
>> TeX-auto-* (automatically generated lisp).")
>
> After some simple testing here, it seems to work. Are there problems
> with using this, anyone?

Yes. tex-site.el is placed in an arbitrary startup directory,
probably a directory intended for automatic installation. auctex is
not necessarily below it.

But it would be fine with me if we have a default of

lispauctexdir='(expand-file-name "auctex" (file-name-directory load-file-name))))'

in our configure.in that only gets overriden when an _explicit_
--with-auctexdir is specified on the command line, so that
configure.in has the defaults

lispauctexdir='(expand-file-name "auctex" (file-name-directory load-file-name))))'
auctexdir='${lispdir}/auctex'

but an explicit -with-auctexdir will override _both_ using the current
mechanism.

This would mean that startup files (tex-site.el and preview-latex.el)
get installed in lispdir, and the bulk of the stuff gets installed in
auctexdir & previewdir, which default to '${lispdir}/auctex' and
'${lispdir}/preview' with auto-detection code relative to the
installation as you suggested, but which can be overriden on the
command line of configure, in which case the autodetection gets
replaced by the lisp-quoted explicit path.

That should cater for most things. The XEmacs package system could
probably not be catered for just with ./configure options, but since
we have an explicit --with-packagedir option, this could also change
the lispauctexdir and auctex variable _defaults_ to something
appropriate pseudo-relative.

Package systems like RedHat and Debian install into fixed paths, so
the explicit --with-auctexdir generating an absolute path will always
be fine.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Jan-Ake Larsson]

David Kastrup wrote:
> Jan-Ake Larsson <***@mai.liu.se> writes:
>
> > Jan-Ake Larsson wrote:
> >> Perhaps some other auctex is in load-path than the one for which we
> >> are loading tex-site.el. Would the following work?
> >>
> >> (defvar TeX-lisp-directory (expand-file-name
> >> "auctex"
> >> (file-name-directory load-file-name))
> >> "*The directory where most of the AUCTeX lisp files are located.
> >> tex-site.el (wherein this variable is defined) resides in its
> >> parent directory. For the location of lisp files associated with
> >> styles, see the variables TeX-style-* (hand-generated lisp) and
> >> TeX-auto-* (automatically generated lisp).")
> >
> > After some simple testing here, it seems to work. Are there problems
> > with using this, anyone?
>
> Yes. tex-site.el is placed in an arbitrary startup directory,
> probably a directory intended for automatic installation. auctex is
> not necessarily below it.
>
> But it would be fine with me if we have a default of
>
> lispauctexdir='(expand-file-name "auctex" (file-name-directory load-file-name))))'
>
> in our configure.in that only gets overriden when an _explicit_
> --with-auctexdir is specified on the command line, so that
> configure.in has the defaults

There is no such switch in AUCTeX. You are probably confusing this
with preview-latex, where -with-tex-site exists only to help that
configure find AUCTeX.

As far as I can see, tex-site.el is installed in $lispdir and
$auctexdir is _hardcoded_ as $lispdir/auctex.

/JÅ


--
"I hope to die before I _have_ to use Microsoft Word."
Donald E. Knuth

[David Kastrup]

Jan-Ake Larsson <***@mai.liu.se> writes:

> David Kastrup wrote:
>> Jan-Ake Larsson <***@mai.liu.se> writes:
>>
>> > Jan-Ake Larsson wrote:
>> >> Perhaps some other auctex is in load-path than the one for which we
>> >> are loading tex-site.el. Would the following work?
>> >>
>> >> (defvar TeX-lisp-directory (expand-file-name
>> >> "auctex"
>> >> (file-name-directory load-file-name))
>> >> "*The directory where most of the AUCTeX lisp files are located.
>> >> tex-site.el (wherein this variable is defined) resides in its
>> >> parent directory. For the location of lisp files associated with
>> >> styles, see the variables TeX-style-* (hand-generated lisp) and
>> >> TeX-auto-* (automatically generated lisp).")
>> >
>> > After some simple testing here, it seems to work. Are there problems
>> > with using this, anyone?
>>
>> Yes. tex-site.el is placed in an arbitrary startup directory,
>> probably a directory intended for automatic installation. auctex
>> is not necessarily below it.
>>
>> But it would be fine with me if we have a default of
>>
>> lispauctexdir='(expand-file-name "auctex" (file-name-directory load-file-name))))'
>>
>> in our configure.in that only gets overriden when an _explicit_
>> --with-auctexdir is specified on the command line, so that
>> configure.in has the defaults
>
> There is no such switch in AUCTeX. You are probably confusing this
> with preview-latex, where -with-tex-site exists only to help that
> configure find AUCTeX.

I was talking about how things should be, not how they are.

> As far as I can see, tex-site.el is installed in $lispdir and
> $auctexdir is _hardcoded_ as $lispdir/auctex.

Yes, that is the current state of affairs. After having outlined the
approach to be taken, I think I might be able to code the respective
stuff into the configuration folderol of both packages.

At least a first shot.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Jan-Ake Larsson]

David Kastrup wrote:
>>> in our configure.in that only gets overriden when an _explicit_
>>> --with-auctexdir is specified on the command line, so that
>>> configure.in has the defaults
>>
>> There is no such switch in AUCTeX. You are probably confusing this
>> with preview-latex, where -with-tex-site exists only to help that
>> configure find AUCTeX.
>
> I was talking about how things should be, not how they are.

What is the reason for the change? (Just weighing the added complexity
against the benefits of having tex-site.el in one directory and
auctex/ in another?)

/JÅ


--
++?????++ Out of Cheese Error. Please Redo From Start.

[David Kastrup]

Jan-Ake Larsson <***@mai.liu.se> writes:

> David Kastrup wrote:
>>>> in our configure.in that only gets overriden when an _explicit_
>>>> --with-auctexdir is specified on the command line, so that
>>>> configure.in has the defaults
>>>
>>> There is no such switch in AUCTeX. You are probably confusing this
>>> with preview-latex, where -with-tex-site exists only to help that
>>> configure find AUCTeX.
>>
>> I was talking about how things should be, not how they are.
>
> What is the reason for the change? (Just weighing the added complexity
> against the benefits of having tex-site.el in one directory and
> auctex/ in another?)

That we can accommodate package systems _and_ install in sensible
startup directory. Putting the bulk of our AUCTeX files into

site-packages/auctex/lisp/auctex/

seems pretty absurd, for example. At the current point of time,
preview-latex does not even dare making a guess where to install
preview-latex.el: that is a long-standing wart of our installation
process: that "make install" is not the last thing you need to do to
have every file placed where one can start working.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Jan-Ake Larsson]

David Kastrup wrote:
> That we can accommodate package systems _and_ install in sensible
> startup directory.

Very good. This is just a suggestion:

--with-lispdir=DIR Where to install lisp files, note that most
of AUCTeX will be installed in a subdirectory


Could become:
--with-lispdir=DIR Where to install the bulk of AUCTeX files,
preferably a subdirectory of some directory
in load-path.
--with-initfiledir=DIR Where your package init files go.


--with-auctexdir seems like a strange name to me.
/JÅ


--
We are MicroSoft. You will be assimilated. Resistance is futile.

[David Kastrup]

Jan-Ake Larsson <***@mai.liu.se> writes:

> David Kastrup wrote:
>> That we can accommodate package systems _and_ install in sensible
>> startup directory.
>
> Very good. This is just a suggestion:
>
> --with-lispdir=DIR Where to install lisp files, note that most
> of AUCTeX will be installed in a subdirectory
>
> Could become:
> --with-lispdir=DIR Where to install the bulk of AUCTeX files,
> preferably a subdirectory of some directory
> in load-path.

Leave off the "preferably". If you specify it, the initfile will know
where to find it.

> --with-initfiledir=DIR Where your package init files go.
>
>
> --with-auctexdir seems like a strange name to me.

Definitely. However, we have in automake

AM_PATH_LISPDIR
Searches for the program emacs, and, if found, sets the output
variable lispdir to the full path to Emacs' site-lisp directory.

Note that this test assumes the emacs found to be a version that
supports Emacs Lisp (such as GNU Emacs or XEmacs). Other emacsen
can cause this test to hang (some, like old versions of
MicroEmacs, start up in interactive mode, requiring `C-x C-c' to
exit, which is hardly obvious for a non-emacs user). In most
cases, however, you should be able to use `C-c' to kill the
test. In order to avoid problems, you can set EMACS to "no" in the
environment, or use the `--with-lispdir' option to configure to
explictly set the correct path (if you're sure you have an emacs
that supports Emacs Lisp.


So there already _is_ a convention that lispdir is a location in
load-path, one intended for top-level code. And that would be our
initialization files usually.

So we should follow this convention. So it would appear to look
consistent, we need the following:

a) lispdir is autodetected unless overridden with --with-lispdir
b) startup file is placed into ${lispdir}/tex-site.el unless
overridden with --with-packagedir or
--with-texsite=/path/and/filename.el

No wait. We have tex-mik.el and fptex.el to install into the same
place. Rats, things could have been so easy. So probably just
--with-texsitedir=...

c) the bulk of AUCTeX is placed into lispdir/auctex unless overridden
with --with-auctexdir=...

The same scheme would go for preview-latex, more or less.

The option names are still up for grabs, but lispdir is taken, and
since it is supposed to be possible to run a bunch of configure
scripts for different packages with the same options, the installation
places unique to AUCTeX and preview-latex should also have
corresponding unique options. Other possibilities are auclispdir and
auctexlispdir.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Uwe Brauer]

>>>>> "David" == David Kastrup <***@gnu.org> writes:

David> Leave off the "preferably". If you specify it, the
David> initfile will know where to find it.

>> --with-initfiledir=DIR Where your package init files go.
>>
>>
>> --with-auctexdir seems like a strange name to me.

David> Definitely. However, we have in automake



David> So there already _is_ a convention that lispdir is a
David> location in load-path, one intended for top-level code.
David> And that would be our initialization files usually.

David> So we should follow this convention. So it would appear to
David> look consistent, we need the following:

David> a) lispdir is autodetected unless overridden with
David> --with-lispdir
David> b) startup file is placed into ${lispdir}/tex-site.el unless
David> overridden with --with-packagedir or
David> --with-texsite=/path/and/filename.el
guys since you are now discussing the installation targets could you
please change the (default) behaviour of packagedir, whose behaviour
is wrong, as I wrote in an earlier message.


Uwe

[David Kastrup]

Uwe Brauer <***@mat.ucm.es> writes:

>>>>>> "David" == David Kastrup <***@gnu.org> writes:
>
> David> Leave off the "preferably". If you specify it, the
> David> initfile will know where to find it.
>
> >> --with-initfiledir=DIR Where your package init files go.
> >>
> >>
> >> --with-auctexdir seems like a strange name to me.
>
> David> Definitely. However, we have in automake
>
>
>
> David> So there already _is_ a convention that lispdir is a
> David> location in load-path, one intended for top-level code.
> David> And that would be our initialization files usually.
>
> David> So we should follow this convention. So it would appear to
> David> look consistent, we need the following:
>
> David> a) lispdir is autodetected unless overridden with
> David> --with-lispdir
> David> b) startup file is placed into ${lispdir}/tex-site.el unless
> David> overridden with --with-packagedir or
> David> --with-texsite=/path/and/filename.el
> guys since you are now discussing the installation targets could you
> please change the (default) behaviour of packagedir, whose behaviour
> is wrong, as I wrote in an earlier message.

Please be more specific. I have now checked _all_ of your mails in
the recent 1000 articles in this list, and the only one appearing
remotely relevant would be
Message-ID: <***@mat.ucm.es>
where you, however, play around with --with-lispdir and people point
out in the followups that you seem to have ignored the instructions
and are installing from within the XEmacs lisp tree. No further reply
was made by you and the thread petered out soon.

So please repost the relevant article or at least its Message Id or
restate the problem. There are millions of ways to change the default
behavior of packagedir, and it is pretty hard to guess for at best
occasional XEmacs users which of those you would call wrong.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Uwe Brauer]

>>>>> "David" == David Kastrup <***@gnu.org> writes:

David> Uwe Brauer <***@mat.ucm.es> writes:

[snip]

>> guys since you are now discussing the installation targets could you
>> please change the (default) behaviour of packagedir, whose behaviour
>> is wrong, as I wrote in an earlier message.

David> Please be more specific. I have now checked _all_ of your mails in
David> the recent 1000 articles in this list, and the only one appearing
David> remotely relevant would be
David> Message-ID: <***@mat.ucm.es>
David> where you, however, play around with --with-lispdir and people point
David> out in the followups that you seem to have ignored the instructions
David> and are installing from within the XEmacs lisp tree. No further reply
David> was made by you and the thread petered out soon.

No, I mean <***@mat.ucm.es>
this is from Monday 7 of feb.


Here is want I said.

--8<------------------------schnipp------------------------->8---

Hello

This is an issue which concerns both the auctex developement team and
the xemacs team, hence my double posting.

The default behaviour for a auctex installation using xemacs
that is
./configure --with-xemacs=/usr/bin/xemacs

has the result, that the files, which are generated by the make
process, will be installed in


infodir = ${packagedir}/info
lispdir = ${packagedir}/lisp
packagedir = /usr/share/xemacs21/xemacs-packages
auctexdir= ${lispdir}/auctex


I consider such a choice as *bad*.
First it will need root privileges, second it will install in the
directory where the _official_ xemacs pkg sits.

So I suggest that the default value are:

either the pkg directory is
packagedir = /usr/share/xemacs21/site-packages

Which still would need root privileges or the value
is
packagedir = ~/.xemacs/xemacs-packages.


It is true that the INSTALLATION file says something about how to set
the packagedir, that is to run
./configure --with-xemacs=/usr/bin/xemacs --with-packagedir=/DIR
but in any case, the *default* behaviour should not be the one mention
above.

I suggest if
./configure --with-xemacs=/usr/bin/xemacs
is executed, a message pops up saying,

"you did not specify neither the packagedir nor the lispdir option".


Besides the package generated this way *does not* include a MANIFEST
file, so uninstall could be a little tricky, recall that the xemacs
are installed according to the structure
/lisp/packagename
/man/packagename

But not

/packename/lisp
/packename/man

In the letter deleting the packagename directory would delete the
installed files, in the former you have to go directory by
directory. So that is where a MANIFEST file comes in handy (posted a
while ago I simple function to delete the content of a 3rd party
package by reading the MANIFEST file)


I would appreciate any comments of the Xemacs development team on this
issue.

Thanks


Uwe Brauer


--8<------------------------schnapp------------------------->8---

[Uwe Brauer]

>>>>> "David" == David Kastrup <***@gnu.org> writes:

David> So please repost the relevant article or at least its
David> Message Id or restate the problem. There are millions of
David> ways to change the default behavior of packagedir, and it

I am not sure what you mean, but packages have to either in

$prefix/xemacs-packages
or
$prefix/site-packages
or
~/.xemacs/xemacs-packages

David> is pretty hard to guess for at best occasional XEmacs users
David> which of those you would call wrong.

That's why I try to point this out.


Uwe