Juri Linkov wrote:
I think `file representation suffix' is an unclear term. There are such
file representations are text, image, unibyte, literal, hex dump, etc.
And using this term in the context of `load' is very confusing.
The purpose of this variable can be mistakenly interpreted
There are three lists, one of Elisp suffixes, one of file representation
suffixes and one which is a computed combination of both.
There is no reason to talk about the third list. That is an internal
implementation detail.
Maybe in the same way as `image-file-name-extensions' is
Date: Fri, 24 Feb 2006 21:58:53 -0600 (CST)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
Anyway, I plan to use the following expanded docstrings of
`load-suffixes' and `load-file-rep-suffixes'. (As I already
mentioned, once the Elisp manual is
There are three lists, one of Elisp suffixes, one of file representation
suffixes and one which is a computed combination of both.
I think `file representation suffix' is an unclear term. There are such
file representations are text, image, unibyte, literal, hex dump, etc.
And using this term
Date: Tue, 21 Feb 2006 22:14:44 -0600 (CST)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org,
[EMAIL PROTECTED]
Eli Zaretskii wrote:
First, what happened to indentation here? The extra spaces are funny.
I just kept the indentation
Eli Zaretskii wrote:
First, what happened to indentation here? The extra spaces are funny.
I just kept the indentation style that was already present (it is also
used in several other docstrings).
Second, there's a spurious period at the end of the last sentence.
I removed that one.
Since other people showed interest in this I CC my new patch to
lread.c which I already sent in (mistakenly) private email to Richard
to emacs-pretest-bug. The changes to the previous patch are mostly in
the docstrings. I substantialy shortened the docstrings of
`load-suffixes' and the still to
From my previous message:
expanded name `load-file-representation-suffixes' for the present
file-rep-suffixes.
I meant: for the present `load-file-rep-suffixes'.
Sincerely,
Luc.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Date: Mon, 20 Feb 2006 23:28:22 -0600 (CST)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org,
[EMAIL PROTECTED]
I substantialy shortened the docstrings of `load-suffixes' and the
still to be renamed `load-file-rep-suffixes'
Too much, I think.
I can install the patches if desired. Once they are installed, I would
also update various docstrings and loading.texi.
The doc strings of load-suffixes and load-file-rep-suffixes left me
confused as to what each of the two lists does.
I want to note also that the name
The following 11 patches implement the new behavior of `load-suffixes'
we agreed on, fixing some reported bugs. They make setting
load-suffixes take effect immediately without any need to call any
updating functions.
I can install the patches if desired. Once they are installed, I would
also
I think what Richard is getting at, is that load-suffixes should be what you
call basic-load-suffixes and what you think of as load-suffixes should be
recomputed on-the-fly when needed.
Yes. That is cleaner.
As for me, I think that even in such a case, load-suffixes should not
Richard Stallman wrote:
Why does it have to change both? Wouldn't it be clearer
to have just one variable that records the list of
compression suffixes? `load' could check it directly.
There are, in current Emacs CVS, 7 places in Lisp and 2 in C which use
load-suffixes. So we are not
No, after my patches, Auto Compression mode changes _both_
`load-suffixes' and `load-file-rep-suffixes'.
Why does it have to change both? Wouldn't it be clearer
to have just one variable that records the list of
compression suffixes? `load' could check it directly.
If we want to
The distinction we are going to make here is between suffixes
that are part of different file names, and suffixes that are
for different ways of representing the same file.
So I suggest the name load-file-rep-suffixes, with an explanation to
match.
The only reliable way
to change load-suffixes for an ordinary user is to customize the
(defcustomed) variable `jka-compr-load-suffixes'.
Isn't Auto Compression mode going to change the new variable,
`load-nosuffix-suffixes' or `load-file-rep-suffixes', instead of
changing
Richard Stallman wrote:
Isn't Auto Compression mode going to change the new variable,
`load-nosuffix-suffixes' or `load-file-rep-suffixes', instead of
changing `load-suffixes'?
No, after my patches, Auto Compression mode changes _both_
`load-suffixes' and `load-file-rep-suffixes'. The
The five patches below do that. They export `default_suffixes' to
Lisp and have jka-compr-* use it.
I can install if desired. If the patches look OK, I will also update
lispref/loading.texi.
It looks good except for the fact that `default-suffixes' is too general
a name for this variable
+ DEFVAR_LISP (default-suffixes, Vdefault_suffixes,
+ doc: /* Additional list of suffixes to try for files to load.
+ Loading tries these after `load-suffixes' if a suffix in `load-suffixes'
+ is not required. Normally includes the empty string. */);
Is that really
Stefan Monnier wrote:
It looks good except for the fact that `default-suffixes' is too general
a name for this variable (it was OK in the context of the C code, but in
the context of elisp it should include `load' somewhere in the name to make
it clear that it refers to suffixes used
The docstring of load-suffixes starts with a `*'. According to what
we decided, we should either get rid of that `*' or make a defcustom
out of it. Given the way that Auto Compression mode plays around with
load-suffixes, it is not easy for ordinary users to customize it
reliably (with or
The docstring of load-suffixes starts with a `*'. According to what
we decided, we should either get rid of that `*' or make a defcustom
out of it. Given the way that Auto Compression mode plays around with
load-suffixes, it is not easy for ordinary users to customize it
reliably (with or
There is the question of whether, assuming that auto-compression-mode
is enabled, trying to load foo with a non-nil NOSUFFIX arg should
find foo.gz. I believe that it should, since NOSUFFIX seems to
apply to suffixes indicating a Lisp file (as MUST-SUFFIX does) and not
to extensions used for
What does this imply in the context of compressed files? I started
this thread because the latest CVS emacs loads via autoload a
compressed file `foo.gz'.
I don't think autoload with name foo should load foo.gz. foo.gz is
a compressed version of foo, and it would not load foo.
So I
No, you do not need an exclude list here. There is an include list,
`load-suffixes'. The problem is simple: .gz is in there, whereas it
should not be. .gz should be handled specially in the same way as
the empty suffix , by appending '( .gz) to load-suffixes,
wherever '() is
Richard Stallman wrote:
I don't think autoload with name foo should load foo.gz. foo.gz is
a compressed version of foo, and it would not load foo.
So I think that is a real bug.
My previous attempt at fixing it was _way_ to hasty (I should have
grepped more carefully), but I believe
There is the question of whether, assuming that auto-compression-mode
is enabled, trying to load foo with a non-nil NOSUFFIX arg should
find foo.gz. I believe that it should, since NOSUFFIX seems to
apply to suffixes indicating a Lisp file (as MUST-SUFFIX does) and not
to
Why does autoload use `must-suffix'? No clue. Anyone?
ISTR it was to avoid undesirable results of loading a non-Lisp file.
`load' MUST allow non-use of a suffix, so you can specify the precise
file name you mean. If you say (load foo) expecting it to load the
file `foo.el', but it loads
On Sun Jan 15 2006 Richard M. Stallman wrote:
Why does autoload use `must-suffix'? No clue. Anyone?
ISTR it was to avoid undesirable results of loading a non-Lisp file.
`load' MUST allow non-use of a suffix, so you can specify the precise
file name you mean. If you say (load foo)
Roland Winkler wrote:
What does this imply in the context of compressed files? I started
this thread because the latest CVS emacs loads via autoload a
compressed file `foo.gz'. I think this behavior is as undesirable as
loading a file `foo' via autoload.
Of course.
Is the arg
From my previous reply:
.gz should be handled specially in the same way as
the empty suffix , by appending '( .gz) to load-suffixes,
wherever '() is currently appended.
Actually, one should append both '() and the list jka-compr-load-suffixes.
I believe that your problem can be solved
I think that the following triple of patches should solve your problem
by removing .gz from load-suffixes. Loading will find foo.gz only
if it would find foo and nosuffix is nil. I can install and make the
necessary accompanying doc changes, if desired.
Sincerely,
Luc.
===File
Stefan Monnier wrote:
Hmm... there's something odd in your patches: they only affect
locate-library, not `load' and not `require', so they won't find foo.gz.
OK, I jumped into this too quickly and did some bad grepping. At the
risk of reacting too quickly again, is there any reason not
You are right -- but it seems we have indeed one more inconsistency.
Modify your example as follows:
% echo '(defun foo () (message foo1))' ~/tmp/foo1/foo
% echo '(defun foo () (message foo2))' ~/tmp/foo2/foo.el
M-: (let ((load-path (append '(~/tmp/foo1 ~/tmp/foo2) load-path)))
Date: Mon, 09 Jan 2006 23:49:57 +0100
From: Roland Winkler [EMAIL PROTECTED]
The CVS emacs I installed today gives me a bug with autoload and
auto-compression-mode that can be reproduced as follows:
cat ~/foo/foo.el EOF
(defun foo () (interactive) (message Hello world.))
EOF
echo
On Fri Jan 13 2006 Eli Zaretskii wrote:
This is not a bug, it's an intended behavior (or maybe an unintended
misfeature of intended behavior ;-). Since ~/bar is before ~/foo in
your load-path, Emacs sees ~/bar/foo.gz first. And because
auto-compression-mode is now on by default, the fact
- Older versions of CVS emacs (built a couple of months ago) do not
try to load ~/bar/foo.gz (even if ~/foo/foo.el doesn't exist at
all).
Yes, we fixed a bug. The bug was that when auto-compression-mode was
enabled, (load foo) would find foo.el.gz but (load foo.el) wouldn't.
- Even my
- If ~/bar is in the load-path before ~/foo and we have files
~/bar/foo and ~/foo/foo.el, then emacs loads ~/foo/foo.el.
Really?
I've just tried it here with:
% echo '(message foo1)' ~/tmp/foo1/foo
% echo '(message foo2)' ~/tmp/foo2/foo.el
M-: (let ((load-path (list* ~/tmp/foo1
On Fri Jan 13 2006 Stefan Monnier wrote:
- If ~/bar is in the load-path before ~/foo and we have files
~/bar/foo and ~/foo/foo.el, then emacs loads ~/foo/foo.el.
Really?
I've just tried it here with:
% echo '(message foo1)' ~/tmp/foo1/foo
% echo '(message foo2)'
39 matches
Mail list logo
