Re: Rmail: rmail-enable-mime is causing troubles
In article [EMAIL PROTECTED], Xavier Maillard [EMAIL PROTECTED] writes: Except that here, it just fails when trying to make it: [EMAIL PROTECTED] 22:37:02 rmail-mime]$ make echo ' ' lisp/autodefs.el emacs-snapshot -q --no-site-file -batch -l autoload --eval \ '(setq source-directory (expand-file-name .) \ generated-autoload-file autodefs.el)' \ -f batch-update-autoloads `find lisp -type d -print` Wrong type argument: symbolp, autodefs.el make: *** [autodefs.el] Error 255 There's also another problem for this package. I'll update a new vesion as soon as the problem of mh-acros.el advising `require' is fixed. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: thumbs doesn't show next image
Would you please try tumme and see if you like it? We may remove thumbs since tumme is intended as the replacement. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with url-retrieve when HTTP status is 304
With CVS Emacs, url-retrieve triggers an error when it gets an HTTP status of 304 *and* the requested page is not in the cache. To reproduce, try this: (setq url-request-extra-headers '((If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT) (If-None-Match . \91ad777b5809a56e2b2b9d7c4833fceb\))) (url-retrieve-synchronously http://tumbleblindly.org/feed/;) Just so I understand the problem better: where did you get info such as Sun, 18 Sep 2005 17:34:28 GMT ? From the HTTP headers of the URL in question. I fetched the headers outside of the URL library. The problem here is that it's completely separate from the cache itself. Who knows, maybe the cache was filled 10 years ago, so if the server replies with unchanged since Sun, 18 Sep 2005 17:34:28 GMT we still shouldn't use the file that's in the cache. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with url-retrieve when HTTP status is 304
Stefan Monnier [EMAIL PROTECTED] writes: With CVS Emacs, url-retrieve triggers an error when it gets an HTTP status of 304 *and* the requested page is not in the cache. To reproduce, try this: (setq url-request-extra-headers '((If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT) (If-None-Match . \91ad777b5809a56e2b2b9d7c4833fceb\))) (url-retrieve-synchronously http://tumbleblindly.org/feed/;) Just so I understand the problem better: where did you get info such as Sun, 18 Sep 2005 17:34:28 GMT ? From the HTTP headers of the URL in question. I fetched the headers outside of the URL library. It's not clear which should change--the section of url-http-parse-headers which handles 304 or url-cache-extract. One of them should check to see whether the cache file exists before trying to insert its contents. It seems neither can do anything: when we receive a 304 and there's no cache file, we simply don't have the body, so we can't complete the operation. I.e. I'm tempted to say the problem is that the (If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT) was used even though there's no cache file for it. Good point. Would you want URL to handle such a situation in a similar way to a redirect (i.e. it removes the If-Modified-Since header and tries again)? Or should it return an empty body? Good question! Perhaps all this means that any application that chooses to bypass the URL library's caching mechanism should use condition-case to handle errors in cases like this. Then again the HTTP 1.1 RFC (2616) says exactly what you said--remove the If-Modified-Since header and If-None-Match headers and retry: If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional. The RFC defines a conditional GET as: The semantics of the GET method change to a conditional GET if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client. (From: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) Here's the entire section about 304s: 10.3.5 304 Not Modified If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. The response MUST include the following header fields: - Date, unless its omission is required by section 14.18.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly. - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional. If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. (From: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: map-keymap doc not clear
1. It's not clear to me what is meant by the event and its binding. Aren't we talking here about a key sequence and its binding in KEYMAP? The event is a key (not a key sequence: just one key). Its binding is either a command or another map (if the key is a prefix key). 1. I'm only saying that the doc is unclear to me. If you think it's clear, leave it as is. Obviously, it's not clear to you, so it could use some improvement. I only explained it, in the hope that we can then come up with a better wording, once you understand it. My impression is that the doc generally speaks of, say, `C-k' as a key sequence not as an event. For most functions, we manipulate sequences of input events (i.e. key sequences) rather than single input events. In particular, a sequence of one event is always a key sequence. Right, just like a list of one element is still a list. map-keymap's function argument is called with an event as argument, not a sequence of events. 2. I still have the question about whether FUNCTION is called for each binding or each key sequence. I don't understand the question. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: map-keymap doc not clear
Obviously, it's not clear to you, so it could use some improvement. I only explained it, in the hope that we can then come up with a better wording, once you understand it. My impression is that the doc generally speaks of, say, `C-k' as a key sequence not as an event. For most functions, we manipulate sequences of input events (i.e. key sequences) rather than single input events. In particular, a sequence of one event is always a key sequence. Right, just like a list of one element is still a list. map-keymap's function argument is called with an event as argument, not a sequence of events. I understand more now, I think. If key sequence `C-x 4 f' is bound to command `find-file-other-window', then, IIUC, the events or keys here are `C-x', `4', and `k'. Is that what you mean? I guess that the bindings for these events correspond to the keymap that is the value of `ctl-x-map', the keymap that is the value of `ctl-x-4-map', and `find-file-other-window', respectively - is that the way it works? If not, then I guess I don't understand what it means for a single key or event to have a binding in KEYMAP. The doc says that FUNCTION is called on the event (not on a multi-event key sequence) and on its binding, but I guess I'm unclear as to what the binding of such an event is. 2. I still have the question about whether FUNCTION is called for each binding or each key sequence. I don't understand the question. I'm not sure what part you don't understand, or whether repeating it might help. Can you tell me what part you don't understand? The doc string uses binding to refer to the command (or the keymap etc.) that is bound to the key - that's not the same as the tuple (key . binding). I'm asking if it is correct that FUNCTION is called once for each such binding in KEYMAP. I'm guessing that this might be incorrect, that, instead, FUNCTION is called once for each bound key, not once for each command (or keymap etc.) that is bound to a key. This makes a difference in case two keys are bound to the same command (or keymap). If FUNCTION is called for each binding, not each key, then which key (event) is supplied as the arg for a binding bound to more than one key? E.g given (key1 . binding) and (key2 . binding), which is called, (FUNCTION key1 binding) or (FUNCTION key2 binding)? 2. Is FUNCTION really called once for each binding in KEYMAP, or is it called once for each key sequence in KEYMAP? If two key sequences are bound to the same command in KEYMAP, is FUNCTION called twice for that command (once for each key sequence) or once (once for the binding). If the latter, which key sequence is used as the first arg? If FUNCTION is called once for each key sequence in KEYMAP, then that's what the first line of the doc string should say. I'm hoping you understand my confusion better now. If so, maybe you can propose some language that would make the behavior clearer to someone who might be confused in the same way as I. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: thumbs doesn't show next image
Would you please try tumme and see if you like it? We may remove thumbs since tumme is intended as the replacement. Please don't remove thumbs which is simpler than tumme, and IMHO works better with small sets of images. I will get this to work if no-one else is interested. Nick ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with url-retrieve when HTTP status is 304
With CVS Emacs, url-retrieve triggers an error when it gets an HTTP status of 304 *and* the requested page is not in the cache. To reproduce, try this: (setq url-request-extra-headers '((If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT) (If-None-Match . \91ad777b5809a56e2b2b9d7c4833fceb\))) (url-retrieve-synchronously http://tumbleblindly.org/feed/;) Just so I understand the problem better: where did you get info such as Sun, 18 Sep 2005 17:34:28 GMT ? It's not clear which should change--the section of url-http-parse-headers which handles 304 or url-cache-extract. One of them should check to see whether the cache file exists before trying to insert its contents. It seems neither can do anything: when we receive a 304 and there's no cache file, we simply don't have the body, so we can't complete the operation. I.e. I'm tempted to say the problem is that the (If-Modified-Since . Sun, 18 Sep 2005 17:34:28 GMT) was used even though there's no cache file for it. Would you want URL to handle such a situation in a similar way to a redirect (i.e. it removes the If-Modified-Since header and tries again)? Or should it return an empty body? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: map-keymap doc not clear
If key sequence `C-x 4 f' is bound to command `find-file-other-window', then, IIUC, the events or keys here are `C-x', `4', and `k'. Is that what you mean? Yes. I guess that the bindings for these events correspond to the keymap that is the value of `ctl-x-map', the keymap that is the value of `ctl-x-4-map', and `find-file-other-window', respectively - is that the way it works? Yes. If you apply map-keymap to the global-map, one of the calls will pass ?C-x as the `event' and ctl-x-map as the `binding'. If you apply map-keymap to ctl-x-map, one of the calls will pass ?4 as the `event' and `ctl-x-4-map' as the binding. The doc says that FUNCTION is called on the event (not on a multi-event key sequence) and on its binding, but I guess I'm unclear as to what the binding of such an event is. I hope that clears it up a bit. 2. I still have the question about whether FUNCTION is called for each binding or each key sequence. I don't understand the question. I'm not sure what part you don't understand, or whether repeating it might help. Can you tell me what part you don't understand? Give me some examples and ask me what they should do. The doc string uses binding to refer to the command (or the keymap etc.) that is bound to the key - that's not the same as the tuple (key . binding). I'm asking if it is correct that FUNCTION is called once for each such binding in KEYMAP. Oh, I see. Yes there's an ambiguity: binding is sometimes used to refer to the pair (KEY + COMMAND) and sometimes only to COMMAND. Which is meant is normally clear from context. E.g. in the case of map-keymap, if Call FUNCTION for every binding in KEYMAP were to mean it's called once per command (or sub-keymap) in the keymap, we have a problem: since each such command can be bound to several key-sequences but the docstring says FUNCTION is called with two arguments: the event and its binding, that means that which `event' is passed is unspecified, or arbitrarily chosen. I'm guessing that this might be incorrect, that, instead, FUNCTION is called once for each bound key, not once for each command (or keymap etc.) that is bound to a key. This makes a difference in case two keys are bound to the same command (or keymap). If FUNCTION is called for each binding, not each key, then which key (event) is supplied as the arg for a binding bound to more than one key? E.g given (key1 . binding) and (key2 . binding), which is called, (FUNCTION key1 binding) or (FUNCTION key2 binding)? Exactly. Which is why it's clearly a bad interpretation of the meaning of the docstring. Of course, the docstring shouldn't need to be interpreted so carefully. I'm hoping you understand my confusion better now. If so, maybe you can propose some language that would make the behavior clearer to someone who might be confused in the same way as I. Maybe you have some suggestion? My proposition would be to just use: Call FUNCTION for every event bound in KEYMAP. FUNCTION is called with two arguments: the event and its binding. If KEYMAP has a parent, the parent's bindings are included as well. This works recursively: if the parent has itself a parent, then the grandparent's bindings are also included and so on. but it doesn't fix your confusion between key-sequences and just single keys. I'm not sure how to improve it. -- Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: map-keymap doc not clear
The doc string uses binding to refer to the command (or the keymap etc.) that is bound to the key - that's not the same as the tuple (key . binding). I'm asking if it is correct that FUNCTION is called once for each such binding in KEYMAP. Oh, I see. Yes there's an ambiguity: binding is sometimes used to refer to the pair (KEY + COMMAND) and sometimes only to COMMAND. Which is meant is normally clear from context. E.g. in the case of map-keymap, if Call FUNCTION for every binding in KEYMAP were to mean it's called once per command (or sub-keymap) in the keymap, we have a problem: since each such command can be bound to several key-sequences but the docstring says FUNCTION is called with two arguments: the event and its binding, that means that which `event' is passed is unspecified, or arbitrarily chosen. Exactly what I meant. In the first doc-string line, binding is meant to mean the pair (KEY + COMMAND). In the rest of the doc string, binding refers to the COMMAND (or keymap) that is bound to KEY. I think the first line should be changed to something like Call FUNCTION for each key bound in KEYMAP. E.g given (key1 . binding) and (key2 . binding), which is called, (FUNCTION key1 binding) or (FUNCTION key2 binding)? Exactly. Which is why it's clearly a bad interpretation of the meaning of the docstring. Of course, the docstring shouldn't need to be interpreted so carefully. There is no need to complicate things by using the two different senses of binding. It is sufficient to say that FUNCTION is called for each key (or event), because the set of bound keys maps one-to-one to the set of binding pairs (KEY + COMMAND). Maybe you have some suggestion? My proposition would be to just use: Call FUNCTION for every event bound in KEYMAP. FUNCTION is called with two arguments: the event and its binding. If KEYMAP has a parent, the parent's bindings are included as well. This works recursively: if the parent has itself a parent, then the grandparent's bindings are also included and so on. but it doesn't fix your confusion between key-sequences and just single keys. I'm not sure how to improve it. I'm not sure either. Upon rereading Elisp manual page Keymap Terminology the doc string seems pretty clear to me now (except for the first line, which I would change to Call FUNCTION for each event bound in KEYMAP). I don't think there is a good way to avoid the confusion I had, short of reminding people that a key sequence is composed of one or more events, and that although we often speak of the binding of a key sequence, it is in fact the individual events that are bound. I don't think the doc string is the place for that. I'd say don't worry about it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: autoload and auto-compression-mode
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 compression. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: autoload and auto-compression-mode
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 think that is a real bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: map-keymap doc not clear
1. It's not clear to me what is meant by the event and its binding. Aren't we talking here about a key sequence and its binding in KEYMAP? A single keymap has bindings for single events. The way a key sequence is bound is that each event leads you to another one. 2. Is FUNCTION really called once for each binding in KEYMAP, or is it called once for each key sequence in KEYMAP? Once for each binding. Does this replacement make it clear? doc: /* Call FUNCTION once for each binding in KEYMAP. FUNCTION is called with two arguments: the event that is bound, and the definition it is bound to. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: autoload and auto-compression-mode
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 currently appended. Treating those two kinds of suffixes as a separate feature is a clean way to handle this. Would you like to implement it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
special Emacs internal symbol named unbound can escape causing mayhem
In certain circumstances, the special Emacs internal symbol named unbound (not interned in the standard obarray) can be obtained as a value by ordinary Lisp code. This causes various failures, especially by Lisp code that tries to print this value. Note that at least under some circumstances, the expression (cdr (assq 'icon-top (cadadr (current-frame-configuration will return this special internal symbol. To reproduce this bug (at least this is how I encountered it): 1. Type C-x r f x (frame-configuration-to-register). This stores a value including the return value of (current-frame-configuration) in a register. 2. Type M-x desktop-save RET RET. This tries to save various aspects of Emacs's state in a file, including the value of register-alist. This fails midway through formatting the contents of the file when it tries to print the special internal symbol named unbound. Of course, the problem is that the Lisp code stores this special symbol in some variable, which is then considered to be unbound and an error is raised when the Lisp code tries to use the value of the variable. I'm using the Gentoo ebuild app-editors/emacs-22.0.50_pre20050225 which is based on a CVS snapshot from 2005-02-25. -- Joe Wells == In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.8) of 2005-08-06 on colinux Distributor `The Cygwin/X Project', version 11.0.60802000 configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--build=i686-pc-linux-gnu' '--enable-debug' '--program-suffix=.emacs-22.0.50' '--without-carbon' '--disable-nls' '--with-x' '--with-xpm' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' 'CFLAGS= -march=pentium4 -O2 -pipe' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: autoload and auto-compression-mode
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 that the set of five patches
below should take care of the problem.
Treating those two kinds of suffixes as a separate feature
is a clean way to handle this. Would you like to implement it?
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.
===File ~/lisp.h-diff===
*** lisp.h 11 Dec 2005 11:59:10 -0600 1.547
--- lisp.h 16 Jan 2006 14:28:57 -0600
***
*** 2610,2616
#define LOADHIST_ATTACH(x) \
if (initialized) Vcurrent_load_list = Fcons (x, Vcurrent_load_list)
extern Lisp_Object Vcurrent_load_list;
! extern Lisp_Object Vload_history, Vload_suffixes;
extern int openp P_ ((Lisp_Object, Lisp_Object, Lisp_Object,
Lisp_Object *, Lisp_Object));
extern int isfloat_string P_ ((char *));
--- 2610,2616
#define LOADHIST_ATTACH(x) \
if (initialized) Vcurrent_load_list = Fcons (x, Vcurrent_load_list)
extern Lisp_Object Vcurrent_load_list;
! extern Lisp_Object Vload_history, Vload_suffixes, Vdefault_suffixes;
extern int openp P_ ((Lisp_Object, Lisp_Object, Lisp_Object,
Lisp_Object *, Lisp_Object));
extern int isfloat_string P_ ((char *));
===File ~/lread-diff
*** lread.c 29 Dec 2005 23:04:56 -0600 1.346
--- lread.c 16 Jan 2006 21:34:05 -0600
***
*** 98,104
Lisp_Object Vsource_directory;
/* Search path and suffixes for files to be loaded. */
! Lisp_Object Vload_path, Vload_suffixes, default_suffixes;
/* File name of user's init file. */
Lisp_Object Vuser_init_file;
--- 98,104
Lisp_Object Vsource_directory;
/* Search path and suffixes for files to be loaded. */
! Lisp_Object Vload_path, Vload_suffixes, Vdefault_suffixes;
/* File name of user's init file. */
Lisp_Object Vuser_init_file;
***
*** 751,757
(!NILP (nosuffix) ? Qnil
: !NILP (must_suffix) ? Vload_suffixes
: Fappend (2, (tmp[0] = Vload_suffixes,
! tmp[1] = default_suffixes,
tmp))),
found, Qnil);
UNGCPRO;
--- 751,757
(!NILP (nosuffix) ? Qnil
: !NILP (must_suffix) ? Vload_suffixes
: Fappend (2, (tmp[0] = Vload_suffixes,
! tmp[1] = Vdefault_suffixes,
tmp))),
found, Qnil);
UNGCPRO;
***
*** 1105,
fn = (char *) alloca (fn_size = 100 + want_size);
/* Loop over suffixes. */
! for (tail = NILP (suffixes) ? default_suffixes : suffixes;
CONSP (tail); tail = XCDR (tail))
{
int lsuffix = SBYTES (XCAR (tail));
--- 1105,
fn = (char *) alloca (fn_size = 100 + want_size);
/* Loop over suffixes. */
! for (tail = NILP (suffixes) ? Vdefault_suffixes : suffixes;
CONSP (tail); tail = XCDR (tail))
{
int lsuffix = SBYTES (XCAR (tail));
***
*** 3901,3909
This list should not include the empty string. */);
Vload_suffixes = Fcons (build_string (.elc),
Fcons (build_string (.el), Qnil));
/* We don't use empty_string because it's not initialized yet. */
! default_suffixes = Fcons (build_string (), Qnil);
! staticpro (default_suffixes);
DEFVAR_BOOL (load-in-progress, load_in_progress,
doc: /* Non-nil iff inside of `load'. */);
--- 3901,3912
This list should not include the empty string. */);
Vload_suffixes = Fcons (build_string (.elc),
Fcons (build_string (.el), Qnil));
+ 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. */);
/* We don't use empty_string because it's not initialized yet. */
! Vdefault_suffixes = Fcons (build_string (), Qnil);
DEFVAR_BOOL (load-in-progress, load_in_progress,
doc: /* Non-nil iff inside of `load'. */);
===File ~/jka-compr-diff
*** jka-compr.el10 Nov 2005 21:26:53 -0600 1.88
--- jka-compr.el16
Re: autoload and auto-compression-mode
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 compression. I agree. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: defvaralias highlighted as a function declaration
Anyway, does the current font-lock.el do the right thing? (I don't know who is to answer he question, but) AFAIK the answer may be yes, except for highlighting of variable names declared by `defvaralias'. I'm not asking you to guess, I'm asking you to try my change. Did I fix the problem? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: thumbs doesn't show next image
thumbs.el has lots of problems, and tumme is generally better. It is very unpleasant to have two similar packages in Emacs for the same job. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: defvaralias highlighted as a function declaration
[Tue, 17 Jan 2006 00:27:55 -0500] Richard M. Stallman [EMAIL PROTECTED] writes: I'm not asking you to guess, I'm asking you to try my change. Did I fix the problem? No. May I ask you a question? Did you really have installed that change? According to `cvs log', font-lock.el was last modified on 2006-01-11 14:29:44 +, earlier than the date I reported the bug. I cannot find your change. -- Tetsuo Tsukamoto ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: thumbs doesn't show next image
thumbs.el has lots of problems, and tumme is generally better. It is very unpleasant to have two similar packages in Emacs for the same job. rmail, mh-e and gnus read mail, vc and pcl-cvs do version control, allout and outline do outlining... I don't use thumbs or tumme very much so I don't have strong feelings about it. However, if I did use one extensively, I wouldn't find the existence of the other unpleasant, I would just ignore it. Nickhttp://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
