Re: Quitting `save-buffer' loses backup file
Richard M. Stallman wrote: I am not convinced this is a wrong outcome for quitting in the middle of saving. However, pressing C-g is a natural panic reaction when the *Warning* buffer pops up. And the warning says: [...] Select one of the following safe coding systems, or edit the buffer: [...] If you want to edit the buffer rather than to specify a safe coding system, it is necessary to hit C-g to get rid of the minibuffer. Here is a summary of what Emacs does in the scenario: (a) Before saving bar, Emacs renames bar to bar~, overwriting the old backup in the process, and sets `buffer-backed-up' to t. This is documented in the manual. (b) Emacs tries to save bar but fails to do so, because the user quits. To reduce harm, Emacs renames bar~ back to bar. But -- and this is probably wrong -- Emacs does not set `buffer-backed-up' back to nil. What I get is (a) but not (b). How comes that `buffer-backed-up' is nil then, as you sayed? This is rather strange. Can you please do M-x debug-on-entry rename-file and tell me at which points the debugger pops up in our scenario? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: jit-lock.el functions variables appear undocumented.
My last build where this worked correctly is from 2005-10-20. A build from 2005-11-06 already doesn't have the doc-strings. In between was: 2005-10-31 Dan Nicolaescu [EMAIL PROTECTED] * loadup.el: Load emacs-lisp/syntax, font-lock and jit-lock so that global-font-lock-mode can be enabled by default. * font-lock.el (font-lock-keywords, font-lock-mode-internal) (font-lock-add-keywords, font-lock-remove-keywords) (font-lock-fontify-buffer): Remove autoload cookies. * jit-lock.el (jit-lock-register): Likewise. Coincidentally, in the same period all doc-strings for functions and variables defined in `mwheel' vanished too, maybe related to: 2005-10-28 Richard M. Stallman [EMAIL PROTECTED] ... * loadup.el (facemenu): Load unconditionally. (image, international/fontset, dnd, mwheel, tool-bar): (x-dnd): Load, when appropriate. but - strangely enough - dnd, tool-bar, ... retained their doc-strings. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
make bootstrap on GNU Emacs 22.0.50 ends early in progmodes/cc-mode.el
Hello! I seem to have managed to retrieve CVS updates via anonymous SSH access, after two weeks of doing nothing, but then the compilation process stopps after all autoloads were recorded for the newly dumped bootstrap-emacs in progmodes/cc-mode.el: Generating autoloads for progmodes/cc-subword.el... Generating autoloads for progmodes/cc-subword.el...done Saving file /Users/pete/Quellen/Emacs_CVS/emacs/lisp/loaddefs.el... Wrote /Users/pete/Quellen/Emacs_CVS/emacs/lisp/loaddefs.el find /Users/pete/Quellen/Emacs_CVS/emacs/lisp -name *.elc -print | xargs chmod +w /dev/null 21; \ wd=/Users/pete/Quellen/Emacs_CVS/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/* | */=* ) ;; *) wins=$wins $wd/$file ;; esac; done; \ els=`echo $wins | tr ' \011' '\012\012' | \ sed -e 's|\(.\)$|\1/|' -e 's|^\./||' -e 's|$|*.el|'`; \ for el in /Users/pete/Quellen/Emacs_CVS/emacs/lisp/emacs-lisp/byte-opt.el /Users/pete/Quellen/Emacs_CVS/emacs/lisp/emacs-lisp/bytecomp.el /Users/pete/Quellen/Emacs_CVS/emacs/lisp/subr.el /Users/pete/Quellen/Emacs_CVS/emacs/lisp/progmodes/cc-mode.el /Users/pete/Quellen/Emacs_CVS/emacs/lisp/progmodes/cc-vars.el $els; do \ if test -f $el; \ then \ echo Compiling $el; \ EMACSLOADPATH=/Users/pete/Quellen/Emacs_CVS/emacs/lisp ../src/bootstrap-emacs -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done $el || exit 1; \ fi \ done Compiling /Users/pete/Quellen/Emacs_CVS/emacs/lisp/emacs-lisp/byte-opt.el Wrote /Users/pete/Quellen/Emacs_CVS/emacs/lisp/emacs-lisp/byte-opt.elc Compiling /Users/pete/Quellen/Emacs_CVS/emacs/lisp/emacs-lisp/bytecomp.el In end of data: bytecomp.el:4165:1:Warning: the function `compilation-forget-errors' is not known to be defined. Wrote /Users/pete/Quellen/Emacs_CVS/emacs/lisp/emacs-lisp/bytecomp.elc Compiling /Users/pete/Quellen/Emacs_CVS/emacs/lisp/subr.el Wrote /Users/pete/Quellen/Emacs_CVS/emacs/lisp/subr.elc Compiling /Users/pete/Quellen/Emacs_CVS/emacs/lisp/progmodes/cc-mode.el In toplevel form: progmodes/cc-mode.el:85:1:Error: Font-lock trying to use keywords before setting them up make[2]: *** [compile] Error 1 make[2]: Target `bootstrap' not remade because of errors. make[1]: *** [bootstrap-build] Error 2 make: *** [bootstrap] Error 2 The code at this place is: 76 ;;; Code: 77 78 (eval-when-compile 79 (let ((load-path 80(if (and (boundp 'byte-compile-dest-file) 81 (stringp byte-compile-dest-file)) 82 (cons (file-name-directory byte-compile-dest-file) load-path) 83 load-path))) 84 (load cc-bytecomp nil t))) 85 It works to interactively byte-compile with GNU Emacs 22.0.50, but using the newly made src/emacs-22.0.50 interactively I have the same error. It stays when I invoke it with -Q ... In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0, X toolkit, Xaw3d scroll bars) of 2005-12-11 on localhost X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--without-pop' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--without-sound' '--enable-locallisppath=/Library/Application Support/Emacs/calendar22:/Library/Application Support/Emacs/preview:/Library/Application Support/Emacs/auctex/images:/Library/Application Support/Emacs/auctex:/Library/Application Support/Emacs' 'CFLAGS=-ggdb -O2 -pipe -faltivec -maltivec -mcpu=740 -no-cpp-precomp -fomit-frame-pointer -foptimize-register-move -fcprop-registers -frename-registers -freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt' 'CPPFLAGS=-I/usr/local/include -I/sw/include/libpng12 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/lib/freetype219/include -I/sw/include' 'LDFLAGS=-L/usr/X11R6/lib -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib/freetype219/lib -L/sw/lib/pango-ft219/lib -L/sw/lib'' Important settings: value of $LC_ALL: de_DE.UTF-8 value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 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: Compilation Minor modes in effect: desktop-save-mode: t display-time-mode: t mouse-sel-mode: t show-paren-mode: t tooltip-mode: t auto-compression-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 column-number-mode: t line-number-mode: t
Re: Function w32_abort not defined
From: Richard M. Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Sun, 25 Dec 2005 21:19:25 -0500 We could add this command to .gdbinit to reassure anyone who might get worried: output If you see messages immediately following about functions not being defined,\n don't worry about them. Nothing is wrong.\n Done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: jit-lock.el functions variables appear undocumented.
From: RGB [EMAIL PROTECTED] Date: Thu, 29 Dec 2005 23:25:27 -0600 Cc: emacs-pretest-bug@gnu.org I then searched for the string 'jit-lock' in the DOC file. This was the only occurrence: For a newer font-lock support mode with similar functionality, see `jit-lock-mode'. Eventually, Lazy Lock mode will be deprecated in JIT Lock's favor. The JIT lock variables were not in DOC due to a bug in lib-src/makefile.w32-in (it missed some of the Lisp files, including jit-lock.elc, in the make-docfile command). I fixed it; could you please try again? And thanks for reporting this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: jit-lock.el functions variables appear undocumented.
Date: Fri, 30 Dec 2005 11:55:34 +0100 From: martin rudalics [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org My last build where this worked correctly is from 2005-10-20. A build from 2005-11-06 already doesn't have the doc-strings. On what OS? (Please always tell that, since the configury and build setups are different on some systems.) The bug that I fixed was specific to MS-Windows. I don't think it existed on other systems. In between was: 2005-10-31 Dan Nicolaescu [EMAIL PROTECTED] * loadup.el: Load emacs-lisp/syntax, font-lock and jit-lock so that global-font-lock-mode can be enabled by default. * font-lock.el (font-lock-keywords, font-lock-mode-internal) (font-lock-add-keywords, font-lock-remove-keywords) (font-lock-fontify-buffer): Remove autoload cookies. * jit-lock.el (jit-lock-register): Likewise. You will see that Dan also changed src/Makefile.in: 2005-11-03 Dan Nicolaescu [EMAIL PROTECTED] * Makefile.in (lisp, shortlisp): Add emacs-lisp/syntax.elc, font-lock.elc and jit-lock.elc. But he didn't make a similar change in lib-src/makefile.w32-in, which is where etc/DOC is produced by the MS-Windows build. This is what caused the bug. Coincidentally, in the same period all doc-strings for functions and variables defined in `mwheel' vanished too, maybe related to: 2005-10-28 Richard M. Stallman [EMAIL PROTECTED] ... * loadup.el (facemenu): Load unconditionally. (image, international/fontset, dnd, mwheel, tool-bar): (x-dnd): Load, when appropriate. I've added the files from this list that are loaded on MS-Windows to the list of files mentioned in lib-src/makefile.w32-in from which etc/DOC is generated. I think they should also be added to SOME_MACHINE_LISP in src/Makefile.in, but I didn't do that. but - strangely enough - dnd, tool-bar, ... retained their doc-strings. Not for me, not on MS-Windows. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: jit-lock.el functions variables appear undocumented.
On what OS? (Please always tell that, since the configury and build setups are different on some systems.) In GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) on WindowsME. but - strangely enough - dnd, tool-bar, ... retained their doc-strings. Not for me, not on MS-Windows. I lied, only tool-bar retained them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Quitting `save-buffer' loses backup file
I wrote: Here is a summary of what Emacs does in the scenario: (a) Before saving bar, Emacs renames bar to bar~, overwriting the old backup in the process, and sets `buffer-backed-up' to t. This is documented in the manual. (b) Emacs tries to save bar but fails to do so, because the user quits. To reduce harm, Emacs renames bar~ back to bar. But -- and this is probably wrong -- Emacs does not set `buffer-backed-up' back to nil. Actually, (b) is coded and documented in the function basic-save-buffer-2, near the end: , | ;; If we get an error writing the new file, and we made | ;; the backup by renaming, undo the backing-up. | (and setmodes (not success) |(rename-file (cdr setmodes) buffer-file-name)) ` What do you think of the following patch which sets `buffer-backed-up' back to nil here? *** files.el~ 2005-12-16 16:41:21.0 +0100 --- files.el2005-12-30 16:36:26.0 +0100 *** *** 3468,3474 ;; If we get an error writing the new file, and we made ;; the backup by renaming, undo the backing-up. (and setmodes (not success) !(rename-file (cdr setmodes) buffer-file-name)) setmodes)) (defun diff-buffer-with-file (optional buffer) --- 3468,3476 ;; If we get an error writing the new file, and we made ;; the backup by renaming, undo the backing-up. (and setmodes (not success) !(progn ! (rename-file (cdr setmodes) buffer-file-name) ! (setq buffer-backed-up nil))) setmodes)) (defun diff-buffer-with-file (optional buffer) By the way, there is another possibility of an error here. The file may be written incompletely due to insufficient disk space. In this case, the renaming of the backup back to the original fails, but I think it shouldn't. So here is a better patch: *** files.el~ 2005-12-16 16:41:21.0 +0100 --- files.el2005-12-30 16:57:39.0 +0100 *** *** 3468,3474 ;; If we get an error writing the new file, and we made ;; the backup by renaming, undo the backing-up. (and setmodes (not success) !(rename-file (cdr setmodes) buffer-file-name)) setmodes)) (defun diff-buffer-with-file (optional buffer) --- 3468,3476 ;; If we get an error writing the new file, and we made ;; the backup by renaming, undo the backing-up. (and setmodes (not success) !(progn ! (rename-file (cdr setmodes) buffer-file-name t) ! (setq buffer-backed-up nil))) setmodes)) (defun diff-buffer-with-file (optional buffer) Regards, Sven ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vc-annotate tries to load vc-nil
Thanks, now I see. I'm so accustomed to the logic of `log-view-diff' that uses the previous revision if there is no mark. Perhaps `C-x c =' should use exactly the same logic. I don't have an opinion, so feel free to change it (it's probably in log-view-minor-wrap). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: jit-lock.el functions variables appear undocumented.
Date: Fri, 30 Dec 2005 16:00:33 +0100 From: martin rudalics [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Lied again, the tool-bar variables are in C. Everything's as you told. So now these problems should be gone, at least on Windows. ___ 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
Stefan Monnier [EMAIL PROTECTED] writes: Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). Thanks. I'll have to try that. In the meantime, I can now reproduce the problem! And, it's uh, in MH-E :-(. emacs -Q C-x b foo RET M-: font-lock-keywords RET = nil C-x k RET M-x mh-rmail C-x b foo RET M-: font-lock-keywords RET = (t nil) (but only if you have unseen messages in +inbox) C-x k RET F v +some-folder RET(mh-visit-folder, must have at least one message) C-x b foo RET M-: font-lock-keywords RET = (t nil) Interestingly, I found that if you kill a folder's buffer and then revisit that folder, this problem does not reappear. But choose a folder that you haven't yet visited with at least one message, and it does. Can you guys take a quick peek and see if you see anything obvious? If not, I'll debug this. If you have GNU mailutils or nmh installed, and you can get a message in +some-folder you should be able to perform the above steps. (Hint: the first chapter of the MH-E manual--even the old one that is currently in Emacs--is a tutorial which will help you do this.) I've opened an MH-E bug #1393879 on this: https://sourceforge.net/tracker/index.php?func=detailaid=1393879group_id=13357atid=113357 -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ 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
Bill Wohler [EMAIL PROTECTED] writes: Can you guys take a quick peek and see if you see anything obvious? If not, I'll debug this. I didn't see anything obvious, but I'm not intimately familiar with the font-lock stuff. mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ 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: font-lock-add-keywords in hi-lock.el
Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). This error was not triggered when I visited a folder in MH-E. Have you re-dumped Emacs in the mean time. font-lock is now preloaded. Stefan ___ 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
Stefan Monnier [EMAIL PROTECTED] wrote: Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). This error was not triggered when I visited a folder in MH-E. Have you re-dumped Emacs in the mean time. font-lock is now preloaded. Nope. Thanks for the reminder. Dumping... Running... signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) mh-notate-user-sequences() mh-regenerate-headers((all)) mh-scan-folder(+tmp/laptops all) mh-visit-folder(+tmp/laptops all) call-interactively(mh-visit-folder) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ 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
signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) So it looks like the problem is that you call font-lock-fontify-region without first setting up font-lock variables (e.g. by calling font-lock-mode or font-lock-set-defaults). OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Yes. Stefan ___ 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
Bill Wohler [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) ... I think the bug is in font-lock, not in MH-E. I see that font-lock-default-fontify-buffer calls font-lock-set-defaults. It seems that font-lock-fontify-region is a perfectly good entry point to font-lock so that font-lock-default-fontify-region might as well call font-lock-set-default too. When I added a call to font-lock-set-default to to the top of font-lock-default-fontify-region, the bug went away. Does this sound right? Are the modes responsible for calling this seemingly internal function. It certainly isn't documented. I do see that dig.el, sh-script.el, and vhdl-mode.el call this function, but maybe these were added to work around this bug. I'd appreciate it if someone who was more familiar with this code inserted the call to font-lock-set-default in the correct place (I had just inserted it blindly at the top). Also, it would be a good idea to check the other functions and see if there are other entry points that are missing this call. There is one inconsistent call to font-lock-set-default. font-lock-fontify-block checks for (not font-lock-mode) first before calling font-lock-set-default. The rest just go ahead and call font-lock-set-default. Maybe all these calls to font-lock-set-defaults can be replaced with a single call to font-lock-set-defaults in font-lock-compile-keywords to replace this code: (if (not font-lock-set-defaults) ;; This should never happen. But some external packages sometimes ;; call font-lock in unexpected and incorrect ways. It's important to ;; stop processing at this point, otherwise we may end up changing the ;; global value of font-lock-keywords and break highlighting in many ;; other buffers. (error Font-lock trying to use keywords before setting them up)) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. The manual seems to indicate that setting font-lock-defaults in this fashion is exactly the right way to proceed. It also implies that font-lock-defaults is already buffer local so we should be able to delete the make-local-variable call above, right? -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ 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
Stefan Monnier [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) So it looks like the problem is that you call font-lock-fontify-region without first setting up font-lock variables (e.g. by calling font-lock-mode or font-lock-set-defaults). The manual doesn't mention either font-lock-fontify-buffer or font-lock-fontify-region. Is that because the manual is incomplete or because we are using font-lock in an undocumented way? Nonetheless, if font-lock-default-fontify-buffer calls font-lock-set-defaults, it seems that font-lock-default-fontify-region should as well, thereby fixing the problem. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Function w32_abort not defined
We could add this command to .gdbinit to reassure anyone who might get worried: output If you see messages immediately following about functions not being defined,\n don't worry about them. Nothing is wrong.\n Done. Since I raised this question, I want to make clear that I was worried not by the meaning of these error messages, but by the clutter they produce in the gdb window. And now a new 4-line explanation just added more clutter :-) A proper analogy for the reaction to gdb error messages are -Wno-pointer-sign compiler warnings. Nobody worries about them, but everyone wants to get rid. If it would be possible to generate .gdbinit depending on the values specified for `configure'... -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
