Re: html-mode vs inconsistent eol types
Stefan Monnier wrote: > Agreed, and the file contents shouldn't make any difference in this > respect since the file's extension is explicit. But they do, since magic-mode-alist describes itself as overriding auto-mode-alist. Maybe you mean this is a Bad Thing? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Thanks for the test case. I'll try to debug this. Jan D. Stephen Berman skrev: I made the file srb.el (attached) and did the following (again, only with QtCurve in KDE): 1. emacs -Q -l srb.el 2. Moving the mouse over the menu bar in *scratch* does not induce the "sticky" highlighting problem. 3. C-x C-f test.srb brings up a buffer in SRB mode with a menu SRB in the menu bar. When I move the mouse over the menu bar in this buffer, as soon as it moves over and off of SRB the highlighting sticks to this menu bar item. If I switch to *scratch* and then back to test.srb, the sticky highlighting is gone, but I get it again by moving the mouse over and off of SRB. I can repeat this ad infinitum. I can also reliably get the sticky highlighting with the following recipe: 1. emacs -Q 2. Moving the mouse over the menu bar in *scratch* does not induce the "sticky" highlighting problem. 3. Do `M-x gnus RET y RET y RET n' to get the Gnus *Group* buffer. When I move the mouse over the menu bar, the four menues Gnus, Groups, Group, Agent get "sticky" highlighting. 4. If I now switch back to *scratch* and move the mouse over the menu bar, the Edit menu gets sticky highlighting. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Richard Stallman wrote: > So there are two bugs here, one in nxml-mode and one in the elisp Info > manual. What do you think is a bug in the Emacs Lisp Reference Manual? Where is it? There is no bug in the manual. Johan Bockgård pointed out I was reading the wrong section in the manual. But it would help with links between description of `modification-hooks' for text and overlays, since they are a bit different. ___ 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
Luc Teirlinck <[EMAIL PROTECTED]> writes: >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? 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. The interactive operation is the same either way (the only difference being whether certain operations are done in the function body or the (interactive...) form). The only real difference as far as I can see is how the arguments are "captured" and re-used with `C-x ESC ESC' -- and your patch changes that behavior anyway (by capturing the state of current-prefix-arg instead of using the current value when C-x ESC ESC is used). The differences between your patch and what I'm suggesting only occur when the user does something weird: Invokes "locate" interactively, then _changes_ the value of locate-prompt-for-command, and attempts to re-invoke locate using `C-x ESC ESC'. I don't think either behavior is obviously more correct, so it seems reasonable to pick the cleanest in this case. -Miles -- A zen-buddhist walked into a pizza shop and said, "Make me one with everything." ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: filling long html href
> I think a regexp matching anything except a given set of literals can be > built mechanically (does someone have something to do that?). In theory, yes, but IIRC the resulting regexp may be of a size exponential w.r.t the size of the literals ;-( I believe in practice it's not going to be exponential, but it may still be fairly big&ugly. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: html-mode vs inconsistent eol types
> In my recent cvs build, visiting the api.html file below selects > xml-mode, where I hoped to get html-mode (or the xhtml variant > thingie). Agreed, and the file contents shouldn't make any difference in this respect since the file's extension is explicit. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc string of compilation-next-error
> Shouldn't the doc string mention what the return value is? At least > one use of the function in the Emacs source code makes use of this > value: > (let* ((columns compilation-error-screen-columns) ; buffer's local value >(last 1) >(loc (compilation-next-error (or n 1) nil > (or compilation-current-error > compilation-messages-start > (point-min >(end-loc (nth 2 loc)) >(marker (point-marker))) > ...) This code is in compilation-next-error-function, so it's safe to say that this is an internal use, in which case it may rely on non-documented behaviors. I.e. I don't see any need to document this return value, unless it seems it might be useful for some non-internal code. Stefan ___ 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
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
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
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > New patch identical to the last one, except for a trivial one-line > docstring change in `locate-with-filter': 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? Such toggling behavior is convenient for interactive use, but it often doesn't make much sense for the programmatic function interface. 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.] -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein ___ 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: ___ 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)
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: Strange undo problem
> So there are two bugs here, one in nxml-mode and one in the elisp Info > manual. What do you think is a bug in the Emacs Lisp Reference Manual? Where is it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
> I think for the reason above that it should be buffer local and I also > think that it should be permanent buffer local then. I think this wouldn't make much sense since `buffer-undo-list' isn't permanently buffer-local either. It is, practically speaking. It is buffer-local, and changing major modes does not clear it out. ___ 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 saw that the _new_ behavior of locate-with-filter (after my previous suggested patch) was not really consistent with its docstring, e.g.: This function is similar to the function `locate', which see. The difference is that, when invoked interactively, the present function prompts for both SEARCH-STRING and FILTER. and: When called from Lisp, this function is identical with `locate', except that FILTER is not optional. Al this was no longer really true after my previously proposed patch, but it is after the following revised version, which also eliminates misfeatures that remained after my previous patch. The new patch is not really as extensive as it looks: it copies the biggest part of the interactive declaration of locate into a separate function, so that it can be reused without code duplication in locate-with-filter, which _should_ use exactly the same prompt for SEARCH-STRING. The new function guarantees this. The new patch also keeps the old Emacs-21 de facto behavior of locate-with-filter, that is, it still respects an interactive arg. Unlike what I thought before, the old docstring actually _did_ suggest that it did, which is why it is better to keep that feature. ===File ~/locate-diff-6= *** locate.el 21 Apr 2007 00:00:52 -0500 1.42 --- locate.el 22 Apr 2007 21:59: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) *** *** 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
Re: C- doesn't respect current keyboard layout, OS X Carbon
> On Mon, 23 Apr 2007 00:36:03 +0200, Aidan Kehoe <[EMAIL PROTECTED]> said: > I'm running on Mac OS X 10.4.7, under a German-language install. The > default software keyboard layout associated with the installed > system, and indeed my physical hardware, is also German. However, > I've installed a variant of the OS X Irish layout (which is itself a > variant of the British layout) and that is the currently active > keyboard layout. In the input menu, the only other available > keyboard is a British (UK) layout. No other account has the German > keyboard available. > When I type normally, this layout is respected. However, when I use > the control key, it is not, and instead the German layout is > used. I don't have German keyboards and I can't reproduce this with my US keyboard. Could you see if each of the following setting/patch changes the behavior? 1) (setq mac-pass-control-to-system nil) 2) Patch to macterm.c: Index: src/macterm.c === RCS file: /cvsroot/emacs/emacs/src/macterm.c,v retrieving revision 1.214 diff -c -p -r1.214 macterm.c *** src/macterm.c 13 Apr 2007 08:14:03 - 1.214 --- src/macterm.c 23 Apr 2007 02:01:01 - *** XTread_socket (sd, expected, hold_quit) *** 11321,11326 --- 11321,11331 UniChar code; UniCharCount actual_length; + #if USE_CARBON_EVENTS + GetEventParameter (eventRef, kEventParamKeyboardType, + typeUInt32, NULL, + sizeof (UInt32), NULL, &keyboard_type); + #endif status = UCKeyTranslate (uchr_ptr, keycode, key_action, modifier_key_state, YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ 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: html-mode vs inconsistent eol types
Kevin Ryde wrote: > I suspect it's because the file has a mixture of end-of-line types. > The first line is LF, but the second and subsequent are CRLF. > Obviously that's fairly bogus, but it'd be nice if emacs content > matching could tolerate it. OK, the magic-mode-alist entry now tolerates carriage-returns, since that seems harmless. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Dave Love wrote: > I explained it to rms, but he wouldn't do anything bug reports > without patches. I can't parse this. > I doubt anyone else can say anything useful unless they're privy to > legal advice, but I haven't been asked for details. Why are you > querying this? Can you give legal advice? I queried this because you sent it to the emacs-pretest-bug mailing list, which is not rms's personal mail account, and I had no clue what you meant, nor could I find anything in the list archives. I got the impression your email was for a specific target, hence the first sentence of my reply. Since rms often takes a day or so to reply, I hoped to speed things along my getting more info. I cannot give legal advice. > There are potential problems due to my previous employer with things > I wrote until I left in April 2006. I'm contractually obliged to > inform the FSF about that, whether or not I consider it spurious or > actually care about GNU. I for one am grateful to you for informing us. >> The python.el in CVS Emacs is the one you submitted to >> gnu-emacs-sources here: > > ?? It's clearly substantially different. The original surely won't > even work in the development Emacs. My intended meaning was "in CVS Emacs is [derived from] the one..." >> Another fix: >> http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-03/msg00441.html > > How could that be a copyright issue? I didn't supply any code, on > purpose. I had no idea what your point was, so I just dredged up all discussions about python.el, in an attempt to speed things along. > There's a changelog entry from then with my name on it, but it isn't > mine, which should be a concern anyway. Some or all of that addition > is problematic and I haven't checked any subsequent changes. I'm > asking why it and anything else was grabbed and put in without > consulting me and whether it's clear there's no problem. It was installed by Stefan. I can't speak for him, but I imagine since he's the person who installed your python.el initially, and subsequent fixes from you, that he got the impression that there was no problem installing updates from your version (which I guess is on the web somewhere?). > (It's pretty annoying to have the code forked and then have people > complain to me about bugs, but I'm sure I won't get anywhere on that.) I'm sorry if people complain to you about bugs that aren't your fault. There is nothing in the python.el in CVS Emacs that says bug reports should be sent to you. It lists maintainer as "FSF". >> There are two long threads about python.el from August 2006 that start >> here and here: >> http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00353.html >> http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00758.html > > I haven't read them; are they relevant? Probably not. I guess these discussions might be what prompted Stefan to check for updates to your python.el. > However, my original compilation mode support was broken by > subsequently changes in the development Emacs, and I gave up trying > to track the general breakage to python.el some time ago. Perhaps it > no longer works, unlike the Emacs 21 version I use. Anyhow, that's a > side issue that I don't suppose people are interested in hearing > about. If something in Emacs does not work, bug reports about it are welcome. If changes in some part of Emacs break another, that's bad, but it can't be fixed if no-one mentions it. Anyway, back to the topic at hand: there's a potential legal problem with python.el. Is all the code you wrote for python.el affected, or just the 2006-08-20 changes? Before that, there are no changes from python.el from you until we get to 2004-12-02. If it's just the 2006-08-20 stuff: Stefan, is there anyway this can easily be removed and still leave a working python.el? Dave, would that be acceptable to you? Otherwise, our only recourse AFAICS is to remove python.el before the (imminent) release of Emacs 22. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Display problems with overlays (on w32 only?)
In the attached images I have one overlay one character long that has a red underline. In the first picture there is only this overlay at that point and the display is correct. In the second picture I have added another overlay, with a slightly blue background. This overlay is 10 characters long and includes a new line. The first overlay with the red underline is still just one character long, but the red underline now displays in the whole range of the second overlay. (The two oeverlays starts at the same character.) Is this perhaps a simple typo somewhere in the display code? Here is the output from C-u C-x = character: C-j (10, #o12, #xa, U+000A) charset: ascii (ASCII (ISO646 IRV)) code point: #x0A syntax:which means: whitespace buffer code: #x0A file code: #x0A (encoded by coding system undecided-unix) display: by this font (glyph code) -outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1 (#x0A) There are 2 overlays here: From 786 to 787 category rng-error help-echo" And the output when clicking on rng-error: Category rng-error: face rng-error-face modification-hooks (rng-error-modified) [back] > Dito mumamo-background-chunk-submode: Face: mumamo-background-chunk-submode (sample) (customize this face) Documentation: Background colors for chunks in major mode. You should only specify :background here, otherwise it will interfere with syntax highlighting. FIX-ME: background colors for dark cases. Defined in `mumamo.el'. Family: unspecified Width: unspecified Height: unspecified Weight: unspecified Slant: unspecified Foreground: unspecified Background: azure Underline: unspecified Overline: unspecified Strike-through: unspecified Box: unspecified Inverse: unspecified Stipple: unspecified Font or fontset: unspecified Inherit: unspecified [back] > In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-22 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Indentation bug in html-mode
The attached file is valid XHTML 1.1 but indents badly because of the < inte part. I paste it here for simplicity too: http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en"> Indentation bug at < In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-22 Title: Indentation bug at < ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: filling long html href
Richard Stallman <[EMAIL PROTECTED]> writes: > > Can you figure out a convention for how to write the tags so as to > indicate which ones should break paragraphs. I'd be inclined to make paragraph-start match all tags (as it does now) except the ones described as "text level" elements by the specs, like etc, because they're not paragraph breaks in the resulting browser display. Not that the html source layout has to match the displayed layout, but it's a sensible starting point. I think a regexp matching anything except a given set of literals can be built mechanically (does someone have something to do that?). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
On Sun, 22 Apr 2007 20:36:31 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote:
> Stephen Berman skrev:
>> On Sun, 22 Apr 2007 12:58:46 +0200 "Franz Häuslschmid" <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Using the GTK build, it always happens that menus entries of the menu
>>> bar, that are dynamically added or removed depending on the currently
>>> active frame (e.g. Gnus or AUCTeX), stay highlighted when the mouse
>>> cursor moves over them. As I am writing this text and having moved the
>>> mouse cursor over all items of the menu bar, the menus "Edit", "Headers"
>>> and "Mail" are highlighted. This accentuation of menus is lost, when I
>>> switch to another buffer not having those menus associated.
>>
>> I have noticed the same thing with my Emacs (currently GNU Emacs
>> 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-20 but
>> I've noticed this for a long time), but only when running under KDE
>> using the GTK Style QtCurve. This is on openSUSE 10.2 using kcm_gtk,
>> "the KDE control module for switching GTK+ style", which I think is
>> the openSUSE substitute for (or version of) the gtk-qt engine. I
>> attach a picture showing the problem.
>
> It looks bad indeed. However, this is all done in Gtk+, I don't even have a
> theme that highlights the menu bar like that. Does only QtCurve do that? Or
> are there other Gtk+-themes that highlights like that but doesn't have the
> same problem?
I tried all the GTK Styles available by default in openSUSE 10.2 KDE
(Personal Settings -> Appearance & Themes -> GTK Styles and Fonts),
and in addition to QtCurve the following also highlight the menu names
when the mouse moves over them: Glider, HighContrast,
HighContrastInverse, HighContrastLargePrint,
HighContrastLargePrintInverse, Redmond. However, I observe the
"sticky" highlighting problem only with QtCurve.
> The GNUS menus are defined with easy-menu, thats about all I can think of that
> differs from "regular" menus. Can you define a small menu with easy.menu and
> see if the problem is there then?
I made the file srb.el (attached) and did the following (again, only
with QtCurve in KDE):
1. emacs -Q -l srb.el
2. Moving the mouse over the menu bar in *scratch* does not induce the
"sticky" highlighting problem.
3. C-x C-f test.srb brings up a buffer in SRB mode with a menu SRB in
the menu bar. When I move the mouse over the menu bar in this buffer,
as soon as it moves over and off of SRB the highlighting sticks to
this menu bar item. If I switch to *scratch* and then back to
test.srb, the sticky highlighting is gone, but I get it again by
moving the mouse over and off of SRB. I can repeat this ad infinitum.
I can also reliably get the sticky highlighting with the following
recipe:
1. emacs -Q
2. Moving the mouse over the menu bar in *scratch* does not induce the
"sticky" highlighting problem.
3. Do `M-x gnus RET y RET y RET n' to get the Gnus *Group* buffer.
When I move the mouse over the menu bar, the four menues Gnus, Groups,
Group, Agent get "sticky" highlighting.
4. If I now switch back to *scratch* and move the mouse over the menu
bar, the Edit menu gets sticky highlighting.
Steve Berman
(defvar srb-mode-map
(let ((map (make-keymap)))
map)
"SRB mode keymap.")
(easy-menu-define srb-menu srb-mode-map "SRB Menu"
'("SRB"))
(defun srb-mode ()
(interactive)
(kill-all-local-variables)
(setq major-mode 'srb-mode)
(setq mode-name "SRB")
(use-local-map srb-mode-map)
(easy-menu-add srb-menu))
(add-to-list 'auto-mode-alist '("\\.srb\\'" . srb-mode))
(provide 'srb)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C- doesn't respect current keyboard layout, OS X Carbon
Dear Bug Team!
I'm running on Mac OS X 10.4.7, under a German-language install. The default
software keyboard layout associated with the installed system, and indeed my
physical hardware, is also German. However, I've installed a variant of the
OS X Irish layout (which is itself a variant of the British layout) and that
is the currently active keyboard layout. In the input menu, the only other
available keyboard is a British (UK) layout. No other account has the German
keyboard available.
When I type normally, this layout is respected. However, when I use the
control key, it is not, and instead the German layout is used. Some
examples:
- The key with the label ü, which sends [ to every app on the system,
sends C-ü to this emacs build when pressed at the same time as the
control key, , and consequently I get a message "C-ü is undefined."
The same key sends [ to this emacs when pressed on its own, or in
combination with shift, or Meta.
- The key with the label z, which sends y to every app on the system,
sends C-z to this emacs build when pressed at the same time as the
control key, and as a result minimises the program instead of
pasting (or "yanking" if you prefer). The same key sends y to this
emacs when pressed on its own, or in combination with another
modifier.
- The key labelled 6 (unshifted) and & (shifted) sends 6 (unshifted)
and ^ (shifted) to every app on the system. However, when pressed in
combination with shift and control, this emacs receives it as C-&,
and I get the message C-& is undefined.
In general, this is annoying and unexpected. Though it is a diverting
surprise to see an app fall back, incorrectly, to something other than the
US layout.
Best regards,
Aidan Kehoe
In GNU Emacs 22.0.92.1 (i386-apple-darwin8.7.1, Carbon Version 1.6.0)
of 2007-04-23 on bonbon
X server distributor `Apple Computers', version 10.4.7
configured using `configure '--enable-carbon-app''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: de_DE.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
encoded-kbd-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
y o n c e SPC y p
u p o n SPC a SPC i t
t SPC t i m e SPC
C-z
l C-yk C-ü
x r e p o r t - e m a c s - b u g
C-g {
[ p
C-p SPC C-ü C-+ C-ä C-p C-p x
p
Recent messages:
Type C-x 1 to remove help window.
Mark set
Loading subst-ksc...done
Loading subst-gb2312...done
Loading subst-big5...done
Loading subst-jis...done
C-ü is undefined
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
Quit
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
html-mode demanding a bit too tight
In a recent build of the cvs, visiting the file minimal.html below selects sgml-mode, where I hoped to get html-mode. According to the (version 3.2) spec at http://www.w3.org/TR/REC-html32-19970114#html (the end of the "Structure of HTML" section) it's a valid minimal html, so it'd be nice if it was recognised. If I'm not mistaken the html-mode regexp in magic-mode-alist demands a "Title: A study of population dynamics ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Help buffer links on a console
On a linux console and using t-mouse, clicking on a link in a help buffer only works if the cursor is already over the link. Otherwise Emacs reports "No cross-reference here" which indicates that help-follow-mouse has been activated, rather than push-button. Typing `C-h c' and clicking as before, however, tells the user that push-button will be activated. Also clicking works properly both on a graphical display and an xterm. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
html-mode vs inconsistent eol types
In my recent cvs build, visiting the api.html file below selects xml-mode, where I hoped to get html-mode (or the xhtml variant thingie). I suspect it's because the file has a mixture of end-of-line types. The first line is LF, but the second and subsequent are CRLF. Obviously that's fairly bogus, but it'd be nice if emacs content matching could tolerate it. If the mail system has munged the file contents it's from http://www.imagemagick.org/www/api.html or in debian /usr/share/doc/imagemagick/www/api.html In GNU Emacs 22.0.98.2 (i586-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-04-18 on blah configured using `configure 'CFLAGS=-O' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_AU locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Title: ImageMagick: Application Program Interfaces Skip to page contents [ About ImageMagick Command-line Tools Program Interfaces ][ Install from Source Binary Releases Resources ][ Download ][ Links ][ Sponsors Solutions for e- andm-commerce ] [C | Ch | C++ | Java | Perl | PHP | Python | Ruby | Tcl/TK ] ImageMagick includes a number of ready-made ImageMagick interfaces. This makes it possible to modify or create images automatically and dynamically. C Use MagickWand to convert, compose, and edit images from the C language. There is also the low-level MagickCore library but is only recommended for wizard-level developers. Ch ChMagick is a Ch binding to the MagickCore and MagickWand API. Ch is an embeddable C/C++ interpreter for cross-platform scripting. C++ Magick++ provides an object-oriented C++ interface to ImageMagick. Java JMagick provides an object-oriented Java interface to ImageMagick. Perl Use PerlMagick to convert, compose, and edit images from the Perl language. PHP MagickWand for PHP a native PHP-extension to the ImageMagick MagickWand API. Python PythonMagick an object-oriented Python interface to ImageMagick. Ruby RMagick is an interface between the Ruby programming language and the ImageMagick image processing libraries. RMagick has a 2D drawing library add-on, RVG, based on the Scalable Vector Graphics specification. Tcl/Tk TclMagick a native Tcl-extension to the ImageMagick MagickWand API. Discourse Server | Mailing Lists | Image Gallery | ImageMagick Studio © 1999-2005 ImageMagick Studio LLC ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Info-scroll-up/down on mode-line
Info-scroll-up/down are bound on the mode-line (over the node name) to mouse-1 and mouse-3. However, in a split window configuaration with Info at the top and the bottom window selected, clicking there scrolls the _bottom_ window, and Emacs gets confused if this is already at the top or bottom. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Glenn Morris <[EMAIL PROTECTED]> writes: > Maybe this message is meant for some specific recipients who will > already know what this is about. I explained it to rms, but he wouldn't do anything bug reports without patches. I doubt anyone else can say anything useful unless they're privy to legal advice, but I haven't been asked for details. Why are you querying this? Can you give legal advice? > If not, please could you explain in more detail what you mean? There are potential problems due to my previous employer with things I wrote until I left in April 2006. I'm contractually obliged to inform the FSF about that, whether or not I consider it spurious or actually care about GNU. > The python.el in CVS Emacs is the one you submitted to > gnu-emacs-sources here: ?? It's clearly substantially different. The original surely won't even work in the development Emacs. > Another fix: > http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-03/msg00441.html How could that be a copyright issue? I didn't supply any code, on purpose. > The only other sizable change from you for python.el seems to be > from 2006-08-20. I can't find any mail about this. Is this one the > problem? There's a changelog entry from then with my name on it, but it isn't mine, which should be a concern anyway. Some or all of that addition is problematic and I haven't checked any subsequent changes. I'm asking why it and anything else was grabbed and put in without consulting me and whether it's clear there's no problem. (It's pretty annoying to have the code forked and then have people complain to me about bugs, but I'm sure I won't get anywhere on that.) > There are two long threads about python.el from August 2006 that start > here and here: > http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00353.html > http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00758.html I haven't read them; are they relevant? > Here are some assignment-related comments from Ken Manheimer: > http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00753.html I don't think that's necessary -- see the python.el commentary, which he obviously hasn't read. However, my original compilation mode support was broken by subsequently changes in the development Emacs, and I gave up trying to track the general breakage to python.el some time ago. Perhaps it no longer works, unlike the Emacs 21 version I use. Anyhow, that's a side issue that I don't suppose people are interested in hearing about. python.el was done partly because we couldn't get an assignment for python-mode.el and because the maintainers wouldn't accept Emacs-specific fixes. I wouldn't have written more if I thought it was going to be pulled in with potential legal problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell and abbrev
From: Glenn Morris <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: emacs-pretest-bug@gnu.org, emacs user <[EMAIL PROTECTED]> Subject: Re: flyspell and abbrev Date: Sat, 21 Apr 2007 20:17:45 -0400 For now, I installed the flyspell change. I suggest we think about the wider issue after the release. it's fine now! thanks for the prompt fix! cheers, EU _ Download Messenger. Join the im Initiative. Help make a difference today. http://im.live.com/messenger/im/home/?source=TAGHM_APR07 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell and abbrev
From: Richard Stallman <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Glenn Morris <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Subject: Re: flyspell and abbrev Date: Sun, 22 Apr 2007 12:35:57 -0400 Beyond that, given the way expand-abbrev treats case, does it make any sense for define-abbrev to allow you to define an abbrev without downcasing it? They don't seem to work at all, eg: Let's document this. Could someone please do so? I think I missed part of the discussion on which I wasn't copied, but I think it is clear that in the context of spell checking for which the abbrev thing is (also) used, it makes sense to allow correcting CHo to Cho or such. _ Interest Rates NEAR 39yr LOWS! $430,000 Mortgage for $1,299/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-19132&moid=14888 ___ 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
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: 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
Success on Sun/SPARC under Solaris "Nevada" b60
This is just to report that I have built 22.0.98 with GTK+ support on Solaris "Nevada" (between Solaris 10 and 11) build 60 in both 32- and 64-bit mode, using Sun's C compiler. The build process was flawless, and I have been using the 64-bit version for several days without any issues. (I still get a coredump in libcairo when I try to run over X to my Debian GNU/Linux laptop. My theory is that my laptop's X11/GNOME installation is somewhat hosed in the fonts department, so I don't blame Emacs. If anything, Cairo should be more robust. Remote display to my home PC running Ubuntu GNU/Linux works just fine.) Best regards, -- Simon. In GNU Emacs 22.0.98.1 (sparc-sun-solaris2.11, GTK+ Version 2.10.6) of 2007-04-18 on diotima configured using `configure '--prefix=/usr/local' '--without-gcc' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-gtk' '--enable-font-backend' '--with-xft' '--libdir=/usr/local/lib/sparcv9' 'CC=/opt/SUNWspro/bin/cc' 'CFLAGS=-fast -xtarget=ultra -xarch=v9 -g -xs' 'LDFLAGS=-xarch=v9' 'CPP=/opt/SUNWspro/bin/cc -Xs -E'' ___ 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: GTK build: some menus in the menu bar stay highlighted
Stephen Berman skrev: > On Sun, 22 Apr 2007 12:58:46 +0200 "Franz Häuslschmid" <[EMAIL PROTECTED]> > wrote: > >> Using the GTK build, it always happens that menus entries of the menu >> bar, that are dynamically added or removed depending on the currently >> active frame (e.g. Gnus or AUCTeX), stay highlighted when the mouse >> cursor moves over them. As I am writing this text and having moved the >> mouse cursor over all items of the menu bar, the menus "Edit", "Headers" >> and "Mail" are highlighted. This accentuation of menus is lost, when I >> switch to another buffer not having those menus associated. > > I have noticed the same thing with my Emacs (currently GNU Emacs > 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-20 but > I've noticed this for a long time), but only when running under KDE > using the GTK Style QtCurve. This is on openSUSE 10.2 using kcm_gtk, > "the KDE control module for switching GTK+ style", which I think is > the openSUSE substitute for (or version of) the gtk-qt engine. I > attach a picture showing the problem. It looks bad indeed. However, this is all done in Gtk+, I don't even have a theme that highlights the menu bar like that. Does only QtCurve do that? Or are there other Gtk+-themes that highlights like that but doesn't have the same problem? The GNUS menus are defined with easy-menu, thats about all I can think of that differs from "regular" menus. Can you define a small menu with easy.menu and see if the problem is there then? Thanks, Jan D. ___ 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
doc string of compilation-next-error
Shouldn't the doc string mention what the return value is? At least one use of the function in the Emacs source code makes use of this value: (let* ((columns compilation-error-screen-columns) ; buffer's local value (last 1) (loc (compilation-next-error (or n 1) nil (or compilation-current-error compilation-messages-start (point-min (end-loc (nth 2 loc)) (marker (point-marker))) ...) In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ 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
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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
If those calls are done in different buffers it looks like trouble to me. Should not pending-undo-list be buffer local? I think for the reason above that it should be buffer local and I also think that it should be permanent buffer local then. Maybe so, but in normal Emacs it won't be used again if you switch buffers. So we can leave this alone for now. After the release, let's do what you suggest. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell and abbrev
Beyond that, given the way expand-abbrev treats case, does it make any sense for define-abbrev to allow you to define an abbrev without downcasing it? They don't seem to work at all, eg: Let's document this. Could someone please do so? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
On Sun, 22 Apr 2007 12:58:46 +0200 "Franz Häuslschmid" <[EMAIL PROTECTED]> wrote: > Using the GTK build, it always happens that menus entries of the menu > bar, that are dynamically added or removed depending on the currently > active frame (e.g. Gnus or AUCTeX), stay highlighted when the mouse > cursor moves over them. As I am writing this text and having moved the > mouse cursor over all items of the menu bar, the menus "Edit", "Headers" > and "Mail" are highlighted. This accentuation of menus is lost, when I > switch to another buffer not having those menus associated. I have noticed the same thing with my Emacs (currently GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-20 but I've noticed this for a long time), but only when running under KDE using the GTK Style QtCurve. This is on openSUSE 10.2 using kcm_gtk, "the KDE control module for switching GTK+ style", which I think is the openSUSE substitute for (or version of) the gtk-qt engine. I attach a picture showing the problem. Steve Berman menu-bar-display5.png Description: multiple highlighted menu entries ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redisplay
On Sat, 21 Apr 2007 20:47:19 -0400 Richard Stallman <[EMAIL PROTECTED]> wrote:
> (progn (new-frame)
> (redisplay t)
> (x-popup-dialog t '("Foo" ("Bar" . 1
>
> I tried this but it didn't fail -- the new frame was not empty.
In my Emacs (GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version
2.10.6) of 2007-04-20 on escher) I see two behaviors:
1. Evalling the above sexp in *scratch* with C-j or in any buffer with
M-: results in what the OP reported: "produces a blank frame while the
popup dialog is active, i.e., (redisplay t) fails to wait for
redisplay to finish."
2. Evalling the sexp with C-x C-e in any buffer results in what RMS
reported.
Steve Berman
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Johan Bockgård wrote: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: And in elisp Info: That is, (info "(elisp)Special Properties") `modification-hooks' If a character has the property `modification-hooks', then its value should be a list of functions; modifying that character calls all of those functions. Each function receives two arguments: the beginning and end of the part of the buffer being modified. Note that if a particular modification hook function Wrong section. Try (info "(elisp)Overlay Properties") `modification-hooks' This property's value is a list of functions to be called if any character within the overlay is changed or if text is inserted strictly within the overlay. Ah, thanks. Looks much better ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: > And in elisp Info: That is, (info "(elisp)Special Properties") > `modification-hooks' > If a character has the property `modification-hooks', then its > value should be a list of functions; modifying that character > calls all of those functions. Each function receives two > arguments: the beginning and end of the part of the buffer being > modified. Note that if a particular modification hook function Wrong section. Try (info "(elisp)Overlay Properties") `modification-hooks' This property's value is a list of functions to be called if any character within the overlay is changed or if text is inserted strictly within the overlay. The hook functions are called both before and after each change. If the functions save the information they receive, and compare notes between calls, they can determine exactly what change has been made in the buffer text. When called before a change, each function receives four arguments: the overlay, `nil', and the beginning and end of the text range to be modified. When called after a change, each function receives five arguments: the overlay, `t', the beginning and end of the text range just modified, and the length of the pre-change text replaced by that range. (For an insertion, the pre-change length is zero; for a deletion, that length is the number of characters deleted, and the post-change beginning and end are equal.) If these functions modify the buffer, they should bind `inhibit-modification-hooks' to `t' around doing so, to avoid confusing the internal mechanism that calls these hooks. -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Lennart Borgman (gmail) wrote: So there are two bugs here, one in nxml-mode and one in the elisp Info manual. And BTW the "bug" in nxml-mode was that the variable rng-error-count did not have the property 'permanent-local t. And that was what my code needed there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
GTK build: some menus in the menu bar stay highlighted
Using the GTK build, it always happens that menus entries of the menu bar, that are dynamically added or removed depending on the currently active frame (e.g. Gnus or AUCTeX), stay highlighted when the mouse cursor moves over them. As I am writing this text and having moved the mouse cursor over all items of the menu bar, the menus "Edit", "Headers" and "Mail" are highlighted. This accentuation of menus is lost, when I switch to another buffer not having those menus associated. [...] In GNU Emacs 22.0.98.1 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-21 on flora Windowing system distributor `The X.Org Foundation', version 11.0.70199902 configured using `configure '--prefix=/home/haeuslsc/local' '--with-gtk' 'CFLAGS=-O3 -march=athlon-xp'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: show-paren-mode: t delete-selection-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: Recent messages: Loading delsel...done Loading paren...done Loading /home/haeuslsc/.xemacs/init.el (source)... Loading easymenu...done Loading places from /home/haeuslsc/.emacs-places...done Loading derived...done Loading /home/haeuslsc/.xemacs/local.el (source)...done Loading /home/haeuslsc/.xemacs/init.el (source)...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Lennart Borgman (gmail) wrote: Lennart Borgman (gmail) wrote: I just saw a very strange undo problem. I have no simple way to reproduce it, but I can frame it a bit. Lock at the backtrace below: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) rng-error-modified(# t 777 777 85) primitive-undo(2 (nil (777 . 862) (t 17963 . 2531))) undo-more(2) undo() call-interactively(undo) Doesn't it look strange that rng-error-modified (from the nxml-mode package) is the first thing on the backtrace, before primitive-undo? I think I am beginning to understand. I found these lines in the nxml-mode files: (put 'rng-error 'modification-hooks '(rng-error-modified)) (defun rng-error-modified (overlay after-p beg end &optional pre-change-len) And in elisp Info: `modification-hooks' If a character has the property `modification-hooks', then its value should be a list of functions; modifying that character calls all of those functions. Each function receives two arguments: the beginning and end of the part of the buffer being modified. Note that if a particular modification hook function It seems like rng-error-modified does not have the correct format for the new Emacs 22. Is there anyone who knows if this was a change in Emacs 22? Eh, but wait a minute ... - The traceback indicates that the elisp Info is wrong here, or? Actually the parameter spec to rng-error-modified seems ok, but it gets an # that it does not check. So there are two bugs here, one in nxml-mode and one in the elisp Info manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Lennart Borgman (gmail) wrote: I just saw a very strange undo problem. I have no simple way to reproduce it, but I can frame it a bit. Lock at the backtrace below: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) rng-error-modified(# t 777 777 85) primitive-undo(2 (nil (777 . 862) (t 17963 . 2531))) undo-more(2) undo() call-interactively(undo) Doesn't it look strange that rng-error-modified (from the nxml-mode package) is the first thing on the backtrace, before primitive-undo? I think I am beginning to understand. I found these lines in the nxml-mode files: (put 'rng-error 'modification-hooks '(rng-error-modified)) (defun rng-error-modified (overlay after-p beg end &optional pre-change-len) And in elisp Info: `modification-hooks' If a character has the property `modification-hooks', then its value should be a list of functions; modifying that character calls all of those functions. Each function receives two arguments: the beginning and end of the part of the buffer being modified. Note that if a particular modification hook function It seems like rng-error-modified does not have the correct format for the new Emacs 22. Is there anyone who knows if this was a change in Emacs 22? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
martin rudalics wrote: > If those calls are done in different buffers it looks like trouble to > me. Should not pending-undo-list be buffer local? Not by default. If you want to write a function which say, tries to undo changes simultaneously in two or more buffers in some lock-step fashion, you can always make it local yourself (and probably `undo-in-region' as well). > I think for the reason above that it should be buffer local and I also > think that it should be permanent buffer local then. I think this wouldn't make much sense since `buffer-undo-list' isn't permanently buffer-local either. Maybe this is a stupid test, but it looks like buffer-undo-list at least does not get killed by kill-all-local-variables, and that is what 'permanent-local is for: (let ((undo-list-copy (undo-copy-list buffer-undo-list))) (kill-all-local-variables) (equal undo-list-copy buffer-undo-list)) Too me it looks bad that pending-undo-list is not permanent buffer local. And of course all other variables that should reflect the undo state in the buffer. But it depends a bit on how they are used. I can not think of any reason why they should not be permanent buffer local. Can anyone else? Making the buffer local means that there is less chance mixing the values from different buffers up (though it will still be possible using with-current-buffer for example). Making them 'permanent-local t means that they do not get killed when changing major mode. And that is good of course. Are there any other way of killing buffer local variables than calling kill-.*local-.*? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
> If I start with -Q and then set whitespace-global-mode to non-nil and > set both whitespace-check-leading-whitespace and > whitespace-check-indent-whitespace to nil, leading sequences of 8 spaces > still get highlighted. What happens if you set (customize) `whitespace-check-indent-whitespace' _before_ you toggle `whitespace-global-mode'? > I see. But I think this has gotten sidetracked from the real bug that > was introduced here. Indeed, the fact that > whitespace-check-indent-whitespace has never done what I want is exactly > the reason I have it set to nil (along with > whitespace-check-leading-whitespace; I'm not clear on how these two > differ). `whitespace-check-leading-whitespace' only serves for removing leading empty lines from the buffer, hence it doesn't enter here. > So the bug that has been introduced recently is whatever causes > whitesapce checking to flag indentation whitespace even though > whitespace-check-indent-whitespace is nil. I'm not sure what you mean here. Above you said that it "has never done what you want" here you talk about a recently introduced bug. Please tell me whether and when this worked correctly. I could try to track the changes that occurred since then. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
> If those calls are done in different buffers it looks like trouble to > me. Should not pending-undo-list be buffer local? Not by default. If you want to write a function which say, tries to undo changes simultaneously in two or more buffers in some lock-step fashion, you can always make it local yourself (and probably `undo-in-region' as well). > I think for the reason above that it should be buffer local and I also > think that it should be permanent buffer local then. I think this wouldn't make much sense since `buffer-undo-list' isn't permanently buffer-local either. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange undo problem
I just saw a very strange undo problem. I have no simple way to reproduce it, but I can frame it a bit. Lock at the backtrace below: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) rng-error-modified(# t 777 777 85) primitive-undo(2 (nil (777 . 862) (t 17963 . 2531))) undo-more(2) undo() call-interactively(undo) Doesn't it look strange that rng-error-modified (from the nxml-mode package) is the first thing on the backtrace, before primitive-undo? The problem is very reproduceable for me, it happens every time I call undo in a certain situation. I can give more detail instructions on how to reproduce this problem if someone is interested. It is not complicated to do that, but quite many things are involved. Maybe a bit of the problem is the look of the backtrace? rng-error-modified is part of the rng validation package that comes with nxml-mode. The validation is running with idle timers. It uses a defmacro similar to save-buffer-state in font-lock.el when it modifies the faces in the buffer. It does that during validation and validation is triggered by changes in the buffer. I am sure that a lot of validation takes place right after the undo. I can not see how it can interfere with undo however. Or at least I can not see how it can do that if the Emacs timers all run within the lisp w32 thread of Emacs on w32. (If however w32 timers are used the situation is very, very different. I think I asked about if such timers were used long ago, but I can't remember I got any clear answer to that.) A problem is that I do not know what to do with this. The "undo information" in the buffer seems corrupt after the above traceback. In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Debugger Minor modes in effect: nxhtml-global-validation-header-mode: t appmenu-mode: t emacsw32-mode: t mlinks-mode: t indent-region-mode: t swbuff-y-mode: t which-function-mode: t show-paren-mode: t recentf-mode: t cua-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: M-x m u m a m o - m o d e j j j j j j j j j j j j j j A M-x n x m l - c o m p l e t e u C-a C-c C-x 5 2 h Recent messages: Loading sgml-mode...done Loading c:/emacs/u/070422/emacsw32/nxml/nxhtml/php-mode.el (source)...done `<' that is not markup must be entered as `<' Loading c:/emacs/u/070422/emacsw32/nxml/nxhtml/javascript.el (source)...done undo! Loading debug...done Entering debugger... Mark set [2 times] Type C-x 1 to remove help window. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
