Re: patch for locate.el when called with prefix arg
Miles Bader wrote; The old code didn't have an arg argument, so there's no argument compatibility to maintain -- and indeed that argues for introducing reasonable arguments now. For backward compatibility and for other reasons, the new arg _needs_ to be optional. That means that a nil arg _must_ mean to just respect the value of `locate-prompt-for-command', so there is at least some compatibility to maintain. On top of that, it seems natural to have one value of ARG that allows the caller to just pass on its prefix arg. In as far as adding two additional values to just force one behavior or the other, regardless of `locate-prompt-for-command', to give a potential caller an additional way to that, rather than passing no arg and binding ``locate-prompt-for-command' around the call, I do not see the urgency to do that before the release. In as far as the behavior of `C-x ESC ESC' is concerned, I do not immediately see why the behavior you describe is better, nor why it is that hugely important, nor why it would have to be taken care of before the release, if at all. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
I suggest the following small changes to the Changelog (mainly for the benefit of people who might want to find out when the optional arg for locate was introduced), as well as the adding of an additional comment to locate.el, to make clear that the use of `current-prefix-arg' in `locate-prompt-for-search-string' is legitimate. These changes are so trivial that I thought of just committing them, but I am unsure about the exact procedure, given the pretest, which is why I post them. ===File ~/changelog-diff *** ChangeLog 23 Apr 2007 11:17:11 -0500 1.11042 --- ChangeLog 23 Apr 2007 11:46:01 -0500 *** *** 8,16 2007-04-23 Luc Teirlinck [EMAIL PROTECTED] * locate.el (locate-local-prompt): New var. (locate-prompt-for-search-string): New function. ! (locate): Make locate-local-prompt buffer-local. Use ! locate-prompt-for-search-string. (locate-with-filter): New optional arg. Use locate-prompt-for-search-string. (locate-update): Bind locate-prompt-for-command. --- 8,17 2007-04-23 Luc Teirlinck [EMAIL PROTECTED] * locate.el (locate-local-prompt): New var. + (locate-prompt-for-command): Doc fix. (locate-prompt-for-search-string): New function. ! (locate): New optional arg. Make locate-local-prompt ! buffer-local. Use locate-prompt-for-search-string. (locate-with-filter): New optional arg. Use locate-prompt-for-search-string. (locate-update): Bind locate-prompt-for-command. ===File ~/locate-diff=== *** locate.el 23 Apr 2007 11:17:12 -0500 1.43 --- locate.el 23 Apr 2007 11:40:14 -0500 *** *** 245,250 --- 245,251 (skip-chars-backward . pt) (point) + ;; Function for use in interactive declarations. (defun locate-prompt-for-search-string () (if (or (and current-prefix-arg (not locate-prompt-for-command)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Richard Stallman wrote: I think BOTH of these functions should pass the arg along. Then behavior will be unchanged. After the release we could document this feature and then get any bugs fixed. `locate-with-filter' now passes the arg along, all bugs and misfeatures I was referring to have been fixed and I believe the doc is clear too. So for this function things are completely solved. In as far as `locate-in-alternate-database' is concerned, I can not test this function since it only works for GNU locate and I have slocate installed. Since the docstring does not mention a prefix arg, I am not even sure that this function can handle one at all. So the currently committed patch does not pass the arg along. IF somebody would be able to check that the following patch works OK in the four combinatorial cases (prefix arg vs no prefix arg, `locate-prompt-for-command' nil vs t), one could commit the patch below. Even so, updating with `g' would probably not work correctly in the resulting buffer, because it would use the wrong database. Since I can not check anything and it is not a regression, I will not try to fix this. Patch IF somebody can check it as specified above and ONLY in that case (DANGER otherwise. Without anybody checking it, I would rather leave things exactly as they are now. I do not believe that this is a widely used command.): ===File ~/locate-diff-new=== *** locate.el 23 Apr 2007 11:17:12 -0500 1.43 --- locate.el 23 Apr 2007 12:16:53 -0500 *** *** 245,250 --- 245,251 (skip-chars-backward . pt) (point) + ;; Function for use in interactive declarations. (defun locate-prompt-for-search-string () (if (or (and current-prefix-arg (not locate-prompt-for-command)) *** *** 667,682 file)) ;; Only for GNU locate ! (defun locate-in-alternate-database (search-string database) Run the GNU locate command, using an alternate database. (interactive ! (list !(progn !;; (require 'locate) !(read-from-minibuffer Locate: nil nil ! nil 'locate-history-list)) !(read-file-name Locate using Database: ) !)) (or (file-exists-p database) (error Database file %s does not exist database)) (let ((locate-make-command-line --- 668,680 file)) ;; Only for GNU locate ! (defun locate-in-alternate-database (search-string database arg) Run the GNU locate command, using an alternate database. (interactive !(list ! (locate-prompt-for-search-string) ! (read-file-name Locate using Database: ) ! current-prefix-arg)) (or (file-exists-p database) (error Database file %s does not exist database)) (let ((locate-make-command-line *** *** 685,691 (list (concat --database= (expand-file-name database)) string)) ! (locate search-string))) (defun locate-do-redisplay (optional arg test-for-subdir) Like `dired-do-redisplay', but adapted for `*Locate*' buffers. --- 683,689 (list (concat --database= (expand-file-name database)) string)) ! (locate search-string nil arg))) (defun locate-do-redisplay (optional arg test-for-subdir) Like `dired-do-redisplay', but adapted for `*Locate*' buffers. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
If somebody else would install the `locate-in-alternate-database' patch (AFTER carefully testing it), please be careful not to add the line: + ;; Function for use in interactive declarations. twice, since I also included that in a previously proposed (but not yet installed) trivial and riskless patch. (Sorry, had to resend this message for address error.) Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
It may be feasible to fix org. Fixing calc is probably a big job and has to wait. From grepping, I have the impression that there are plenty of other places that have similar problems. The docstring of `current-prefix-arg' does not contain any usage instructions and `(elisp)Prefix Command Arguments' is unclear, in the two places were it mentions the variable: Normally, commands specify which representation to use for the prefix argument, either numeric or raw, in the `interactive' specification. (*Note Using Interactive::.) Alternatively, functions may look at the value of the prefix argument directly in the variable `current-prefix-arg', but this is less clean. and: -- Variable: current-prefix-arg This variable holds the raw prefix argument for the _current_ command. Commands may examine it directly, but the usual method for accessing it is with `(interactive P)'. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous message: In as far as `locate-in-alternate-database' is concerned, I can not test this function since it only works for GNU locate and I have slocate installed. Since the docstring does not mention a prefix arg, I am not even sure that this function can handle one at all. So the currently committed patch does not pass the arg along. IF somebody would be able to check that the following patch works OK in the four combinatorial cases (prefix arg vs no prefix arg, `locate-prompt-for-command' nil vs t), one could commit the patch below Thinking more about this, I now believe that a numeric arg to this function makes little sense, even assuming that it _would_ work OK, nor does using this function at all with `locate-prompt-for-command' set to t make much sense. This function is nothing more than an interface for specifying the `d' option. If you want to specify the exact command line given to locate, then you can quite as well specify the `-d' option right then. This is actually more convenient than specifying the database at a separate prompt. Moreover, if you specify the `-d' option explicitly, `g' will work correctly, whereas if you use `locate-in-alternate-database', it probably will not. So I do not believe that there is any need to test the patch for `locate-in-alternate-database' which I proposed. I believe that it is better to just forget about that patch. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
_None_ of this is important enough to do before the release. The changes fixed several annying bugs and Richard asked explicitly for my patch to be committed. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
With something scheduled for tomorrow, I can not wait for Richard's response, since Richard asked to do this ASAP, which I interpret as meaning before the next pretest, that is now. A choice between three alternatives has to be made (see below), so I will wait some time for input. Richard Stallman wrote: Is the way the `locate' command uses `current-prefix-arg', outside an interactive declaration and without checking that `locate' itself was called interactively, actually legitimate? That is indeed a bug. All use of `current-prefix-arg' should be in the interactive spec. Would some please fix it ASAP? I plan to fix it by giving the locate command an extra arg and storing the value of `current-prefix-arg' in it in the interactive declaration for use in the body of the function. Other commands can then use that arg to pass their own interactive arg on to the locate command if they wish to do so. Now we have to make a decision for `locate-with-filter' and `locate-in-alternate-database'. These two commands currently pass their interactive arg on to locate, which is undocumented and probably unintentional, but could nevertheless be considered a feature. Now there are three things we could do. We could do something now and something else after the release, if appropriate. The three choices are: no longer pass the arg on, pass the arg on and leave it undocumented, sticking with the current state of affairs (no visible difference to the user), pass on and properly document. Problem with the last two: I do not know how well tested the unintentional feature is. I plan to also commit my previously mentioned bug fixes, since they are way less invasive than the new change, fix annoying and confusing bugs and I tested them extensively. They are an obvious complement to already committed changes. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous reply: The three choices are: no longer pass the arg on, pass the arg on and leave it undocumented, sticking with the current state of affairs (no visible difference to the user), pass on and properly document. Well, properly document would be more than just changing the doc strings, it would involve changing the prompts too. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous message: The three choices are: no longer pass the arg on, pass the arg on and leave it undocumented, sticking with the current state of affairs (no visible difference to the user), pass on and properly document. Problem with the last two: I do not know how well tested the unintentional feature is. In the absence of suggestions, I opted for the first possibility, since it involves the fewest changes. This leaves some misfeatures if `locate-prompt-for-command' is t (this is not the default value). Below is my suggested patch. It includes the bugfix patch I suggested earlier, but did not commit. I do not know the procedures to follow in this pretest stage. Do I commit or let Chong commit it? ===File ~/locate-diff-5= *** locate.el 21 Apr 2007 00:00:52 -0500 1.42 --- locate.el 22 Apr 2007 14:05:55 -0500 *** *** 117,122 --- 117,123 (defvar locate-current-filter nil) (defvar locate-local-filter nil) (defvar locate-local-search nil) + (defvar locate-local-prompt nil) (defgroup locate nil Interface to the locate command. *** *** 221,227 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. :group 'locate :type 'boolean) --- 222,231 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. ! ! Setting this option non-nil actually inverts the meaning of a prefix arg; ! that is, with a prefix arg, you get the default behavior. :group 'locate :type 'boolean) *** *** 242,248 (point) ;;;###autoload ! (defun locate (search-string optional filter) Run the program `locate', putting results in `*Locate*' buffer. Pass it SEARCH-STRING as argument. Interactively, prompt for SEARCH-STRING. With prefix arg, prompt for the exact shell command to run instead. --- 246,252 (point) ;;;###autoload ! (defun locate (search-string optional filter arg) Run the program `locate', putting results in `*Locate*' buffer. Pass it SEARCH-STRING as argument. Interactively, prompt for SEARCH-STRING. With prefix arg, prompt for the exact shell command to run instead. *** *** 259,265 the variables `locate-command' or `locate-make-command-line'. The main use of FILTER is to implement `locate-with-filter'. See ! the docstring of that function for its meaning. (interactive (list (if (or (and current-prefix-arg --- 263,271 the variables `locate-command' or `locate-make-command-line'. The main use of FILTER is to implement `locate-with-filter'. See ! the docstring of that function for its meaning. ! ! ARG is the interactive prefix arg. (interactive (list (if (or (and current-prefix-arg *** *** 282,296 nil nil nil 'locate-history-list default t))) (and (equal input ) default (setq input default)) ! input (if (equal search-string ) (error Please specify a filename to search for)) (let* ((locate-cmd-list (funcall locate-make-command-line search-string)) (locate-cmd (car locate-cmd-list)) (locate-cmd-args (cdr locate-cmd-list)) (run-locate-command ! (or (and current-prefix-arg (not locate-prompt-for-command)) ! (and (not current-prefix-arg) locate-prompt-for-command))) ) ;; Find the Locate buffer --- 288,305 nil nil nil 'locate-history-list default t))) (and (equal input ) default (setq input default)) ! input)) !nil !current-prefix-arg)) ! (if (equal search-string ) (error Please specify a filename to search for)) (let* ((locate-cmd-list (funcall locate-make-command-line search-string)) (locate-cmd (car locate-cmd-list)) (locate-cmd-args (cdr locate-cmd-list)) (run-locate-command ! (or (and arg (not locate-prompt-for-command)) ! (and (not arg) locate-prompt-for-command))) ) ;; Find the Locate buffer *** *** 304,309 --- 313,319 (setq locate-current-filter filter) (set (make-local-variable 'locate-local-search) search-string) (set (make-local-variable 'locate-local-filter) filter) + (set (make-local-variable 'locate-local-prompt) run-locate-command) (if run-locate-command (shell-command search-string locate-buffer-name) *** *** 584,590 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in
Re: patch for locate.el when called with prefix arg
That is indeed a bug. All use of `current-prefix-arg' should be in the interactive spec. There seem to be many places in the Lisp code that violate this. For instance, both Calc and org mode seem to violate this systematically. In as far as org is concerned, the docstring of `org-execute-file-search-functions' contains the following cryptic remark: Each function can access the current prefix argument through the variable `current-prefix-argument'. Note that a single prefix is used to force opening a link in Emacs, so it may be good to only use a numeric or double prefix to guide the search function. The _only_ mention of the variable `current-prefix-argument' in the entire source code is in that docstring. I would guess that `current-prefix-arg' is what is meant. I do not use org and hence can not look further into this. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous message: Below is my suggested patch. It includes the bugfix patch I suggested earlier, but did not commit. I do not know the procedures to follow in this pretest stage. Do I commit or let Chong commit it? In the latter case, please wait just a little bit. I probably will soon submit a better patch (although my previous one had no real bugs). Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
I should say that although my latest patch looks more extensive than my previous version, this really is largely an optical illusion. I feel that my later version is much more solid. I tested prompting in all eight combinatorial possibilities (locate vs locate-with-filter, C-u vs no C-u, locate-prompt-for-command nil vs t) and checked that not only the prompting was correct in all eight cases, but that the `g' command worked correctly in all eight cases as well. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
New patch identical to the last one, except for a trivial one-line docstring change in `locate-with-filter': ARG is the interactive prefix arg. gets replaced by: ARG is the interactive prefix arg, which has the same effect as in `locate'. ===File ~/locate-diff-8= *** locate.el 21 Apr 2007 00:00:52 -0500 1.42 --- locate.el 22 Apr 2007 23:04:26 -0500 *** *** 117,122 --- 117,123 (defvar locate-current-filter nil) (defvar locate-local-filter nil) (defvar locate-local-search nil) + (defvar locate-local-prompt nil) (defgroup locate nil Interface to the locate command. *** *** 221,227 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. :group 'locate :type 'boolean) --- 222,231 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. ! ! Setting this option non-nil actually inverts the meaning of a prefix arg; ! that is, with a prefix arg, you get the default behavior. :group 'locate :type 'boolean) *** *** 241,248 (skip-chars-backward . pt) (point) ;;;###autoload ! (defun locate (search-string optional filter) Run the program `locate', putting results in `*Locate*' buffer. Pass it SEARCH-STRING as argument. Interactively, prompt for SEARCH-STRING. With prefix arg, prompt for the exact shell command to run instead. --- 245,275 (skip-chars-backward . pt) (point) + (defun locate-prompt-for-search-string () + (if (or (and current-prefix-arg + (not locate-prompt-for-command)) + (and (not current-prefix-arg) locate-prompt-for-command)) + (let ((locate-cmd (funcall locate-make-command-line ))) + (read-from-minibuffer +Run locate (like this): +(cons + (concat (car locate-cmd) + (mapconcat 'identity (cdr locate-cmd) )) + (+ 2 (length (car locate-cmd +nil nil 'locate-history-list)) + (let* ((default (locate-word-at-point)) + (input + (read-from-minibuffer +(if ( (length default) 0) +(format Locate (default %s): default) + (format Locate: )) +nil nil nil 'locate-history-list default t))) + (and (equal input ) default + (setq input default)) + input))) + ;;;###autoload ! (defun locate (search-string optional filter arg) Run the program `locate', putting results in `*Locate*' buffer. Pass it SEARCH-STRING as argument. Interactively, prompt for SEARCH-STRING. With prefix arg, prompt for the exact shell command to run instead. *** *** 259,296 the variables `locate-command' or `locate-make-command-line'. The main use of FILTER is to implement `locate-with-filter'. See ! the docstring of that function for its meaning. (interactive ! (list !(if (or (and current-prefix-arg ! (not locate-prompt-for-command)) ! (and (not current-prefix-arg) locate-prompt-for-command)) ! (let ((locate-cmd (funcall locate-make-command-line ))) !(read-from-minibuffer ! Run locate (like this): ! (cons ! (concat (car locate-cmd) ! (mapconcat 'identity (cdr locate-cmd) )) ! (+ 2 (length (car locate-cmd ! nil nil 'locate-history-list)) !(let* ((default (locate-word-at-point)) ! (input ! (read-from-minibuffer !(if ( (length default) 0) !(format Locate (default %s): default) ! (format Locate: )) !nil nil nil 'locate-history-list default t))) ! (and (equal input ) default ! (setq input default)) ! input (if (equal search-string ) (error Please specify a filename to search for)) (let* ((locate-cmd-list (funcall locate-make-command-line search-string)) (locate-cmd (car locate-cmd-list)) (locate-cmd-args (cdr locate-cmd-list)) (run-locate-command ! (or (and current-prefix-arg (not locate-prompt-for-command)) ! (and (not current-prefix-arg) locate-prompt-for-command))) ) ;; Find the Locate buffer --- 286,308 the variables `locate-command' or `locate-make-command-line'. The main use of FILTER is to implement `locate-with-filter'. See ! the docstring of that function for its meaning. ! ! ARG is the interactive prefix arg. (interactive !(list ! (locate-prompt-for-search-string) ! nil ! current-prefix-arg)) ! (if
Re: patch for locate.el when called with prefix arg
Compared to previous, just re-adds an accidentally deleted line of whitespace: ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Compared to previous, just re-adds an accidentally deleted line of whitespace, which of course would only make a difference if somebody else would commit it. (Previous message without diff sent by mistake). ===File ~/locate-diff-9= *** locate.el 21 Apr 2007 00:00:52 -0500 1.42 --- locate.el 22 Apr 2007 23:25:23 -0500 *** *** 117,122 --- 117,123 (defvar locate-current-filter nil) (defvar locate-local-filter nil) (defvar locate-local-search nil) + (defvar locate-local-prompt nil) (defgroup locate nil Interface to the locate command. *** *** 221,227 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. :group 'locate :type 'boolean) --- 222,231 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. ! ! Setting this option non-nil actually inverts the meaning of a prefix arg; ! that is, with a prefix arg, you get the default behavior. :group 'locate :type 'boolean) *** *** 241,248 (skip-chars-backward . pt) (point) ;;;###autoload ! (defun locate (search-string optional filter) Run the program `locate', putting results in `*Locate*' buffer. Pass it SEARCH-STRING as argument. Interactively, prompt for SEARCH-STRING. With prefix arg, prompt for the exact shell command to run instead. --- 245,275 (skip-chars-backward . pt) (point) + (defun locate-prompt-for-search-string () + (if (or (and current-prefix-arg + (not locate-prompt-for-command)) + (and (not current-prefix-arg) locate-prompt-for-command)) + (let ((locate-cmd (funcall locate-make-command-line ))) + (read-from-minibuffer +Run locate (like this): +(cons + (concat (car locate-cmd) + (mapconcat 'identity (cdr locate-cmd) )) + (+ 2 (length (car locate-cmd +nil nil 'locate-history-list)) + (let* ((default (locate-word-at-point)) + (input + (read-from-minibuffer +(if ( (length default) 0) +(format Locate (default %s): default) + (format Locate: )) +nil nil nil 'locate-history-list default t))) + (and (equal input ) default + (setq input default)) + input))) + ;;;###autoload ! (defun locate (search-string optional filter arg) Run the program `locate', putting results in `*Locate*' buffer. Pass it SEARCH-STRING as argument. Interactively, prompt for SEARCH-STRING. With prefix arg, prompt for the exact shell command to run instead. *** *** 259,296 the variables `locate-command' or `locate-make-command-line'. The main use of FILTER is to implement `locate-with-filter'. See ! the docstring of that function for its meaning. (interactive ! (list !(if (or (and current-prefix-arg ! (not locate-prompt-for-command)) ! (and (not current-prefix-arg) locate-prompt-for-command)) ! (let ((locate-cmd (funcall locate-make-command-line ))) !(read-from-minibuffer ! Run locate (like this): ! (cons ! (concat (car locate-cmd) ! (mapconcat 'identity (cdr locate-cmd) )) ! (+ 2 (length (car locate-cmd ! nil nil 'locate-history-list)) !(let* ((default (locate-word-at-point)) ! (input ! (read-from-minibuffer !(if ( (length default) 0) !(format Locate (default %s): default) ! (format Locate: )) !nil nil nil 'locate-history-list default t))) ! (and (equal input ) default ! (setq input default)) ! input (if (equal search-string ) (error Please specify a filename to search for)) (let* ((locate-cmd-list (funcall locate-make-command-line search-string)) (locate-cmd (car locate-cmd-list)) (locate-cmd-args (cdr locate-cmd-list)) (run-locate-command ! (or (and current-prefix-arg (not locate-prompt-for-command)) ! (and (not current-prefix-arg) locate-prompt-for-command))) ) ;; Find the Locate buffer --- 286,308 the variables `locate-command' or `locate-make-command-line'. The main use of FILTER is to implement `locate-with-filter'. See ! the docstring of that function for its meaning. ! ! ARG is the interactive prefix arg. (interactive !(list ! (locate-prompt-for-search-string) ! nil ! current-prefix-arg)) ! (if (equal search-string ) (error Please specify a filename to
Re: patch for locate.el when called with prefix arg
Miles Bader wrote: Why are you putting the prefix inverts sense of locate-prompt-for-command logic into the main function body, and not in the (interactive ...) code? I believe that was already the case before my patch is it not? It would seem more understandable and useful for non-interactive users if you just added a prompt-for-command argument to the locate function and put all the grot involving locate-prompt-for-command into the interactive code. IOW, (1) add a prompt-for-command argument to locate, (2) use that arg everywhere in the function body where locate-prompt-for-command used to be used, (3) implement the arg toggles global var stuff in the (interactive ...) code (e.g., (not (eq (not arg) (not locate-prompt-for-command. [I think anytime you find yourself using a function argument called arg with funny semantics intended solely for convenient keyboard use, it's a hint that maybe you should rethink the function interface.] I was trying to keep changes as minimal as possible while still fixing all bugs and misfeature. I thought Chong was about to cut a final pretest Monday (depending on the place where you live, that may mean today), so I was hurrying. I do not believe that any of the programming interface objections you were introduced by the patch I proposed, or ..,? Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous reply: I do not believe that any of the programming interface objections you were introduced by the patch I proposed, or ..,? Meant was of course: I do not believe that any of the programming interface objections you mentioned were introduced by the patch I proposed, or ..,? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
(1) revert-buffer does not work in *Locate* buffers that result from C-u locate RET or C-u locate-with-filter RET. We have not generally implemented reverting for search command output. Locate implements a revert-buffer-function, locate-update. The reported bug can be annoying and confusing to the user. The following patch fixes the reported bug, as well as a related bug when locate-prompt-for-command is t, as well as a related bug with `C-u g' in locate buffers, and provides a doc fix for locate-prompt-for-command: ===File ~/locate-diff-4= *** locate.el 21 Apr 2007 00:00:52 -0500 1.42 --- locate.el 21 Apr 2007 14:27:15 -0500 *** *** 117,122 --- 117,123 (defvar locate-current-filter nil) (defvar locate-local-filter nil) (defvar locate-local-search nil) + (defvar locate-local-prompt nil) (defgroup locate nil Interface to the locate command. *** *** 221,227 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. :group 'locate :type 'boolean) --- 222,231 (defcustom locate-prompt-for-command nil If non-nil, the `locate' command prompts for a command to run. ! Otherwise, that behavior is invoked via a prefix argument. ! ! Setting this option non-nil actually inverts the meaning of a prefix arg; ! that is, with a prefix arg, you get the default behavior. :group 'locate :type 'boolean) *** *** 304,309 --- 308,314 (setq locate-current-filter filter) (set (make-local-variable 'locate-local-search) search-string) (set (make-local-variable 'locate-local-filter) filter) + (set (make-local-variable 'locate-local-prompt) run-locate-command) (if run-locate-command (shell-command search-string locate-buffer-name) *** *** 584,590 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'. ! (let ((locate-buffer-name (buffer-name))) (and locate-update-when-revert (yes-or-no-p Update locate database (may take a few seconds)? ) ;; `expand-file-name' is used in order to autoload Tramp if --- 589,597 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'. ! (let ((locate-buffer-name (buffer-name)) ! (locate-prompt-for-command locate-local-prompt) ! (current-prefix-arg nil)) (and locate-update-when-revert (yes-or-no-p Update locate database (may take a few seconds)? ) ;; `expand-file-name' is used in order to autoload Tramp if ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Richard Stallman wrote: (2) While C-u locate RET gives the prompt Run locate (like this): , locate-with-filter gives the same prompt, Locate: , regardless of whether or not a prefix arg is used. The behaviour of C-u locate-with-filter is analogous to C-u locate (due to the value current-prefix-arg), but the use of a prefix arg is not documented for locate-with-filter. (All of this is also true for Emacs 21.) That's not serious. And apparently the feature is non-intentional. `locate-in-alternate-database' has a similar undocumented (and probably non-intentional) feature. Is the way the `locate' command uses `current-prefix-arg', outside an interactive declaration and without checking that `locate' itself was called interactively, actually legitimate? It means that any function that calls locate, and uses itself the prefix arg with unrelated meaning, has to bind `current-prefix-arg' to nil around the call to `locate', otherwise a bug results. (This is actually part of what my previous patch does for `locate-update', which was necessary, because otherwise `C-u g' produces a bug.) This does not seem very clean to me. In the case of `locate-with-filter' and `locate-in-alternate-database' the result could actually be considered a feature rather than a bug. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
(1) revert-buffer does not work in *Locate* buffers that result from C-u locate RET or C-u locate-with-filter RET. Note that, without my very latest suggested patch, you _can_ actually correctly revert such buffers using `C-u g'. Obviously, this is not a very clean feature. (But it is fun.) Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Francesco Potorti` [EMAIL PROTECTED] wrote: A bug was apparently introduced in locate.el, but I did not check when and why. That was not the only bug introduced by the following change: 2006-09-09 Matt Hodges [EMAIL PROTECTED] * locate.el (locate-current-search): New variable. (locate): Set buffer local value. Use current buffer if it is in Locate mode. (locate-mode): Disable undo here. (locate-do-setup): Use locate-current-filter from buffer to be killed. (locate-update): Use locate-current-search and locate-current-filter. Undo no longer works in a locate buffer. This is a serious bug and a regression in Emacs 22 if it does not get fixed. You are supposed to be able to do essentially everything you can do in a dired buffer (including undo) in a locate buffer. That is the very purpose of locate-mode. From the above changelog entry, this bug seems to have been introduced _on purpose_. What was the purpose of the above changes? They seem to have been made by somebody who does not understand how other people use locate mode and only cares about the way he personally uses it. Who knows what else these changes broke. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
And here is yet another regressive bug introduced by that change: I do `M-x locate RET autorevert', then `M-x rename-uniquely' to start conducting a second locate search (the routine recommended way to start a new search while keeping the results of the previous one) and then do `M-x locate RET ielm'. My autorevert results now get overwritten. in spite of the `M-x rename-uniquely'. This is yet another regressive bug. I believe that _instead_ of applying your patch, the apparently misguided 2006-09-09 changes should be completely reverted (before releasing Emacs 22), getting rid of all three _regressive_ bugs we know about, as well as of those we do not know about yet that were introduced by that change. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous message: I believe that _instead_ of applying your patch, the apparently misguided 2006-09-09 changes should be completely reverted (before releasing Emacs 22), getting rid of all three _regressive_ bugs we know about, as well as of those we do not know about yet that were introduced by that change. I know see that these changes were made to address the following problems: Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. These problems can, and should, obviously be addressed in locate-update, without affecting other stuff. Anyway, the problems described above are not regressions and could be fixed properly after the release (or before, but that would imply a delay), whereas the problems introduced by their fix are regressions, at least two of which are currently not fixed. (And looking at the code, I strongly suspect that these two bugs are not the only ones.) Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
From my previous message: Undo no longer works in a locate buffer. This is a serious bug and a regression in Emacs 22 if it does not get fixed. To explain the seriousness: I often perform work in locate buffers. For instance, I often clean up the buffer by manually marking and killing search results that were irrelevant. If I kill a line by mistake (which happens, I am absent-minded), it is important to be able to get that line back by undo. Getting it back by a new search looses all my previous work. Actually, to me `undo' is _more_ important in locate buffers than in regular Dired buffers. This also shows why the second bug is serious too: after the overwrite, I can conduct the original search over again, but I loose all my work in the process. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
After studying the patch that introduced this, it seems to me that the one line (buffer-disable-undo) in locate.el:472 was sneaked in without further justification. As was other stuff that causes bugs too. Luc, could you test if removing this line solves your problem? Also, could you see if the original problem addressed by this patch, i.e. It solves one of the two bugs I reported but not the other. It leaves very strange looking code in locate.el, which I suspect to have other problems than the ones we yet know about. Also, could you see if the original problem addressed by this patch, i.e. Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. remains solved after removing that line? What I did test was that reverting the changes in revisions 1.38 and 1.40 (the one from today) and then applying the patch below, not only solves the three bugs reported today, but also solves the three problems described in the above paragraph. The first two, I checked. The third one I could not actually check, because I do not use eshell, but it _should_ be fixed, as my patch eliminates dependence from these history lists. Note that my patch below only changes six lines (4 trivial and 2 very simple) compared to 1.37, whereas 1.38 changes 40 lines in a complex way. All problems which 1.38 tried to solve concerned only the function locate-update. My patch affects only that function. Rev 1.38 affected all of locate, causing various bugs. Patch to be applied _after_ reverting revisions 1.37 and 1.40: ===File ~/locate-diff-2= *** locate.el 20 Apr 2007 18:51:04 -0500 1.37 --- locate.el 20 Apr 2007 20:37:21 -0500 *** *** 115,120 --- 115,122 ;; Variables (defvar locate-current-filter nil) + (defvar locate-local-filter nil) + (defvar locate-local-search nil) (defgroup locate nil Interface to the locate command. *** *** 300,305 --- 302,309 (erase-buffer) (setq locate-current-filter filter) + (set (make-local-variable 'locate-local-search) search-string) + (set (make-local-variable 'locate-local-filter) filter) (if run-locate-command (shell-command search-string locate-buffer-name) *** *** 580,586 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'. ! (let ((str (car locate-history-list))) (and locate-update-when-revert (yes-or-no-p Update locate database (may take a few seconds)? ) ;; `expand-file-name' is used in order to autoload Tramp if --- 584,590 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'. ! (let ((locate-buffer-name (buffer-name))) (and locate-update-when-revert (yes-or-no-p Update locate database (may take a few seconds)? ) ;; `expand-file-name' is used in order to autoload Tramp if *** *** 588,594 ;; is remote. (let ((default-directory (expand-file-name locate-update-path))) (shell-command locate-update-command))) ! (locate str))) ;;; Modified three functions from `dired.el': ;;; dired-find-directory, --- 592,598 ;; is remote. (let ((default-directory (expand-file-name locate-update-path))) (shell-command locate-update-command))) ! (locate locate-local-search locate-local-filter))) ;;; Modified three functions from `dired.el': ;;; dired-find-directory, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
As a complement to my previous message, here is a diff showing _all_ changes since 1.37 _after_ applying the two reversions and my patch, to show that all revisions in between are unrelated: ===File ~/locate-diff-1= *** locate.el 20 Apr 2007 18:51:04 -0500 1.37 --- locate.el 20 Apr 2007 20:10:42 -0500 *** *** 1,7 ;;; locate.el --- interface to the locate command ;; Copyright (C) 1996, 1998, 2001, 2002, 2003, 2004, ! ;; 2005, 2006 Free Software Foundation, Inc. ;; Author: Peter Breton [EMAIL PROTECTED] ;; Keywords: unix files --- 1,7 ;;; locate.el --- interface to the locate command ;; Copyright (C) 1996, 1998, 2001, 2002, 2003, 2004, ! ;; 2005, 2006, 2007 Free Software Foundation, Inc. ;; Author: Peter Breton [EMAIL PROTECTED] ;; Keywords: unix files *** *** 115,120 --- 115,122 ;; Variables (defvar locate-current-filter nil) + (defvar locate-local-filter nil) + (defvar locate-local-search nil) (defgroup locate nil Interface to the locate command. *** *** 300,305 --- 302,309 (erase-buffer) (setq locate-current-filter filter) + (set (make-local-variable 'locate-local-search) search-string) + (set (make-local-variable 'locate-local-filter) filter) (if run-locate-command (shell-command search-string locate-buffer-name) *** *** 422,428 (save-excursion (forward-line 0) (looking-at (concat . ! (make-string (1- locate-filename-indentation) ?\ ) \\(/\\|[A-Za-z]:\\) (defun locate-mouse-view-file (event) --- 426,432 (save-excursion (forward-line 0) (looking-at (concat . ! (make-string (1- locate-filename-indentation) ?\s) \\(/\\|[A-Za-z]:\\) (defun locate-mouse-view-file (event) *** *** 469,475 ;; This should support both Unix and Windoze style names (setq directory-listing-before-filename-regexp (concat ^. ! (make-string (1- locate-filename-indentation) ?\ ) \\(/\\|[A-Za-z]:\\)\\| (default-value 'directory-listing-before-filename-regexp))) (make-local-variable 'dired-actual-switches) --- 473,479 ;; This should support both Unix and Windoze style names (setq directory-listing-before-filename-regexp (concat ^. ! (make-string (1- locate-filename-indentation) ?\s) \\(/\\|[A-Za-z]:\\)\\| (default-value 'directory-listing-before-filename-regexp))) (make-local-variable 'dired-actual-switches) *** *** 477,483 (make-local-variable 'dired-permission-flags-regexp) (setq dired-permission-flags-regexp (concat ^.\\( ! (make-string (1- locate-filename-indentation) ?\ ) \\)\\| (default-value 'dired-permission-flags-regexp))) (make-local-variable 'revert-buffer-function) --- 481,487 (make-local-variable 'dired-permission-flags-regexp) (setq dired-permission-flags-regexp (concat ^.\\( ! (make-string (1- locate-filename-indentation) ?\s) \\)\\| (default-value 'dired-permission-flags-regexp))) (make-local-variable 'revert-buffer-function) *** *** 501,507 (locate-insert-header search-string) (while (not (eobp)) ! (insert-char ?\ locate-filename-indentation t) (locate-set-properties) (forward-line 1))) (goto-char (point-min))) --- 505,511 (locate-insert-header search-string) (while (not (eobp)) ! (insert-char ?\s locate-filename-indentation t) (locate-set-properties) (forward-line 1))) (goto-char (point-min))) *** *** 580,586 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'. ! (let ((str (car locate-history-list))) (and locate-update-when-revert (yes-or-no-p Update locate database (may take a few seconds)? ) ;; `expand-file-name' is used in order to autoload Tramp if --- 584,590 Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'. ! (let ((locate-buffer-name (buffer-name))) (and locate-update-when-revert (yes-or-no-p Update locate database (may take a few seconds)? ) ;; `expand-file-name' is used in order to autoload Tramp if *** *** 588,594 ;; is remote. (let ((default-directory (expand-file-name locate-update-path))) (shell-command locate-update-command))) ! (locate str))) ;;; Modified three
Re: patch for locate.el when called with prefix arg
From my previous message: What I did test was that reverting the changes in revisions 1.38 and 1.40 (the one from today) Meant was: 1.41 (the one from today) All references to 1.40 in my replies actuaaly referred to 1.41 Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible memory problem and crashes on cygwin
emacs user wrote: I'll take your word for that, I hardly know what GC is... I did not follow this thread and I do not know whether this has already been pointed out to you, but you can force a garbage collection using M-: (garbage-collect) If by any chance you then see `nil' in the echo area, we know what the problem is (pure space overflow). Actually, you can do `M-x garbage-collect' to force garbage collection, but then you do not see the return value in the echo area. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrapping error (autoloads error 255)
Dieter Wilhelm wrote: just updated my emacs directory from CVS, typed: make bootstrap and got the following messages: I can not reproduce this. Does the error still occur if you do: make maintainer-clean ./configure before `make bootstrap'? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp Manual: New Symbols node
Nick Roberts wrote: Assuming that I've built the manual properly, why can't they work like the previous Index (generated by findex, vindex etc?) and send the user directly to the relevant line? They still do for me. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp Manual: New Symbols node
Wait, now I believe I understand. If you have the line: * constrain-to-field:Fields. (line 70) Then clicking (or pressing RET) on `* constrain-to-field:' immediately gets you to line 70, but pressing RET on `Fields.' carries you to the beginning of the node. Clicking mouse-2 on `Fields.' does nothing for me. It does not follow any link. Is this the same as what you see? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp Manual: New Symbols node
Nick Roberts wrote: Assuming that I've built the manual properly, why can't they work like the previous Index (generated by findex, vindex etc?) and send the user directly to the relevant line? I do not see any difference in behavior between the various indices. The behavior I described in my previous response seems to apply to all indices. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x occur and `[^a-z]$'
Mark Plaskin wrote: Put this in the *scatch* buffer: a1 b c1 d e1 f g1 h i1 j k1 l m1 n Go to the top of the buffer and type M-x occur RET [^a-z]$ RET You'll get this: 8 matches for [^a-z]$ in buffer: *scratch* 1:a1 3:c1 5:e1 7:g1 9:i1 11:k1 13:m1 14:n But line 14 doesn't match the regexp, does it? I assume that you have a newline after the n, followed by a completely empty line. Then line 14 _does_ match. You have a newline, which matches [^a-z], followed by an end of line. Elisp regexps behave differently in this respect from grep regexps. From `(elisp)Regexp Special': A complemented character alternative can match a newline, unless newline is mentioned as one of the characters not to match. This is in contrast to the handling of regexps in programs such as `grep'. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Bill Wohler wrote: OK, it's back. Here's the message: Buffer `*desktop*' undo info is 3159101 bytes long; discard it? (yes or no) The patch below should solve your problem, or part of your problem. There is no reason for the `*desktop*' buffer to accumulate a huge undo entry just to allow you to erase the buffer completely using `M-x undo'. So the patch below disables undo while desktop.el writes all these entries in the *desktop* buffer. After that, undo is re-enabled however. So if you then inadvertently mess up the buffer, repeated undo will restore the buffer to what desktop.el wrote in it. But one more undo will not erase the buffer. Instead, it will tell you that there is no further undo info. I said that it might solve part of your problem. The question is whether the 3M of undo is legitimate. Take a look at what is in that buffer. Does the huge size of the buffer seem legitimate, because there really is that much info to save? I guess that you know that you can produce the buffer using `M-x desktop-save'. I believe that my patch should be applied regardless of whether the 3M is legitimate, but if it is not, additional changes may be necessary. ===File ~/desktop.el-diff=== *** desktop.el 10 Feb 2006 08:34:46 -0600 1.99 --- desktop.el 11 May 2006 20:42:50 -0500 *** *** 766,804 (eager desktop-restore-eager) (buf (get-buffer-create *desktop*))) (set-buffer buf) ! (erase-buffer) ! (insert ! ;; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n ! desktop-header ! ;; Created (current-time-string) \n ! ;; Desktop file format version desktop-file-version \n ! ;; Emacs version emacs-version \n\n ! ;; Global section:\n) ! (mapc (function desktop-outvar) desktop-globals-to-save) ! (if (memq 'kill-ring desktop-globals-to-save) ! (insert ! (setq kill-ring-yank-pointer (nthcdr ! (int-to-string (- (length kill-ring) (length kill-ring-yank-pointer))) !kill-ring))\n)) ! (insert \n;; Buffer section -- buffers listed in same order as in buffer list:\n) ! (mapc #'(lambda (l) ! (when (apply 'desktop-save-buffer-p l) ! (insert ( ! (if (or (not (integerp eager)) ! (unless (zerop eager) ! (setq eager (1- eager)) ! t)) ! desktop-create-buffer ! desktop-append-buffer-args) ! ! desktop-file-version) ! (mapc #'(lambda (e) ! (insert \n (desktop-value-to-string e))) ! l) ! (insert )\n\n))) ! info) (setq default-directory dirname) (let ((coding-system-for-write 'emacs-mule)) (write-region (point-min) (point-max) filename nil 'nomessage --- 766,807 (eager desktop-restore-eager) (buf (get-buffer-create *desktop*))) (set-buffer buf) ! (when (consp buffer-undo-list) ! (setq buffer-undo-list nil)) ! (let ((buffer-undo-list t)) ! (erase-buffer) ! (insert !;; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n !desktop-header !;; Created (current-time-string) \n !;; Desktop file format version desktop-file-version \n !;; Emacs version emacs-version \n\n !;; Global section:\n) ! (mapc (function desktop-outvar) desktop-globals-to-save) ! (if (memq 'kill-ring desktop-globals-to-save) ! (insert !(setq kill-ring-yank-pointer (nthcdr !(int-to-string (- (length kill-ring) (length kill-ring-yank-pointer))) ! kill-ring))\n)) ! (insert \n;; Buffer section -- buffers listed in same order as in buffer list:\n) ! (mapc #'(lambda (l) ! (when (apply 'desktop-save-buffer-p l) ! (insert ( ! (if (or (not (integerp eager)) ! (unless (zerop eager) ! (setq eager (1- eager)) ! t)) ! desktop-create-buffer ! desktop-append-buffer-args) ! ! desktop-file-version) ! (mapc #'(lambda (e) ! (insert \n (desktop-value-to-string e))) ! l) ! (insert )\n\n))) ! info)) (setq default-directory dirname) (let ((coding-system-for-write 'emacs-mule)) (write-region (point-min) (point-max) filename nil 'nomessage
Re: Big desktop undo buffer crashes Emacs
From my previous reply: I said that it might solve part of your problem. The question is whether the 3M of undo is legitimate. Take a look at what is in that buffer. Does the huge size of the buffer seem legitimate, because there really is that much info to save? I guess that you know that you can produce the buffer using `M-x desktop-save'. Well, the size of the undo info is not necessarily related to the size of the buffer. In my setup, after `M-x desktop-save', I get a *desktop* buffer of size 2943, but my buffer-undo-list (_without_ my patch applied) is very small: (nil (1 . 2944) (t 0 . 0)) I guess that if you created the *desktop* buffer and did `C-h v buffer-undo-list' in it, you would get a really huge *Help* buffer, assuming it would not make your Emacs crash. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
I believe that we can forget about that potential second undo problem. It is apparently when you do `M-x desktop-save' while you already have a *desktop* buffer that you can accumulate a large undo entry proportional to the size of the buffer. This seems to happen as a result of the call to `erase-buffer'. But after my patch, recording of undo info during the call to `erase-buffer' is disabled anyway. So the problem should be completely solved. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
I mangled Bill's email address in my previous reply, re-included below. So if you follow up, please follow up on this version rather than the original to prevent CC-ing a mangled address: I believe that we can forget about that potential second undo problem. It is apparently when you do `M-x desktop-save' while you already have a *desktop* buffer that you can accumulate a large undo entry proportional to the size of the buffer. This seems to happen as a result of the call to `erase-buffer'. But after my patch, recording of undo info during the call to `erase-buffer' is disabled anyway. So the problem should be completely solved. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Stefan Monnier wrote: ! (when (consp buffer-undo-list) ! (setq buffer-undo-list nil)) ! (let ((buffer-undo-list t)) ! (erase-buffer) Why not just (buffer-disable-undo) ?? Because I want to allow people who visit the buffer to undo any changes they deliberately or inadvertently make to it. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
Reiner Steib wrote:
-use @code{booleanp} as the property value.
+use @code{booleanp} as the property value. Lambda expressions should
+be quoted so that @code{describe-variable} can display the predicate.
This is ambiguous.
What is meant by quoting a lambda expression '(lambda ... ) or
#'(lambda ... )? If you use '(lambda ... ) the expression does not get
compiled, which can be a nuisance if the lambda does any real work.
If you use #'(lambda ... ) then `C-h v' still displays byte code,
so this form of quoting is useless for the stated purpose.
I personally still believe that the best thing to do would just be to
simply remove this annoying safe-local-variable clutter from the `C-h v'
output entirely.
Sincerely,
Luc.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
_If_ we are going to keep that safe-local-variable trivia in the `C-h v' output, then at least it should be formulated in a less confusing way: This variable is safe to use as a file local variable only if its value satisfies the predicate ... These variables are perfectly safe to use as file local variables in one's own files. What is not safe is to blindly accept somebody else's use of these file local variables. Also, the present text looks like a warning message: Beware, this is a dangerous variable!', whereas variables without safe-local-variable property are actually considered _more_ dangerous by default. An improvement would be: This variable is considered safe as a file local variable if its value satisfies the predicate ... Deleting to use avoids the first confusion. Replacing only if by if avoids the warning aspect. The is considered weakens the implication that all other values are necessarily dangerous, whereas usually only some are. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash upon executing sunrise-sunset
Peter Dyballa wrote: Having updated from CVS today, GNU Emacs crashes reliably upon executing sunrise-sunset Since I know nothing about Mac OS, all I can do is confirm that this is definitely Mac OS specific. It does not happen on GNU/Linux. The code from 2005-05-03 seems to be OK: it displays when sun rose and set down today -- the puzzling thing is that this Carbon Emacs version uses the Elisp code from today There were tons of Mac specific changes to the C code between May 3 and today. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Bill Wohler wrote: Weird, a copy of the message was *not* saved in the *Messages* buffer. It is not a message, but a yes-or-no-p prompt. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Bill Wohler wrote: Bill Wohler [EMAIL PROTECTED] writes: Every morning for the past weeks, I've had a message in my minibuffer that roughly goes, Desktop undo buffer is 3+ MB, discard? (yes or no). I've been saying yes. This morning, feeling snarky, I said no and Emacs crashed. I said no to that question twice this morning, and Emacs did not crash. Emacs only crashes if the size of the undo info is big enough to cause memory overflow. So the fact that if you answer no, Emacs sometimes crashes and sometimes not is to be expected. Also, if you leave Emacs running while the question is being asked and leave your computer without answering the question for a relatively long time, memory leakage will occur. What is this Desktop undo buffer by the way? I do not use desktop. But my impression is that desktop should disable undo somewhere. Somebody who uses and knows desktop should take a look at that. And why does Emacs keep asking me this question? For debugging purposes. I do not know desktop well enough, but this seems to be a bug in desktop (failing to disable undo). Once Emacs-22 is released, the undo info will be discarded automatically, to prevent crashes and memory leakage. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for catch throw should not mention tag
Drew Adams wrote: The doc strings and the Emacs Lisp-manual doc for `catch' and `throw' currently refer to the catch target as the tag. Because of possible confusion with tags files, and to let searching the manual for \btag find only occurrences that involve tag files, the doc for `catch' and `throw' should call the target something like target or label instead of tag. tag is just standard Lisp terminology for this. That is why, for instance, the Common Lisp function `tagbody' is not called `labelbody' or `targetbody'. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc for catch throw should not mention tag
Of course you can find tons of different meanings for the word tag, because it is such a common word. CVS has tags also. I am pretty sure that if I wanted to take the trouble, I could easily point out tons of different uses for label or target too. There is absolutely no problem as long as it is clear from the context which type of tag is meant. In practice, after reading through tons of docs, I never encountered any ambiguity whatsoever. In situations where ambiguity could arise one could easily specify catch tag or CVS tag or whatever. But this will very seldom happen in practice. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customizing cursor color
Otto Maddox wrote: so I go to the cursor customize group. Next to the State button for Cursor face is this: NO CUSTOMIZATION DATA; not intended to be customized. That is because the defface sets the cursor face to '(), that is, nil. Custom stores that value in the `face-defface-spec' symbol property of the symbol `cursor'. But a nil value for a symbol property is equivalent with no property. Thus `cursor' has _no_ face-defface-spec property, which tells Custom that it is not intended to be customized. This apparently causes still other bugs in addition to the one you reported. For variables, Custom avoids this problem by storing the standard value as a list with one element (the standard value). Thus, if the standard value is nil, Custom stores '(nil) in the standard-value property, thereby avoiding the bugs for faces. Apparently, Custom does not consider nil a valid value for a face. If you erase all attributes of a face and then save it through Custom, Custom will save it as '((t nil)). I do not know whether nil actually is supposed to be a valid value for a face, or whether one is supposed to always use '((t nil)) instead. The simplest solution would be to simply replace all nil's in faces.el with '((t nil)) which fixes the bug you reported and other ones. The patch below, which I could install if desired, implements this simple solution. If we really want to admit nil as a valid value, one could store face-defface-spec as a list of one element, in analogy with standard-value, but I believe that this would require quite some rewriting. Another solution would be to make Custom automatically store '((t nil)) in face-defface-spec, if nil was specified in the defface, but I am not sure that this could not yield unexpected problems. Patch: ===File ~/faces.el-diff-b=== *** faces.el06 Feb 2006 16:01:46 -0600 1.348 --- faces.el20 Apr 2006 12:00:05 -0500 *** *** 2143,2161 :group 'frames :group 'basic-faces) ! (defface scroll-bar '() Basic face for the scroll bar colors under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface border '() Basic face for the frame border under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface cursor '() Basic face for the cursor color under X. Note: Other faces cannot inherit from the cursor face. :version 21.1 --- 2143,2161 :group 'frames :group 'basic-faces) ! (defface scroll-bar '((t nil)) Basic face for the scroll bar colors under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface border '((t nil)) Basic face for the frame border under X. :version 21.1 :group 'frames :group 'basic-faces) ! (defface cursor '((t nil)) Basic face for the cursor color under X. Note: Other faces cannot inherit from the cursor face. :version 21.1 *** *** 2164,2170 (put 'cursor 'face-no-inherit t) ! (defface mouse '() Basic face for the mouse color under X. :version 21.1 :group 'mouse --- 2164,2170 (put 'cursor 'face-no-inherit t) ! (defface mouse '((t nil)) Basic face for the mouse color under X. :version 21.1 :group 'mouse ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Small sticking point in documentation
Richard Stallman wrote: is not quite correct. There's a slight difference between C-j at the end of a line and RET followed by TAB: The function 'newline-and-indent' eats up trailing whitespace while RET TAB does not. In programming modes, TAB does exactly that; it adjusts the indentation on the line, so that any indentation the line previously had is irrelevant. To state my previous reply in a different way: C-j at the end of a line is not equivalent with `RET TAB', but with `M-\ RET TAB'. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes
Bill Wohler wrote: I do not understand this. If you remove mh-e/*.elc, it compiles. If you just touch mh-e/mh-e.el and compile it fails. I did `make maintainer-clean' and I even checked that that really removed all mh-e/*.elc files. Bootstrapping nevertheless failed (before your very latest change). I found that making mh-strip-package-version a macro fixes the error (which I just checked in) Now bootstrapping indeed works again. 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
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 as specifying what file representation `load' uses. In practice, `load-file-rep-suffixes' handles compressed representations of a file if and only if Auto Compression mode is enabled. Theoretically, it could be used to let load handle other forms of a file too, but I could not really immediately think of which ones, since in the context of load we are talking exclusively about Elisp files. I would not immediately see a need to support loading, say, encrypted Lisp files. 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
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. And finally, I'm sorry to say that this description still leaves me confused. Why do we need 2 lists, and why one of them is a literal list, while the other is returned by a function? The answers are in the discussions earlier in this thread. There are three lists, one of Elisp suffixes, one of file representation suffixes and one which is a computed combination of both. The last one needs to be computed on the fly, because any of the two other lists could have changed in the meantime, and hence needs to be returned by a function. The two others do not need to be computed on the fly and hence can be stored in a variable. There are various alternatives to this approach, including the current situation, but Richard rejected those. Anyway, it is not the task of a docstring to explain and motivate design decisions. These two doc strings should at least tell that the details of how these lists are used are described in the doc string of `load' (if that's the intent). Just saying that `load' and the unnamed ``related functions'' use does not immediately invites me to look there for a detailed description. Since there are currently still discussions underway about how whether load-file-rep-suffixes should be used just for load or for some other file operations as well, I believe that we should delay any further worries about these two docstrings until these issues are resolved. Maybe if the Elisp manual is properly updated, there could be a link to the Elisp manual in those two docstrings, where these two variables can be discussed in the proper context, which is more difficult in docstrings which are supposed to be relatively compact. 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
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 be renamed `load-file-rep-suffixes'
(I did not rename it yet, as the name is a separate problem) and put
most of the new info in the `load' docstring. I also suggested the
expanded name `load-file-representation-suffixes' for the present
file-rep-suffixes.
===File ~/lread.c-diff-b
Index: lread.c
===
RCS file: /sources/emacs/emacs/src/lread.c,v
retrieving revision 1.349
diff -c -r1.349 lread.c
*** lread.c 6 Feb 2006 15:23:21 - 1.349
--- lread.c 21 Feb 2006 04:21:24 -
***
*** 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, Vload_file_rep_suffixes;
/* File name of user's init file. */
Lisp_Object Vuser_init_file;
***
*** 653,663
return Qnil;
}
DEFUN (load, Fload, Sload, 1, 5, 0,
doc: /* Execute a file of Lisp code named FILE.
First try FILE with `.elc' appended, then try with `.el',
then try FILE unmodified (the exact suffixes are determined by
! `load-suffixes'). Environment variable references in FILE
are replaced with their values by calling `substitute-in-file-name'.
This function searches the directories in `load-path'.
If optional second arg NOERROR is non-nil,
--- 653,685
return Qnil;
}
+ DEFUN (get-load-suffixes, Fget_load_suffixes, Sget_load_suffixes, 0, 0, 0,
+doc: /* Return the suffixes that `load' should try if a suffix is \
+ required.
+ This uses the variables `load-suffixes' and `load-file-rep-suffixes'. */)
+ ()
+ {
+ Lisp_Object lst = Qnil, suffixes = Vload_suffixes, suffix, ext;
+ while (CONSP (suffixes))
+ {
+ Lisp_Object exts = Vload_file_rep_suffixes;
+ suffix = XCAR (suffixes);
+ suffixes = XCDR (suffixes);
+ while (CONSP (exts))
+ {
+ ext = XCAR (exts);
+ exts = XCDR (exts);
+ lst = Fcons (concat2 (suffix, ext), lst);
+ }
+ }
+ return Fnreverse (lst);
+ }
+
DEFUN (load, Fload, Sload, 1, 5, 0,
doc: /* Execute a file of Lisp code named FILE.
First try FILE with `.elc' appended, then try with `.el',
then try FILE unmodified (the exact suffixes are determined by
! `load-suffixes'). Environment variable references in FILE
are replaced with their values by calling `substitute-in-file-name'.
This function searches the directories in `load-path'.
If optional second arg NOERROR is non-nil,
***
*** 669,674
--- 691,708
If optional fifth arg MUST-SUFFIX is non-nil, insist on
the suffix `.elc' or `.el'; don't accept just FILE unless
it ends in one of those suffixes or includes a directory name.
+ If this function fails to find a file, it may look for different
+ representations of that file before trying another file.
+ It does so by adding the non-empty suffixes in `load-file-rep-suffixes'
+ to the file name. Emacs uses this feature mainly to find compressed
+ versions of files when Auto Compression mode is enabled.
+
+ The exact suffixes that this function tries out, in the exact order,
+ are given by the value of the variable `load-file-rep-suffixes' if
+ NOSUFFIX is non-nil and by the return value of the function
+ `get-load-suffixes' if MUST-SUFFIX is non-nil. If both NOSUFFIX and
+ MUST-SUFFIX are nil, this function first tries out the latter suffixes
+ and then the former..
Loading a file records its definitions, and its `provide' and
`require' calls, in an element of `load-history' whose
***
*** 749,757
fd = openp (Vload_path, file,
(!NILP (nosuffix) ? Qnil
! : !NILP (must_suffix) ? Vload_suffixes
! : Fappend (2, (tmp[0] = Vload_suffixes,
! tmp[1] = default_suffixes,
tmp))),
found, Qnil);
UNGCPRO;
--- 783,791
fd = openp (Vload_path, file,
(!NILP (nosuffix) ? Qnil
! : !NILP (must_suffix) ? Fget_load_suffixes ()
! : Fappend (2, (tmp[0] = Fget_load_suffixes (),
! tmp[1] = Vload_file_rep_suffixes,
tmp))),
found, Qnil);
UNGCPRO;
***
*** 1109,1115
fn = (char
Re: autoload and auto-compression-mode
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 http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: autoload and auto-compression-mode
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 update various docstrings and loading.texi.
The patches to jka-compr.el and jka-cmpr-hook.el also fix updating
bugs for jka-compr-load-suffixes and two other jka related
customizable options. These are not unrelated bugfixes, but a
necessary complement to my above fix.
There are two types of bugs for these three options. First,
currently Emacs ignores any user customization for these three
options: customizing these options only has an effect if done _before_
enabling Auto Compression mode. But Auto Compression mode is enabled
at startup before the user's .emacs file is read, hence the
customizations in .emacs are ignored. Another serious bug in these
three variables is that if you change them while Auto Compression mode
is enabled and then disable Auto Compression mode, then Auto
Compression mode may not be correctly disabled.
My patches fix both kind of bugs by giving the three defcustoms a :set
function that provides for automatic updating, making the new values
take effect immediately, and by making Auto Compression mode store the
values of the three variables at the time it was enabled. That way
Auto Compression mode can correctly remove everything it added to
various other variables. If you set these three jka customizable
options _outside_ Custom, you still (after my patches) have to call an
updating function to make the new values take effect immediately.
Short of essentially completely rewriting jka-*, I do not know what to
do about that. At least, now there is an updating function and it
works correctly.
===File ~/lread.c-diff==
Index: lread.c
===
RCS file: /sources/emacs/emacs/src/lread.c,v
retrieving revision 1.349
diff -c -r1.349 lread.c
*** lread.c 6 Feb 2006 15:23:21 - 1.349
--- lread.c 19 Feb 2006 02:15:01 -
***
*** 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, Vload_file_rep_suffixes;
/* File name of user's init file. */
Lisp_Object Vuser_init_file;
***
*** 653,658
--- 653,680
return Qnil;
}
+ DEFUN (get-load-suffixes, Fget_load_suffixes, Sget_load_suffixes, 0, 0, 0,
+doc: /* Return the suffixes that `load' should try if a suffix is \
+ required.
+ This uses the variables `load-suffixes' and `load-file-rep-suffixes'. */)
+ ()
+ {
+ Lisp_Object lst = Qnil, suffixes = Vload_suffixes, suffix, ext;
+ while (CONSP (suffixes))
+ {
+ Lisp_Object exts = Vload_file_rep_suffixes;
+ suffix = XCAR (suffixes);
+ suffixes = XCDR (suffixes);
+ while (CONSP (exts))
+ {
+ ext = XCAR (exts);
+ exts = XCDR (exts);
+ lst = Fcons (concat2 (suffix, ext), lst);
+ }
+ }
+ return Fnreverse (lst);
+ }
+
DEFUN (load, Fload, Sload, 1, 5, 0,
doc: /* Execute a file of Lisp code named FILE.
First try FILE with `.elc' appended, then try with `.el',
***
*** 749,757
fd = openp (Vload_path, file,
(!NILP (nosuffix) ? Qnil
! : !NILP (must_suffix) ? Vload_suffixes
! : Fappend (2, (tmp[0] = Vload_suffixes,
! tmp[1] = default_suffixes,
tmp))),
found, Qnil);
UNGCPRO;
--- 771,779
fd = openp (Vload_path, file,
(!NILP (nosuffix) ? Qnil
! : !NILP (must_suffix) ? Fget_load_suffixes ()
! : Fappend (2, (tmp[0] = Fget_load_suffixes (),
! tmp[1] = Vload_file_rep_suffixes,
tmp))),
found, Qnil);
UNGCPRO;
***
*** 1109,1115
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));
--- 1131,1137
fn = (char *) alloca (fn_size = 100 + want_size);
/* Loop over suffixes. */
! for (tail = NILP (suffixes) ? Vload_file_rep_suffixes : suffixes;
CONSP (tail); tail = XCDR (tail))
{
int lsuffix = SBYTES (XCAR (tail));
***
***
Re: display.texi
bojohan wrote: This change to the manual revision 1.198 date: 2006-01-29 16:59:57 +; author: cyd; state: Exp; lines: +2 -2 * display.texi (Other Display Specs, Image Descriptors): Image description is a list, not a cons cell. replaced (image . PROPS) with (image PROPS). The old description was correct. The proper format is (image . PROPS) == (image . (:prop1 val1 :prop2 val2 ...)) == (image :prop1 val1 :prop2 val2 ...) Indeed. The above was pointed out a week ago. But the errors are still present in the Elisp manual. Is there any reason not to revert these changes, since they are obviously erroneous? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-name-shadow-mode breaks viper-mode's // interpretation
I guess that I am CC-ed on this because I handled the technical details of how to enable the minor mode `file-name-shadow-mode' by default. But I was not the one who actually implemented `file-name-shadow-mode' (Miles Bader and, for some part, Stefan Monnier). I do not know viper-mode well enough to solve this problem. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: erc: problems with bundled erc in CVS::Emacs
T. V. Raman wrote: 1) For some reason the files in lisp/erc are not getting byte-compiled. They do compile for me with: cvs -z3 update -d cd emacs make maintainer-clean ./configure --without-toolkit-scroll-bars make bootstrap 1) Loading library erc bombs because it depends on defalias definitions in erc-compat.el (suggest getting rid of these defalias kluges since they are a nightmare to debug) erc loads without problems for me. The fact that it depends om erc-compat shoulds not give any problems, because erc contains: (require 'erc-compat) Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: buggy defcustom in sendmail.el
T. V. Raman wrote: Recent cvs updates have ended up leaving send-mail-function set to nil while running on the linux console. Evaluating the form that is in the defcustom does yield the right result, so I suspect some kind of bizarre autoloading bug. I can not reproduce this. On the Linux console, send-mail-function is sendmail-send-it for me. However, if your loaddefs.el is not properly updated, then send-mail-function will indeed be nil. Your loaddefs.el should contain: (put (quote send-mail-function) (quote standard-value) (quote ((if (and window-system (memq system-type (quote (darwin windows-nt (quote mailclient-send-it) (quote sendmail-send-it) Otherwise it is out of date. To update loaddefs.el do: $ cd lisp $ make autoloads mh-autoloads EMACS=../src/emacs or use `make-bootstrap'. I believe that this should fix your problem. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: invalid-function ('use-completion-backward)
Chris Moore wrote: My .emacs contains a single line: (dynamic-completion-mode) If the first thing I do upon starting Emacs is type: C-x C-f backspace then I see an error message: Error in pre-command-hook: (invalid-function ((quote use-completion-backward))) I believe that the folowing patch should fix this. I can install if desired. ===File ~/completion-diff=== *** completion.el 02 Dec 2005 16:17:17 -0600 1.55 --- completion.el 24 Jan 2006 11:27:18 -0600 *** *** 82,88 ;; SAVING/LOADING COMPLETIONS ;; Completions are automatically saved from one session to another ;; (unless save-completions-flag or enable-completion is nil). ! ;; Activating this minor-mode calling completion-initialize) causes Emacs ;; to load a completions database for a saved completions file ;; (default: ~/.completions). When you exit, Emacs saves a copy of the ;; completions that you --- 82,88 ;; SAVING/LOADING COMPLETIONS ;; Completions are automatically saved from one session to another ;; (unless save-completions-flag or enable-completion is nil). ! ;; Activating this minor-mode (calling completion-initialize) causes Emacs ;; to load a completions database for a saved completions file ;; (default: ~/.completions). When you exit, Emacs saves a copy of the ;; completions that you *** *** 2250,2262 TYPE is the type of the wrapper to be added. Can be :before or :under. (put function-name 'completion-function (cdr (assq type ! '((:separator 'use-completion-before-separator) ! (:before 'use-completion-before-point) ! (:backward-under 'use-completion-backward-under) ! (:backward 'use-completion-backward) ! (:under 'use-completion-under-point) ! (:under-or-before 'use-completion-under-or-before-point) ! (:minibuffer-separator 'use-completion-minibuffer-separator)) (defun use-completion-minibuffer-separator () (let ((completion-syntax-table completion-standard-syntax-table)) --- 2250,2263 TYPE is the type of the wrapper to be added. Can be :before or :under. (put function-name 'completion-function (cdr (assq type ! '((:separator . use-completion-before-separator) ! (:before . use-completion-before-point) ! (:backward-under . use-completion-backward-under) ! (:backward . use-completion-backward) ! (:under . use-completion-under-point) ! (:under-or-before . use-completion-under-or-before-point) ! (:minibuffer-separator !. use-completion-minibuffer-separator)) (defun use-completion-minibuffer-separator () (let ((completion-syntax-table completion-standard-syntax-table)) ___ 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: 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 just talking about `load'. Obviously, it would not be smart to write inline code in these 9 places which are bound to become more than 9 over time. So we have two solutions: The first is to define a new primitive function, say `get-load-suffixes'. The user/programmer would use the variable `load-suffixes' directly _only_ when changing its value for some non-compression related reason (which probably seldom happens; I have never done it, except to experiment). But when functions want to figure out what suffixes to try (happens at 9 places, bound to go up), they should not use load-suffixes directly, but call the function `get-load-suffixes'. The second solution is to define a command `set-basic-load-suffixes', probably written in Lisp. If the user wants to change the value of the basic load suffixes, he should not set `load-suffixes' or `basic-load-suffixes' directly, but do (set-basic-load-suffixes '(...)), which automatically updates everything that needs to be updated. If one really wants, one could write a defcustom for `basic-load-suffixes' with `set-basic-load-suffixes' as :set function. But all functions could still access the value of load-suffixes normally, by just evaluating it. I do not immediately see why the first solution is cleaner. The second seems more standard. There are many variables in Emacs whose value only takes effect either by calling a function or by setting through Custom. The second solution seems also easier to implement. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: move-beginning-of-line
Drew Adams wrote: 3. I don't see home documented in the Emacs manual (for `beginning-of-line' or `move-beginning-of-line'). Shouldn't it be mentioned? No, because there is no reason to use home to go to the beginning of a line if you know about the much more efficient C-a. The home binding is only meant for beginning users who do not know about C-a yet, but may have been using other editors that use home to go to the beginning of a line. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: move-beginning-of-line
Drew Adams wrote: Is there some reason not to bind home to `move-beginning-of-line'? This was my #2 question. Not that I know of. I believe that it is just an omission. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: move-beginning-of-line
2005-10-04 Stefan Monnier ...
* bindings.el (global-map): Resync [home] and [end] bindings with
C-a and C-e.
I somehow forgot that Drew uses old CVS, so I forgot to check this in
`emacs -q'. (Normally I have home and end bound to
{beginning,end}-of-buffer.)
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
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 main purpose of my patches was to fix the type of bugs that started this thread. So you should add it to cus-start.el. If we want to allow the user to customize a `load-suffixes' type variable, then I believe that we need one, or maybe two, new customizable variable(s), say `basic-load-suffixes' and `basic-load-file-rep-suffixes'. These would represent the values of `default-suffixes' and `load-file-rep-suffixes' that `load-suffixes' and `load-file-rep-suffixes' _would_ have if Auto Compression mode would be disabled. In addition to provide user customizability, it could also make the way Auto Compression mode plays around with `load-suffixes' and `load-file-rep-suffixes' cleaner and more reliable. My present patch does not do that, but I could adapt it to do that if desired. 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
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 for the `load' operation). and Richard Stallman wrote: + is not required. Normally includes the empty string. */); Is that really true? Doesn't it normally include more than just the empty string? It did not say Normally only includes But anyway, it seems that the only objections to my patches are the name and the docstring. Stefan proposed load-no-suffix-suffixes, but since it is related to the NOSUFFIX arg to load, I prefer load-nosuffix-suffixes. If that name and the following docstring look OK, I will replace everywhere in the C and Lisp code default[-_]suffixes with the new names and install my patches. DEFVAR_LISP (load-nosuffix-suffixes, Vload_nosuffix__suffixes, doc: /* List of suffixes that are not treated as suffixes\ by `load'. Loading a file tries these suffixes and no others if no \real suffix\ is allowed. It tries them after the suffixes in `load-suffixes' if a suffix is allowed, but not required. It does not try them at all if a suffix is required. This list should include the empty string. If Auto Compression mode is enabled, as it is by default, it also includes the suffixes in `jka-compr-load-suffixes'. */); ___ 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
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 without my patches applied). The only reliable way to change load-suffixes for an ordinary user is to customize the (defcustomed) variable `jka-compr-load-suffixes'. Changing this situation would require more extensive changes than the ones in my patches and even after such changes, carelessly customizing load-suffixes could easily make Emacs unusable. I propose to remove the `*' and consider `load-suffixes' a non user variable. 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
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
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
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 `must-suffix' too unspecific here? No. It is very specific. It requires a suffix present in `load-suffixes'. Would it make sense to have something like an exclude list for file name suffixes so that a file `foo.gz' is treated like `foo'?? 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. 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
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 with just two small changes, I wil take a look at it. 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
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 ~/subr-diff= *** subr.el 30 Dec 2005 08:35:47 -0600 1.493 --- subr.el 15 Jan 2006 19:21:23 -0600 *** *** 1328,1334 t)) (let ((file (locate-file library (or path load-path) ! (append (unless nosuffix load-suffixes) '() (if interactive-call (if file (message Library is file %s (abbreviate-file-name file)) --- 1328,1337 t)) (let ((file (locate-file library (or path load-path) ! (append (unless nosuffix load-suffixes) ! '() ! (unless nosuffix !jka-compr-load-suffixes) (if interactive-call (if file (message Library is file %s (abbreviate-file-name file)) ===File ~/jka-cmpr-hook-diff *** jka-cmpr-hook.el15 Nov 2005 21:55:16 -0600 1.8 --- jka-cmpr-hook.el15 Jan 2006 19:26:13 -0600 *** *** 140,145 --- 140,146 :type '(repeat (cons string symbol)) :group 'jka-compr) + ;;;###autoload (defcustom jka-compr-load-suffixes '(.gz) List of suffixes to try when loading files. :type '(repeat string) *** *** 217,229 ;; Make sure that (load foo) will find /bla/foo.el.gz. (setq load-suffixes ! (apply 'append ! (append (mapcar (lambda (suffix) !(cons suffix ! (mapcar (lambda (ext) (concat suffix ext)) ! jka-compr-load-suffixes))) ! load-suffixes) !(list jka-compr-load-suffixes) (defun jka-compr-installed-p () --- 218,229 ;; Make sure that (load foo) will find /bla/foo.el.gz. (setq load-suffixes ! (apply 'append (mapcar (lambda (suffix) !(cons suffix ! (mapcar (lambda (ext) !(concat suffix ext)) ! jka-compr-load-suffixes))) ! load-suffixes (defun jka-compr-installed-p () ===File ~/ldefs-boot-diff=== Index: ldefs-boot.el === RCS file: /sources/emacs/emacs/lisp/ldefs-boot.el,v retrieving revision 1.12 diff -c -r1.12 ldefs-boot.el *** ldefs-boot.el 6 Jan 2006 12:05:46 - 1.12 --- ldefs-boot.el 16 Jan 2006 02:06:53 - *** *** 1,15560 --- 1,15571 ;;;*** + ;;;### (autoloads (jka-compr-load-suffixes) jka-cmpr-hook jka-cmpr-hook.el + ;; (17354 63029)) + ;;; Generated autoloads from jka-cmpr-hook.el + + (defvar jka-compr-load-suffixes (quote (.gz)) \ + List of suffixes to try when loading files.) + + (custom-autoload (quote jka-compr-load-suffixes) jka-cmpr-hook) + + ;;;*** + ;;;### (autoloads (jka-compr-uninstall jka-compr-handler) jka-compr ;; jka-compr.el (17148 24997)) ;;; Generated autoloads from jka-compr.el ___ 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
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 export default_suffixes to Lisp and have jka-compr-* use that instead of jka-compr-load-suffixes? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: :link is ignored in defface - contradicts Elisp manual
Drew Adams wrote: Customize-face does correctly show the link provided by a :link that is applied to a defface in that group. However, customize-group does not show this link for the face. Yes it does. Just click on Show Face. Note that the values of faces are normally hidden by default in group buffers (but not when you do `M-x customize-face'). For most defcustoms, the value is not hidden by default. If you hide their value, the link disappears, just like for faces. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-faces overridden?
What happens if you delete the -face from the face names? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
On closer look, it appears that the error can be triggered both at compile and at run time (because the keywords can be compiled at run time). Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Quoted lambda expressions in manuals
Ralf Angeli wrote: There are some quoted lambda expressions in the manuals: find . -type f -print0 | xargs -0 -e grep -nH -e '(lambda ./custom.texi:905: '(lambda () ./custom.texi:1392: '(lambda () ./custom.texi:: '(lambda () (auto-fill-mode 1))) ./emacs-xtra.texi:215: #'(lambda (optional noconfirm) 'fast)) ./gnus.texi:3020: '(lambda nil (local-set-key d (local-key-binding n Maybe those could be removed eventually in order to prevent bad karma (as Stefan puts it). There is a difference between ' and #'. According to the Elisp manual, quoting a lambda expression with ' can be used to prevent byte-compilation. (If this is incorrect, the Elisp manual should be corrected.) Preventing byte-compilation is clearly not intended in the above examples. In as far as #' is concerned, `(elisp)Anonymous Functions' points out that it is no longer really necessary, but goes on to discuss it at length, and examples in other nodes in the Elisp manual use it. The clear impression you get from reading the Elisp doc is that, although #' (or `function') is not necessary, it is better to use it anyway, as a sort of comment. _If_ this is wrong and if the special form `function' is actually deprecated, then several changes in the Elisp manual would be needed. In that case, the discussion of `function' in `(elisp)Anonymous Functions' should be substantially shortened. It should explicitly state that `function' should only be used if you want your code to work with old Emacs versions. `function' should not be used in examples in the Elisp manual. The main question is: Is the special form `function' (or #') deprecated or is its use as a type of comment still encouraged, as the Elisp manual seems to suggest? Or is it only deprecated for lambda expressions and not for quoting symbols that are used as functions (where most of the time a simple ' appears to be used in practice anyway)? Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tooltip custom group: duplicate labels
Nick Roberts wrote: Variable names are generally chosen to be self explanatory. Since the hyphens are removed in the node name, I guess you mean variable name. its hard to tell whether it's derived from the variable name or comes from a tag. This just seems to provide another level of obfuscation. And it confuses people who like to use customize-apropos. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: DEL key doesn't kill mouse-dragged region
Eli Zaretskii wrote: Care to share the details (what problems newbies are supposed to have, but don't)? I do not want to seem to reopen recent discussions, but since you explicitly ask for it: Plenty of stuff. For instance, something that has been discussed recently, ^L being pagebreaks: they just figure that out very quickly and they make plenty of use of it. There is the silly myth that regexps are useless to newbies. To newbies, regexps are just spiced up strings and they get by perfectly using plenty of regexps like auto fill mode. If that is going to find anything matching two or more of these words, now _that_ is going to confuse them. It has been said : experienced users can always use auto +fill mode if they want a regexp, but that is forcing unobvious tricks on _newbies_, who are the most likely to use regexps without any special characters. Of course, what also confuses them is that in Emacs, the regexp auto fill mode sometimes matches auto fill mode even when spread over several lines (which is usually what they really want) and sometimes not, depending on the Emacs function they use. Apart from that, people can pretty painlessly slowly graduate from using exclusively the auto fill type regexp to more and more complicated stuff, if they feel that need. I could give more examples, but I do not want to write a one hundred page dissertation on the subject. What really confuses newbies (as well as experienced users) is inconsistent behavior (such as traditional Emacs behavior and MS Windows type behavior more or less randomly mixed together), lack of transparency (such as abusive use of invisibility and display properties, a very bad problem in Info, leading to surprises while yanking or while printing off stuff). What obviously discourages people learning Emacs is too much change in basic behavior from one Emacs version to the next. It makes too much of what they have learned useless. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: DEL key doesn't kill mouse-dragged region
Drew Adams wrote: Why not just turn on delete-selection-mode and transient-mark-mode, by default? Certainly not delete-selection-mode. Its behavior is extremely surprising, disturbing and difficult to understand for _real_ newbies (newbies to editors, as opposed to experienced MS Windows users). Yes, there are still people who are unfamiliar with the MS Windows interface. I am one of them. But I have taught Math courses that use mathematical software to Math Ed students, some of them middle aged and with very limited computer knowledge. I recommend that they use Emacs as their editor. They manage very well. They do not seem to have any of those problems newbies are _supposed_ to have, according to the apparently prevailing wisdom on this list. The only people to complain will be (some of the) experienced users, and they can easily restore the current behavior. _Real_ newbies might indeed not complain (at least not on emacs-devel, Bug-gnu-emacs or similar lists), but they would suffer. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dabbrev-completion doc string
Resending, since I got an invalid address error for emacs-pretest-bug the first time. Drew Adams wrote: IIUC, a nil ARG means to search only the current buffer. I apparently did not read the docstring carefully enough. The first paragraph says exactly that. Perhaps this all hinges on the meaning of if there is a suitable one already - just what does that mean? I suspect that explaining what suitable means here, in user terms, would mean explaining that only the current buffer is to be searched. But I could be wrong. On reading through the source code, I am the one who is confused now. Whether the old list is suitable or not is determined by an `and' expression. But that `and' expression includes `dabbrev--last-abbreviation' and this happens after `dabbrev--reset-global-variables' got called which always sets `dabbrev--last-abbreviation' to nil. The way I understand it, the `and' expression _always_ returns nil and the old completion list is _never_ suitable. I must be misunderstanding something. I tried to CC the listed maintainer, but that apparently resulted in an invalid address error. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Failure in describe-variable
Richard Stallman wrote: Pick a variable in loaddefs.el e.g. warning-type-format. Do C-h v on it. The *Help* buffer says: warning-type-format is a variable defined in `C source code'. Its actually defined in warnings.el Clicking on the link gives: Search failed: Vwarning-type-format It does not fail for me. It fails for me and it seems rather strange that it does not fail for you. Did you use `emacs -q'? I do not see how the current call to locate-file in startup.el can correctly handle loaddefs, since, prior to the code in startup.el, loaddefs is stored in load-history as loaddefs.el and is not in load-suffixes, that is, locate-file tries to find loaddefs.el.el and so on in load-path, but not loaddefs.el. The following patch fixes this and makes the reported problem go away. I can install if desired. ===File ~/startup-diff== *** startup.el 15 Nov 2005 19:12:15 -0600 1.388 --- startup.el 18 Nov 2005 20:37:44 -0600 *** *** 647,653 (if (and (stringp (car elt)) (not (file-name-absolute-p (car elt (cons (locate-file (car elt) load-path !load-suffixes) (cdr elt)) elt)) load-history)) --- 647,653 (if (and (stringp (car elt)) (not (file-name-absolute-p (car elt (cons (locate-file (car elt) load-path !(append load-suffixes '())) (cdr elt)) elt)) load-history)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q behavior doesn't match doc
While trying to document a bug I ran Emacs using -Q. It was a nice surprise to see syntax highlighting and paren matching were on. I've always thought these should default to ON. But the doc specifically says ... This is like using `-q' and `--no-site-file', but in addition it also disables the menu-bar, the tool-bar, the scroll-bars, tool tips, the blinking cursor, and the fancy startup screen. Could you state precisely which exact docs are you referring to? `emacs --help' gives: --quick, -Q equivalent to -q --no-site-file --no-splash and `(emacs)Initial Options' says: `-Q' `--quick' Start emacs with minimum customizations. This is like using `-q' and `--no-site-file', but also disables the startup screen. Since you are apparently using relatively recent CVS: GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600) of 2005-11-11 on LD1 that is what you should see, unless there is a problem with the way you updated. But maybe you are referring to some other docs that we might indeed have overlooked. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q behavior doesn't match doc
I'm not up to snuff on figuring out where the source is but the section I quoted starts like this: C.2 Initial Options === The initial options specify parameters for the Emacs session. This section describes the more general initial options; some other options specifically related to the X Window System appear in the following sections. Your Info version of the Elisp manual is not up to date. I guess you ran: $ ./configure $ make $ cd lisp $ make recompile EMACS=../src/emacs $ cd .. $ make as recommended in INSTALL.CVS. I thought that `make' automatically updates the Info docs, but I am not really sure of that. I am sure that somebody else on this list will know. I personally always do `make maintainer-clean', `configure' and `make bootstrap', which does update them. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q behavior doesn't match doc
From my earlier reply: Your Info version of the Elisp manual is not up to date. I meant: Your Info version of the Emacs manual is not up to date. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q behavior doesn't match doc
I get a Don't know how to make maintainer-clean message when I run `nmake maintainer-clean'. I made the mistake of locating a makefile that DID know how and it emptied my emacs\info directory. nmake bootstrap completes successfully but it never rebuilds the info files. It does rebuild them. But you may have to run `make install' after `make bootstrap' to install them in the place an installed Emacs looks for them. make maintainer-clean ./configure make bootstrap sudo make install should have properly updated all your info files as well as everything else. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q behavior doesn't match doc
But I don't see configure looking for makeinfo It looks for install-info. so I don't see how this should happen. It is `make bootstrap' that calls makeinfo, not configure. But maybe the following excerpt of INSTALL.CVS is relevant, if you are using MS Windows: Users of non-Posix systems (MS-Windows etc.) should run the platform-specific configuration scripts (nt/configure.bat, config.bat, etc.) before make bootstrap. I do not really know anything about MS Windows. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q behavior doesn't match doc
But if you don't have makeinfo the makefile's for man, lispref and lispintro will fail. For CVS, you need version 4.2 or later of Texinfo. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-variables fails to set variable
Glenn Morris wrote: I am he, but Stefan has it right anyway. It was just a cosmetic change, in response to bug report outline mode doesn't call outline-mode-hook as promised (patch) (Jul 16 2003). Without it, when one read the docstring for a mode defined with define-derived-mode it referenced a hook that did not seem to be defined. I do not know wether the fact that a hook is unbound caused problems back in July 2003, but it certainly causes no problems in today's CVS. Many hooks are unbound until add-hook gets called for them. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
The patch I sent yesterday was silly. I send an alternative patch below, which I will install if there are no objections. I forgot about the 'string arg to file-attributes (I should have reread the docs). The patch below passes the 'string arg to `file-attributes' and everything works OK, including the GID. The `user-login-name' stuff is unnecessary if the 'string arg is used. Probably, the 'string arg did not exist when find-lisp was written. I got confused by the comment on line 521 in ls-lisp.el: ;; Numeric uid/gid are more confusing than helpful; ;; Emacs should be able to make strings of them. ===File ~/find-lisp.el-diff= *** find-lisp.el09 Nov 2005 17:05:07 -0600 1.10 --- find-lisp.el10 Nov 2005 08:39:41 -0600 *** *** 3,9 ;; Author: Peter Breton ;; Created: Fri Mar 26 1999 ;; Keywords: unix ! ;; Time-stamp: 2005-11-10 09:00:49 teirllm ;; Copyright (C) 1999, 2000, 2002, 2003, 2004, ;; 2005 Free Software Foundation, Inc. --- 3,9 ;; Author: Peter Breton ;; Created: Fri Mar 26 1999 ;; Keywords: unix ! ;; Time-stamp: 2005-11-10 08:39:41 teirllm ;; Copyright (C) 1999, 2000, 2002, 2003, 2004, ;; 2005 Free Software Foundation, Inc. *** *** 293,299 (defun find-lisp-find-dired-insert-file (file buffer) (set-buffer buffer) (insert find-lisp-line-indent ! (find-lisp-format file (file-attributes file) (list ) (current-time --- 293,299 (defun find-lisp-find-dired-insert-file (file buffer) (set-buffer buffer) (insert find-lisp-line-indent ! (find-lisp-format file (file-attributes file 'string) (list ) (current-time *** *** 309,326 (if (memq ?s switches) ; size in K (format %4d (1+ (/ (nth 7 file-attr) 1024 (nth 8 file-attr) ; permission bits - ;; numeric uid/gid are more confusing than helpful - ;; Emacs should be able to make strings of them. - ;; user-login-name and user-full-name could take an - ;; optional arg. (format %3d %-8s %-8s %8d (nth 1 file-attr) ; no. of links ! (if (= (user-uid) (nth 2 file-attr)) ! (user-login-name) ! (int-to-string (nth 2 file-attr))); uid (if (eq system-type 'ms-dos) root ; everything is root on MSDOS. ! (int-to-string (nth 3 file-attr))); gid (nth 7 file-attr) ; size in bytes ) (find-lisp-format-time file-attr switches now) --- 309,324 (if (memq ?s switches) ; size in K (format %4d (1+ (/ (nth 7 file-attr) 1024 (nth 8 file-attr) ; permission bits (format %3d %-8s %-8s %8d (nth 1 file-attr) ; no. of links ! (if (integerp (nth 2 file-attr)) ! (int-to-string (nth 2 file-attr)) ! (nth 2 file-attr)) ; uid (if (eq system-type 'ms-dos) root ; everything is root on MSDOS. ! (if (integerp (nth 3 file-attr)) ! (int-to-string (nth 3 file-attr)) ! (nth 3 file-attr))) ; gid (nth 7 file-attr) ; size in bytes ) (find-lisp-format-time file-attr switches now) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-variables fails to set variable
Bill Wohler wrote: I've found a problem where my mh-letter-mode-hook (in MH-E) isn't getting called. It is listed properly in the custom-set-variables stanza, but when I start Emacs, load MH-E, and run customize-option on mh-letter-mode-hook, the hook is empty! When I enter the hook function, the hook works again. Is it because MH-E isn't loaded when custom-set-variables is run? Is it something MH-E is doing when it is loaded? No. The sequence of events is the following. (I explain it in a somewhat simplified version, but it is still complex enough.) The entry for mh-letter-mode-hook in the custom-set-variables form is not executed while your .emacs is loaded, _unless_ the variable already has a value at that time. If the variable already has a value, custom-set-variables immediately overwrites it and you will note that your bug disappears if you put (defvar mh-letter-mode-hook nil) in your .emacs _before_ the call to custom-set-variables. But if mh-letter-mode-hook is unbound when the custom-set-variables form is evaluated then all custom-set-variables does is set the 'saved-value property of mh-letter-mode-hook, which remains unbound. Later, when the defcustom is executed mh-letter-mode-hook is set to the 'saved-value property _if_ it is still unbound. But if it got bound to some value in the meantime, the defcustom leaves that value unchanged. Summary, where defvar means a non-compiler defvar, i.e just (defvar foo) has no effect, except quieting the compiler: defvar custom-set-variables defvar defcustom: custom-set-variables wins. custom-set-variables defcustom defvar: custom-set-variables wins again. custom-set-variables defvar defcustom: The defvar wins. All of this may look contorted, but the fact is that making a defcustom compete with a real defvar makes no sense. mh-letter-mode is defined using define-derived-mode, whose macroexpanded form contains: (defvar mh-letter-mode-hook nil) This is normally executed after the custom-set-variables form, but before the defcustom, so we get: custom-set-variables defvar defcustom and the defvar wins. mh-letter-mode-hook remains nil. There are probably good, but complex reasons behind Custom's complexity, as explained above. I do not immediately know what the best real solution to your problem is, but a workaround to the problem would be to put the defcustom before the call to define-derived-mode. Then you get: custom-set-variables defcustom defvar and the defvar looses, as it should. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-variables fails to set variable
From my previous message: custom-set-variables defcustom defvar and the defvar looses, as it should. The defvar looses in the struggle for the value, but the defvar wins in as far as the docstring is concerned, which might be a problem for you. To avoid this you could do: defcustom define-derived-mode yet-another-defvar-with-your-docstring, which would start looking very strange. Maybe we need a keyword argument to define-derived-mode that prevents it from defvarring the mode hook, in case somebody wants a defcustom or a hand-crafted defvar. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-variables fails to set variable
Bill Wohler wrote: There are two solutions 1. Preserve the Emacs 21 semantics which had the effect of remembering customization settings in customize-set-variables so that when the modules were eventually loaded, the user's settings took precendence. In as far as I can see the way that customization settings are remembered in emacs-23 is exactly the same as in current CVS. I explained the somewhat complex details in my earlier message. What _has_ changed is that now define-derived-mode writes a defvar for the mode hook. It did not do that in emacs-21.3. That is what caused the regression. Why does define-minor-mode need to defvar the mode hook? There is no need to defvar hooks. `add-hook' can perfectly handle unbound hook variables. I propose that we revert this change in define-derived-mode. One should check define-minor-mode and similar macros to see if they have the same problem and correct them too if they do. Boy howdy! It is a trend. Not to the degree you think. Obviously it is a trend for mode hooks that have competing definitions, one as a defvar and one as a defcustom. However, many of the problems in your list seem to be unrelated local problems. For instance I can not reproduce your problem with ispell-program-name. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-variables fails to set variable
I'm still a bit confused though. For example, mh-show-mode-hook is defined implicitly by the definition of mh-show-mode in mh-utils.el which requires mh-customize.el which contains the defcustom of mh-show-mode-hook. Shouldn't that defcustom have won against the defvar in the mh-show-mode? I should look at the details to figure that out. But do not forget that add-hook also will bind an undefined hook, just as defvar does. Custom and hooks quite simply do not work very well together. Per designed Custom under the assumption that there are two disjoint classes of variables: internal variables for use by programs and Custom variables for user customization which programs should never touch. Emacs does not satisfy that assumption and this creates problems. These problems are the worst for hooks, which should be manipulated with add-hook and remove-hook, not with setq-default, as Custom does. I described several nasty problems related to Custom and hooks earlier. This is a yet another one. We are planning for a fix, but decided it was too involved to do before the release. (add-hook 'foo-hook 'essential-function) custom-set-variables: The custom-set-variables undoes the add-hook. This is a problem I described earlier. It could create problems if a user upgrades to an Emacs version in which essential-function is new and essential. It is a constant potential pitfall for CVS users. But now: custom-set-variables (add-hook 'foo-hook 'essential-function) defcustom: Now the add-hook means that the user's customization is ignored. This is yet another problem related to Custom and hooks. custom-set-variables defcustom (add-hook 'foo-hook 'essential-function) will work as intended, but I see no way to always guarantee this order. I'd still be curious to hear the opinions on whether one should use the ;;;###autoload cookie on the defcustoms or not. It could solve the newly pointed out problem with Custom and hooks, but would not solve the other ones, like, for instance, the first one I pointed out above (there are others). Some people who do not have a lot of memory available might not like it. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: custom-set-variables fails to set variable
Bill Wohler wrote: Also, why does the same code work in Emacs 21 and not in Emacs 22? I believe that I answered this in an earlier reply, but maybe you had not yet read that reply when you asked this. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Nick Roberts wrote: Can you get find-lisp-find-dired to work? I fixed both bugs you reported. If you update your CVS, things should work fine, except for the updating problem that we are discussing. I did not remove the binding for dired-buffers. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Richard Stallman wrote: The patch in Nick's message includes another change in another place. It looked like that other change was intended to update files correctly in both kinds of buffers, but I did not study it. What is that other change supposed to do? Take care of *Locate* buffers. Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Nick Roberts (talking about find-lisp-find-dired) wrote: The GID is listed as a number, which seems a bit strange. There is worse. The UID is also a number, except for the user who is running Emacs. This is a misfeature. There is still worse, if you run Emacs with the -u option. For instance if I su to root but run Emacs with `-u teirllm', then find-lisp-find-dired falsely lists all files owned by root as owned by teirllm. This is an outright bug. The patch below fixes the UID-bug, as well as the UID-misfeature. It also updates a partially obsolete comment. I will install the patch if there are no objections. In as far as the GID misfeature is concerned, if I understand correctly, find-lisp.el, like ls-lisp.el, tries to get the directory listing completely from Lisp, without directly or indirectly (through dired) using the ls program. Given that, I do not know how to convert the GID to a string. If I understand correctly, then on some operating systems, ls-lisp.el uses numeric UID and GID too. So if it would now be easy convert the GID to the group name from Lisp, then ls-lisp should probably be changed too. (See the comment on line 521 of ls-lisp.el.) My patch _does_ take care of the case where file-attributes actually lists the GID as a string (the current find-lisp code throws an error in that case). A comment in ls-lisp says that this case _can_ occur. Here is my patch: ===File ~/find-lisp-diff *** find-lisp.el09 Nov 2005 17:05:07 -0600 1.10 --- find-lisp.el09 Nov 2005 22:48:11 -0600 *** *** 3,9 ;; Author: Peter Breton ;; Created: Fri Mar 26 1999 ;; Keywords: unix ! ;; Time-stamp: 2005-11-09 22:55:41 teirllm ;; Copyright (C) 1999, 2000, 2002, 2003, 2004, ;; 2005 Free Software Foundation, Inc. --- 3,9 ;; Author: Peter Breton ;; Created: Fri Mar 26 1999 ;; Keywords: unix ! ;; Time-stamp: 2005-11-09 22:48:11 teirllm ;; Copyright (C) 1999, 2000, 2002, 2003, 2004, ;; 2005 Free Software Foundation, Inc. *** *** 309,326 (if (memq ?s switches) ; size in K (format %4d (1+ (/ (nth 7 file-attr) 1024 (nth 8 file-attr) ; permission bits ! ;; numeric uid/gid are more confusing than helpful ! ;; Emacs should be able to make strings of them. ! ;; user-login-name and user-full-name could take an ! ;; optional arg. (format %3d %-8s %-8s %8d (nth 1 file-attr) ; no. of links ! (if (= (user-uid) (nth 2 file-attr)) ! (user-login-name) ! (int-to-string (nth 2 file-attr))); uid (if (eq system-type 'ms-dos) root ; everything is root on MSDOS. ! (int-to-string (nth 3 file-attr))); gid (nth 7 file-attr) ; size in bytes ) (find-lisp-format-time file-attr switches now) --- 309,327 (if (memq ?s switches) ; size in K (format %4d (1+ (/ (nth 7 file-attr) 1024 (nth 8 file-attr) ; permission bits ! ;; numeric gid is more confusing than helpful. ! ;; Emacs should be able to convert it into a string. (format %3d %-8s %-8s %8d (nth 1 file-attr) ; no. of links ! (if (integerp (nth 2 file-attr)) ! (or (user-login-name (nth 2 file-attr)) ! (int-to-string (nth 2 file-attr))) ! (nth 2 file-attr)) ; uid (if (eq system-type 'ms-dos) root ; everything is root on MSDOS. ! (if (integerp (nth 3 file-attr)) ! (int-to-string (nth 3 file-attr)) ! (nth 3 file-attr))) ; gid (nth 7 file-attr) ; size in bytes ) (find-lisp-format-time file-attr switches now) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Can you answer Richard's question, since you are the one proposing the revert? Could you provide a self-contained description of what the issue is? Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Richard Stallman wrote: Perhaps the thing that did not work is what you are fixing now. I do not immediately understand. Nick is proposing to revert the 1998 change and do essentially nothing else, so any problem the 1998 change fixed will reappear, unless it has been undeliberately fixed in the meantime by some other change. Or was the original problem that for some reason people did not _want_ the results in their *Find* buffers to be automatically changed when the file system changed as a result of operations in another Dired buffer? The only additional thing I could find that might be relevant to the present discussion is that find-lisp.el contains code completely similar to the one in find-dired (see line 191 and following). So _if_ the code in find-dired should be changed, then it seems likely that the one in find-lisp should be changed too, although I did not check this. Quoted from find-lisp.el, starting at line 191: ;; Most of this is lifted from find-dired.el ;; (defun find-lisp-find-dired-internal (dir file-predicate directory-predicate buffer-name) Run find (Lisp version) and go into Dired mode on a buffer of the output. (let ((dired-buffers dired-buffers) Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Nick Roberts wrote:
You appear to have just put back the lines removed from 21.3 and left those
added for 22.0.50.
Yes.
I think the idea of dired-fun-in-all-buffers is to update
correctly when there is more than one dired buffer.
Yes.
So, for example, I don't think your patch will work if one buffer
uses find-dired and another normal dired, and you delete a file
present in both buffers, from the normal dired buffer.
With my patch *Locate* and find{-grep}-dired buffers would only get
updated if the file were deleted in their own buffer. This is not
ideal, but better than the present situation.
For this reason, I think its important that find-dired can add to
dired-buffers.
If I understood correctly, this requires reverting an old change by
Richard. In that case, Richard should tell us whether that is OK or
not. Also did you check that the way you want to do it works
correctly if you delete a file whose directory is not the *Find*
buffer's directory, but a subdirectory of it, that is, a file listed
as subdir/filename?
delete-region could be used for locate, of course,
I guess one could also make dired-fun-in-all-buffers automatically
check all *Locate* buffers, so that *Locate* buffers would also be
updated, even if the file got deleted in another Dired buffer. But
maybe that might be more complicated.
possibly conditioned on major-mode not being dired-mode to make
sure nothing gets deleted twice.
I do not believe that my patch deletes anything twice.
dired-fun-in-all-buffers can not delete anything that is not there any more.
Sincerely,
Luc.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
