Re: suspend/fg excitement in *shell*
[EMAIL PROTECTED] wrote: GM I cannot reproduce this. At least you perhaps can reproduce in an emacs *shell* buffer: No, I can't. Surprisingly, you just repeating most of what you said the first time word for word has not helped me to do so. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: suspend/fg excitement in *shell*
Sven Joachim wrote: Yes, I can reproduce this with Emacs 21.4. How about outside Emacs? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar.el byte-compile failed
Zhang Wei wrote: Checking d:/emacs-gbk/lisp/calendar... Compiling d:/emacs-gbk/lisp/calendar/calendar.el... In toplevel form: calendar/calendar.el:2215:1:Error: Symbol's function definition is void: i There have been no changes in lisp/calendar/ in the past two weeks. It works for me. Perhaps there is a problem on your end? In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-08-04 on BREPHOME modified by Zhangwei [EMAIL PROTECTED]. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: suspend/fg excitement in *shell*
Dan Jacobson wrote: I notice in the *shell* buffer, suspend/fg acts funny. I cannot reproduce this. If you want this investigating, please provide a clear recipe showing the minimum emacs and shell configurations needed to produce the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: missing links in *Help*
Tom Tromey wrote: 2. Visit a patch file; make sure it is in diff-mode 3. C-h b 4. Move your mouse around the *Help* buffer. Note that diff-unified-context and diff-context-unified do not highlight -- you cannot click on these to go to the appropriate help text. Thanks; I think I fixed this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
printing.el is broken
emacs -Q -l printing load: Symbol's value as variable is void: ps-print-version ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bootstrap fails due to missing cl-loaddefs.el
Michael Olson wrote: I removed it mistakenly, thinking that it was autogenerated by the build system. No problem. Looks like Miles already restored it in CVS too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
copyright-update-year broken in some modes
rev 1.58 of copyright.el breaks copyright-update-year in some modes, eg texinfo, depending on the value of comment-start-skip: emacs -Q man/calendar.texi M-x copyright-update Wrong type argument: integer-or-marker-p, nil comment-start-skip does not contain any subexpressions in texinfo mode (nor need it, according to the documentation), so the change from (match-end 0) to (match-end 1) at line 114 of copyright.el causes problems. 2007-05-25 Stefan Monnier [EMAIL PROTECTED] * emacs-lisp/copyright.el (copyright-names-regexp): New var. (copyright-update-year): Use it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq cal-tex-diary t) does not have the documented effect on cal-tex-cursor-week
Brian van den Broek wrote: According to section `39.5 Writing Calendar Files' of the emacs info file: If the variable `cal-tex-diary' is non-`nil' (the default is `nil'), diary entries are included also (in weekly and monthly calendars only). However, the effect is observed only for monthly calendars, not weekly ones as documented. Thanks, I will fix the code and/or doc. In the meantime, looks like `cal-tex-cursor-week-iso' does use this variable, whereas cal-tex-cursor-week does not (at present). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: semicolon missing in lib-src/etags.c
root wrote: on line 892 This is in CVS checkout withon teh last 5 minutes sorry for the typo. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old web page
Francesco Potorti` wrote: At http://directory.fsf.org/GNU/emacs.html a link is provided to the source tarball of Emacs 21.4a, rather than 22.1. The emacs developers have no direct access to this page. As it says at the end of the page, problems should be reported to bug-directory at gnu.org. I already sent a patch to update the page for Emacs 22, but for some reason it was only partially applied. I will send the rest again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mac/INSTALL typos
YAMAMOTO Mitsuharu wrote: Thanks. I applied your patch to both the trunk and the EMACS_22_BASE branch. I think you should alter the changelog entry to be under your name, which seems perfectly acceptable for corrections which are simple typos (ie purely factual). Large numbers of tiny changes from authors without assignments are an issue. I haven't read any of the recent bug reports, but please don't install any code from the OP. If you're not familiar with the gory details, see admin/notes/copyright, or this thread: http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00257.html ___ 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
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: Info-scroll-up/down on mode-line
Nick Roberts wrote: 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. Maybe: *** info.el 01 Apr 2007 23:11:10 -0700 1.500 --- info.el 23 Apr 2007 00:02:02 -0700 *** *** 2602,2607 --- 2602,2608 in other ways.) (interactive) + (select-window (posn-window (event-start last-input-event))) (if (or ( (window-start) (point-min)) ( (window-start) (point-max))) (set-window-start (selected-window) (point))) *** *** 2627,2632 --- 2628,2634 beginning of a node, that goes to the previous node or back up to the parent node. (interactive) + (select-window (posn-window (event-start last-input-event))) (if (or ( (window-start) (point-min)) ( (window-start) (point-max))) (set-window-start (selected-window) (point))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: html-mode demanding html a bit too tight
Kevin Ryde wrote: If I'm not mistaken the html-mode regexp in magic-mode-alist demands a html. It'd be nice if a html doctype like !DOCTYPE HTML ... or !DOCTYPE html ... could be considered html too. Since plain html is already accepted, I don't see how this can do any harm, so I added it. (I remember the days when file extensions stood for something round these parts...) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with overlays (on w32 only?)
Lennart Borgman (gmail) wrote: In the attached images I have one overlay one character long that has a red underline. [...] 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.) Yes, but what shade of blue? emacs -q --no-site-file Press [RET] on i in This buffer is for... At end of buffer, evaluate this: (setq o1 (make-overlay 1 2)) (overlay-put o1 'face '(:underline t :foreground red)) (setq o2 (make-overlay 1 10)) (overlay-put o2 'face '(:background green)) Works as it should for me. This is on GNU/Linux. ___ 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
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: Link in define-key doc broken
Lennart Borgman (gmail) wrote: The link to Extended Menu Items in the doc string for define-key is broken. Thanks; fixed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired-virtual-mode doc
Johan Bockgård wrote: The doc string for dired-virtual-mode speaks about the nonexistent variable `buffer-contents-mode-alist'. Also, the regexp is wrong (the /?+ part) and a bunch of backslashes are missing. Thank you; installed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell and abbrev
Richard Stallman wrote: I think this is an issue for aspell or ispell (whichever one you are using). Not for Emacs. No, I think rather that flyspell should downcase abbrevs before defining them, like define-mode-abbrev does. 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: emacs -Q -f abbrev-mode (define-abbrev lisp-mode-abbrev-table FOO foobar) FOO - not expanded foo - not expanded (define-abbrev lisp-mode-abbrev-table bar foobar) bar - foobar Bar - Foobar BAr - Foobar BAR - FOOBAR *** flyspell.el 06 Apr 2007 19:55:53 -0700 1.117 --- flyspell.el 21 Apr 2007 16:30:23 -0700 *** *** 1827,1833 (defun flyspell-define-abbrev (name expansion) (let ((table (flyspell-abbrev-table))) (when table ! (define-abbrev table name expansion ;;*-*/ ;;*flyspell-auto-correct-word ... */ --- 1827,1833 (defun flyspell-define-abbrev (name expansion) (let ((table (flyspell-abbrev-table))) (when table ! (define-abbrev table (downcase name) expansion ;;*-*/ ;;*flyspell-auto-correct-word ... */ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell and abbrev
For now, I installed the flyspell change. I suggest we think about the wider issue after the release. ___ 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 found that you're distributing a version of python.el that includes work I did a couple of years ago (some of which seems to have been somewhat broken in the process). What's the reason for disregarding my legal concerns about that work? Maybe this message is meant for some specific recipients who will already know what this is about. If not, please could you explain in more detail what you mean? Precisely which work has potential legal concerns? The python.el in CVS Emacs is the one you submitted to gnu-emacs-sources here: http://lists.gnu.org/archive/html/gnu-emacs-sources/2004-01/msg00032.html Here you ask why it's not installed yet: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-04/msg3.html Here you supply some updates, installed 2004-05-06 http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00055.html Another fix: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-03/msg00441.html 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 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 Here are some assignment-related comments from Ken Manheimer: http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00753.html ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: spelling errors in todo-mode.el
Robert Marshall wrote: threshhold should be threshold - in the text rather than the variable name. Thanks. Fixed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile failure due to Xaw3d include file issues
It seems bad form to abort in the middle of the build though. A small
addition to configure.in makes it clearer IMO:
*** configure.in02 Apr 2007 16:10:31 -0700 1.442
--- configure.in19 Apr 2007 00:21:22 -0700
***
*** 2204,2210
dnl Do not put whitespace before the #include statements below.
dnl Older compilers (eg sunos4 cc) choke on it.
! if test x${USE_X_TOOLKIT} = xmaybe; then
if test x${HAVE_X11R5} = xyes; then
AC_MSG_CHECKING(X11 version 5 with Xaw)
AC_CACHE_VAL(emacs_cv_x11_version_5_with_xaw,
--- 2204,2210
dnl Do not put whitespace before the #include statements below.
dnl Older compilers (eg sunos4 cc) choke on it.
! if test x${USE_X_TOOLKIT} = xmaybe || test x${USE_X_TOOLKIT} = xLUCID;
then
if test x${HAVE_X11R5} = xyes; then
AC_MSG_CHECKING(X11 version 5 with Xaw)
AC_CACHE_VAL(emacs_cv_x11_version_5_with_xaw,
***
*** 2218,2226
--- 2218,2230
AC_MSG_RESULT([5 or newer, with Xaw; use toolkit by default])
USE_X_TOOLKIT=LUCID
else
+ if test x${USE_X_TOOLKIT} = xLUCID; then
+ AC_MSG_ERROR([Lucid toolkit requires X11/Xaw include files])
+ else
AC_MSG_RESULT(before 5 or no Xaw; do not use toolkit by default)
USE_X_TOOLKIT=none
fi
+ fi
else
USE_X_TOOLKIT=none
fi
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves /../ in expansions at times
Miles Bader wrote: The filesystem I was thinking of wasn't AFS; I don't know if it's still used or not. I think this may be the original bug report requesting this feature, from 1989. It says: FREEDOMNET, TRFS, the NewCastle Connection, and several other products all use the superroot. http://groups.google.com/group/gnu.emacs.bug/msg/9db06ff9a54847d0 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile failure due to Xaw3d include file issues
Ulrich Mueller wrote: libXaw Xaw3d 0 0 fails in lwlib.c due to missing X11/Xaw/Paned.h 0 1 OK, links against libXaw3d.so.8 I think it's also going to fail in this case if you configure --without-toolkit-scroll-bars --with-x-toolkit=lucid because then HAVE_XAW3D never gets set. And if you configure with no options, it's not going to realize that it could in fact use the Xaw3d include files to build the lucid toolkit. Emacs 21 had the same problem, and since no-one ever reported it here (?), it doesn't seem that big an issue. So rather than making significant changes to the build process so close to the release, it might be best just to document the problem and leave it alone for now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves /../ in expansions at times
Richard Stallman wrote: I think this is the Andrew file system. Indeed, I think that is the reason why Emacs doesn't convert `/..' to `/', I don't know whether AFS is still used. If not, we would like to remove the support for it, by and by. But there is certainly no reason to remove it just now. OpenAFS at least is still widely used in the particle physics community. I have never encountered the superroot concept in connection with it though. Everything is accessed through /afs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves /../ in expansions at times
Richard Stallman wrote: It would be good to add a sentence in the Emacs Lisp Reference Manual to explain this. Would someone please do that? Done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: regression in diary-lib
Andreas Seltenreich wrote: I just switched from 22.0.96 to 22.0.98 and noticed that the file-local variables in my ~/diary file are no longer honored. It seems like the following change causes buffer-local variables to be flushed on each call to diary-view-entries: Fixed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: autoload problem in calendar?
John ffitch wrote: Debugger entered--Lisp error: (error Autoloading failed to define function diary-font-lock-keywords) Works for me. Are you sure your CVS is fully up to date? A `make bootstrap' never hurts. Failing that, please provide a full recipe starting from `emacs -Q'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: bibtex-user-optional-fields: INIT without {}
Roland Winkler wrote:
The following patch appears much clearer to me.
[...]
Should I check it in?
Entirely up to you. I installed mine, but feel free to revert it.
+ (unless (string-match \\`\\({.*}\\|\.*\\\)\\' init)
+(setq init (concat (bibtex-field-left-delimiter) init
+ (bibtex-field-right-delimiter)
What about the (unlikely?) cases like:
author = {Smith}, J. and Jones, {P.}
It matches the above regexp, but still needs enclosing.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Kim F. Storm wrote: Should we add quack.el to the list of packages which we recommend people to upgrade when using Emacs 22.1 ? (The list is in etc/NEWS). I don't think this was a quack + emacs 22 problem, it was just a problem in older versions of quack, full stop. http://www.neilvandyke.org/quack/quack.el ;; HISTORY: ;; ;; Version 0.29 (2006-11-12) ;; * Fixed `quack-bar-syntax-string', which caused vertical bar ;; characters to be treated as whitespace. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Nick Roberts wrote: It fails on Emacs 22 too (it would be best if you checked this first). I'm pretty sure it relates to my changes, but I'm not sure yet that the bug is in tmm.el. org-mode has an awesome menubar! [...] Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? According to the lispref Inheritance and Keymaps, yes. Eg: (let ((map (make-sparse-keymap))) (set-keymap-parent map text-mode-map) map) So how about this fix: *** tmm.el 3 Apr 2007 10:09:45 - 1.52 --- tmm.el 12 Apr 2007 22:46:20 - *** *** 547,555 ;; the global list. (dolist (minor minorbind) (dolist (item (cdr minor)) ! (setq globalbind (assq-delete-all (car item) globalbind (dolist (item (cdr localbind)) ! (setq globalbind (assq-delete-all (car item) globalbind))) (setq globalbind (cons 'keymap globalbind)) (setq allbind (cons globalbind (cons localbind minorbind))) --- 547,555 ;; the global list. (dolist (minor minorbind) (dolist (item (cdr minor)) ! (setq globalbind (assq-delete-all (car-safe item) globalbind (dolist (item (cdr localbind)) ! (setq globalbind (assq-delete-all (car-safe item) globalbind))) (setq globalbind (cons 'keymap globalbind)) (setq allbind (cons globalbind (cons localbind minorbind))) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: bibtex-user-optional-fields: INIT without {}
Christian Schlauer wrote: So the curly braces are missing. I think this patch fixes it. *** bibtex.el 21 Jan 2007 13:45:48 - 1.124 --- bibtex.el 12 Apr 2007 22:49:20 - *** *** 1785,1791 (set-mark (point)) (message Mark set) (bibtex-make-field (funcall fun 'bibtex-field-kill-ring-yank-pointer ! bibtex-field-kill-ring) t)) ;; insert past the current entry (bibtex-skip-to-valid-entry) (set-mark (point)) --- 1785,1791 (set-mark (point)) (message Mark set) (bibtex-make-field (funcall fun 'bibtex-field-kill-ring-yank-pointer ! bibtex-field-kill-ring) t nil t)) ;; insert past the current entry (bibtex-skip-to-valid-entry) (set-mark (point)) *** *** 3020,3026 (if comment (message %s (nth 1 comment)) (message No comment available) ! (defun bibtex-make-field (field optional move interactive) Make a field named FIELD in current BibTeX entry. FIELD is either a string or a list of the form \(FIELD-NAME COMMENT-STRING INIT ALTERNATIVE-FLAG) as in --- 3020,3026 (if comment (message %s (nth 1 comment)) (message No comment available) ! (defun bibtex-make-field (field optional move interactive nodelim) Make a field named FIELD in current BibTeX entry. FIELD is either a string or a list of the form \(FIELD-NAME COMMENT-STRING INIT ALTERNATIVE-FLAG) as in *** *** 3028,3034 If MOVE is non-nil, move point past the present field before making the new field. If INTERACTIVE is non-nil, move point to the end of the new field. Otherwise move point past the new field. ! MOVE and INTERACTIVE are t when called interactively. (interactive (list (let ((completion-ignore-case t) (field-list (bibtex-field-list --- 3028,3035 If MOVE is non-nil, move point past the present field before making the new field. If INTERACTIVE is non-nil, move point to the end of the new field. Otherwise move point past the new field. ! MOVE and INTERACTIVE are t when called interactively. ! INIT is surrounded by delimiters, unless NODELIM is non-nil. (interactive (list (let ((completion-ignore-case t) (field-list (bibtex-field-list *** *** 3058,3067 (indent-to-column (+ bibtex-entry-offset bibtex-text-indentation))) (let ((init (nth 2 field))) ! (insert (cond ((stringp init) init) ((fboundp init) (funcall init)) ! (t (concat (bibtex-field-left-delimiter) ! (bibtex-field-right-delimiter)) (when interactive ;; (bibtex-find-text nil nil bibtex-help-message) (if (memq (preceding-char) '(?} ?\)) (forward-char -1)) --- 3059,3073 (indent-to-column (+ bibtex-entry-offset bibtex-text-indentation))) (let ((init (nth 2 field))) ! (insert (if nodelim ! ! (bibtex-field-left-delimiter)) ! (cond ((stringp init) init) ((fboundp init) (funcall init)) ! (t )) ! (if nodelim ! ! (bibtex-field-right-delimiter (when interactive ;; (bibtex-find-text nil nil bibtex-help-message) (if (memq (preceding-char) '(?} ?\)) (forward-char -1)) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
I should also say that the Format of Keymaps section of the lispref has an example (lisp-mode-map) with a keymap sitting there on its own. It looks weird to me too, but there you go. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Nick Roberts wrote: Does it fix the bug, or just mask the error? I mean does the menu on a tty for Org mode look as it should with this change? Well, it looks alright to me (at least, it looks the same as it does in 21.3 when I load org-mode), but I don't know what problem your recent change was trying to fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Richard Matthew Stallman wrote: It seems that this does not happen in the current CVS. Looks like it's been this way for about 2 years. If that is the case, how come Jose gets this bug? His snapshot is surely not 2 years old. I don't know. All I can say is that: emacs -q --no-site-file -f scheme-mode abcd| RET M-x delete-trailing-whitespace does the right thing for me (deletes the spaces, not the |). This is with the current CVS (the | is indeed removed in Emacs 21.3) and the last relevant-looking changes to scheme.el were 2 years ago. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
Stefan Monnier wrote: The iff idiom is sufficiently common that we don't want to shy away from it just at this one place. So either we rule it out everywhere, or we use it liberally. Sufficiently common in Emacs (~ 600 instances); I've never seen it anywhere else as far as I remember. All it does is save some typing at the expense of confusing people from time to time. Personally, I think it should not be used. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Jose A. Ortega wrote: In a buffer with scheme-mode active, delete-trailing-whitespace treats a traling vertical bar character (|) as trailing whitespace (that is, the character is deleted when invoking delete-trailing-whitespace, either interactively or as a write hook). It seems that this does not happen in the current CVS. Looks like it's been this way for about 2 years. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: diary-date-forms customization too late
Stephen Berman wrote: If you call (diary) from your init-file and use the Custom interface to customize diary-date-forms, the customization gets evaluated after diary-font-lock-keywords has been set, so your customized date form does not get fontified as it should. To reproduce: Thanks; I've installed a fix for this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hanoi causes SEGV
Jeffrey C Honig wrote: M-xhanoiRET Erk. Seems to be a font-lock related transpose-regions problem. emacs -Q Type abcd in scratch M-: (transpose-regions 1 2 3 4) Debugger entered--Lisp error: (args-out-of-range 0 0) get-text-property(0 font-lock-multiline) font-lock-extend-jit-lock-region-after-change(0 0 0) run-hook-with-args(font-lock-extend-jit-lock-region-after-change 0 0 0) jit-lock-after-change(0 0 0) transpose-regions(1 2 3 4) eval((transpose-regions 1 2 3 4)) eval-expression((transpose-regions 1 2 3 4) nil) call-interactively(eval-expression) If you repeat the experiment and disable font-lock before calling transpose-regions, Emacs segfaults. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs -Q -f calendar wraps ugly
Dan Jacobson wrote: $ emacs -Q -f calendar wraps ugly these days. I could very briefly reproduce this [1], then it went away. It turns out my build was incomplete, and I was running a bootstrap-emacs rather than a finished emacs. In GNU Emacs 22.0.92.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-01-15 on pacem, modified by Debian That's from a few months ago. Please report again (in more detail) if the problem occurs with the current CVS. [1] Well, I saw some kind of problem, but I have no idea what you were seeing, since there are no _details_ or anything boring like that in this bug report. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Make calendar-mark-today update at midnight
Stephen Berman wrote: Set today-visible-calendar-hook to 'calendar-mark-today in your init-file or via Custom. Then, if you have the calendar buffer open before midnight and keep it open past the stroke of midnight, the marked date remains unchanged, i.e., now yesterday is marked. I'm inclined to consider changing this as adding a feature, rather than fixing a bug (it's always been like this), and so would rather not change it now, even if the solution seems simple. The following patch makes the marked date change at midnight, i.e., keeps today as the marked date, but I'm not sure it's the best way to deal with this issue. I guess it will have to be something using a timer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
Lennart Borgman (gmail) wrote: The variable is marked obsolete in the same file where it is used. I would expect that the new name where used in that file instead of the old. I would even expect the new name to be used everywhere in Emacs, leaving the old obsolete name only to external packages to use. I'm sorry, but your expectation is just wrong. Under your scheme, things would go from working in one release to not working in the next. Instead, it's working, working with an obsolete warning, then at some point not working. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-defaults-alist is obsolete but used
Lennart Borgman (gmail) wrote: The variable above is marked as obsolete but used in font-core.el. Should it be that way? Obviously even obsolete variables have to be used _somewhere_, else they are not just obsolete but totally useless. Can you elaborate on your question? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Make install cannot handle directory names with a SPC in it
Chong Yidong wrote: This seems to be a limitation of the venerable mkinstalldirs program. I wonder how other projects handle this problem? We could replace the mkinstalldirs in Emacs with one from a recent automake, which seems to have addressed this issue. But I think that trying to use paths with spaces will still not work, because there are many many places in the Emacs Makefile where paths are used without quoting. So paths with spaces will be split by the build process before even being passed to mkinstalldirs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Calendar customization too late
Stephen Berman wrote: customize-variable RET diary-display-hook' and in the Customize buffer fixed. customize-variable RET diary-header-line-flag', toggle it to `off' and fixed. typos in diary-lib.el: the docstrings of the defcustoms of diary-header-line-flag and diary-header-line-format refer to `diary-simple-display'; it should be `simple-diary-display' (which fixed. doesn't follow the Emacs naming conventions, but that's still true of a bunch of names in the calendar packages). Yes, it's a bit annoying but I'm not going to change them now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Calendar customization too late
Stephen Berman wrote: Now your ~/.emacs file contains these lines: (appt-activate 1) (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(number-of-diary-entries 7)) [...] 5. Kill Emacs and restart it as in step 3 above. You again get vertically split windows and in the lower one is just the first diary entry. However, because of the customization, the lower window should display all diary entries within a week from today. [...] I think the problem is caused by appt-activate making the diary display before the customization takes effect. It happens with just (diary) too, regardless of appt.el. How about this patch: *** diary-lib.el17 Mar 2007 17:51:56 - 1.119 --- diary-lib.el20 Mar 2007 00:22:22 - *** *** 317,322 --- 317,330 (integer :tag Thursday) (integer :tag Friday) (integer :tag Saturday))) + :initialize 'custom-initialize-default + ;; Redraw a live diary buffer if necssary. + :set (lambda (symbol value) + (let ((oldvalue number-of-diary-entries)) +(custom-set-default symbol value) +(and (not (equal value oldvalue)) + (find-buffer-visiting (substitute-in-file-name diary-file)) + (diary :group 'diary) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Richard Stallman wrote: I agree that there is no reason not to put the usual scratch buffer message into the scratch buffer. So I guess this change should be made. Glenn, would you please install your startup.el patch? done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
Richard Stallman wrote: That sounds like a larger change. Is your change a reversion of that whole previous change, or just an adjustment of it? The change was a large one. This was tiny, IMO incidental part of it. It looks to me that you simply decided not to insert the initial scratch message if another buffer had been selected during startup. More precisely, if the init file leaves a different buffer selected. That sounds right; shouldn't it be so? I don't see why the insertion of the initial scratch message should be conditional on which buffer happens to be current at that point in the start-up sequence. There exists a mechanism to disable the message if so desired. Perhaps the right change is in desktop, to make it not select any of the buffers it makes. No, I think it's right that desktop restore the order of the buffer list at the time you save, which is what it seems to do now. The splash screen is still displayed, BTW, but when you click through it you get your last buffer back. I took that to mean that you were reverting the patch, but now I can see it could be interpreted differently, as just reverting a certain aspect of the behavior. Which meaning did you have in mind? I meant, revert this particular tiny aspect of behaviour, not revert the whole change. I intended revert to be a comforting word, in the sense of, it used to work like this, so it can't be too crazy... :) I'm happy if we drop this till after 22. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
Oliver Scholz wrote: The initial scratch message (from `initial-scratch-message') is missing *iff* `desktop-save-mode' is on and at least one file is actually visited automatically. I belive this is because command-line-1 only inserts the initial-scratch-message if the scratch buffer is selected. Restoring a desktop buries the scratch buffer. The following patch would fix this. It reverts the behaviour to what it was before rev 1.270 of startup.el. *** startup.el 4 Mar 2007 17:49:56 - 1.431 --- startup.el 8 Mar 2007 07:55:36 - *** *** 1995,2007 (with-no-warnings (setq menubar-bindings-done t)) ! ;; If *scratch* is selected and it is empty, insert an ! ;; initial message saying not to create a file there. ! (when (and initial-scratch-message !(equal (buffer-name) *scratch*) ! (= 0 (buffer-size))) (insert initial-scratch-message) ! (set-buffer-modified-p nil)) ;; If user typed input during all that work, ;; abort the startup screen. Otherwise, display it now. --- 1995,2008 (with-no-warnings (setq menubar-bindings-done t)) ! ;; If *scratch* exists and is empty, insert an initial message ! ;; saying not to create a file there. ! (and initial-scratch-message ! (get-buffer *scratch*) ! (with-current-buffer *scratch* !(when (= 0 (buffer-size)) (insert initial-scratch-message) ! (set-buffer-modified-p nil ;; If user typed input during all that work, ;; abort the startup screen. Otherwise, display it now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Partial completion
Here's a somewhat more tested patch. The problem in question is caused by a change in the behaviour of try-completion between 21 and 22. (try-completion foo '((foo) (foo))) returns foo in 21, but t in 22. I don't know if this is a correct interpretation of the doc-string's unique match which is exact or not. The (1- beg) part of the patch prevents PC-lisp-complete-symbol erasing the whole buffer, which it seems to do in 21.4 as well... Could someone familiar with complete.el comment on this? Index: complete.el === RCS file: /sources/emacs/emacs/lisp/complete.el,v retrieving revision 1.60 diff -c -c -w -r1.60 complete.el *** complete.el 5 Mar 2007 14:55:05 - 1.60 --- complete.el 5 Mar 2007 21:07:43 - *** *** 624,630 ;; If ambiguous, try for a partial completion (let ((improved nil) ! prefix (pt nil) (skip \\`)) --- 624,630 ;; If ambiguous, try for a partial completion (let ((improved nil) ! prefix chunk (pt nil) (skip \\`)) *** *** 669,686 (setq skip (concat skip (regexp-quote prefix) PC-ndelims-regex) ! prefix (try-completion ! (PC-chunk-after ;; not basestr, because that does ;; not reflect insertions (buffer-substring (+ beg (length dirname)) end) skip) (mapcar (lambda (x) (when (string-match skip x) (substring x (match-end 0 poss))) (or ( i 0) ( (length prefix) 0)) (or (not (eq mode 'word)) (and first ( (length prefix) 0) --- 669,690 (setq skip (concat skip (regexp-quote prefix) PC-ndelims-regex) ! chunk (PC-chunk-after ;; not basestr, because that does ;; not reflect insertions (buffer-substring (+ beg (length dirname)) end) skip) + prefix (try-completion + chunk (mapcar (lambda (x) (when (string-match skip x) (substring x (match-end 0 poss))) + ;; try-completion returns t if chunk is + ;; an exact match. + (if (eq prefix t) (setq prefix chunk)) (or ( i 0) ( (length prefix) 0)) (or (not (eq mode 'word)) (and first ( (length prefix) 0) *** *** 716,722 ;; Record which part of the buffer we are completing ;; so that choosing a completion from the list ;; knows how much old text to replace. ! (setq completion-base-size dirlength))) (PC-temp-minibuffer-message [Next char not unique])) nil) --- 720,728 ;; Record which part of the buffer we are completing ;; so that choosing a completion from the list ;; knows how much old text to replace. ! (setq completion-base-size (if dirname !dirlength ! (1- beg) (PC-temp-minibuffer-message [Next char not unique])) nil) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Richard Stallman wrote: Ok, but I am still puzzled by one thing. I thought that the more recent fix consisted of reverting the change you had previously made. How come that didn't bring back the old bug? Is it the case that the more recent fix did NOT revert your change? In essence, Jan's original change was to set LIB_X11_LIB to XFT_LIBS when using xft. Now, in essence we append XFT_LIBS to the original value of LIB_X11_LIB, rather than overwriting it. So we may have some duplicate libraries, but that's ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Partial completion
Oops, this has all been discussed on emacs-devel. Apologies for the total time waste. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem compiling on Redhat Enterprise WS 3 with X11
Chong Yidong wrote: ./configure --prefix=/local --x-libraries=/usr/X11R6/lib --x-includes=/usr/X11R6/include --with-x-toolkit=yes As an additional data point, it builds fine for me with these options on Red Hat Enterprise Linux WS release 3 (Taroon Update 8). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Partial completion
Johan Bockgård wrote: $ emacs -Q -l complete Insert (defma ) Place point after a and run M-x PC-lisp-complete-symbol = Wrong type argument: sequencep, t How about the following patch? The 1+ part fixes a different bug that seems to be present in 21.4 as well. *** complete.el 03 Mar 2007 15:51:14 -0800 1.59 --- complete.el 03 Mar 2007 16:04:05 -0800 *** *** 617,623 ;; If ambiguous, try for a partial completion (let ((improved nil) ! prefix (pt nil) (skip \\`)) --- 617,623 ;; If ambiguous, try for a partial completion (let ((improved nil) ! prefix temp (pt nil) (skip \\`)) *** *** 662,668 (setq skip (concat skip (regexp-quote prefix) PC-ndelims-regex) ! prefix (try-completion (PC-chunk-after ;; not basestr, because that does ;; not reflect insertions --- 662,668 (setq skip (concat skip (regexp-quote prefix) PC-ndelims-regex) ! temp (try-completion (PC-chunk-after ;; not basestr, because that does ;; not reflect insertions *** *** 674,679 --- 674,680 (when (string-match skip x) (substring x (match-end 0 poss))) + (if (stringp temp) (setq prefix temp)) (or ( i 0) ( (length prefix) 0)) (or (not (eq mode 'word)) (and first ( (length prefix) 0) *** *** 709,715 ;; Record which part of the buffer we are completing ;; so that choosing a completion from the list ;; knows how much old text to replace. ! (setq completion-base-size dirlength))) (PC-temp-minibuffer-message [Next char not unique])) nil) --- 710,716 ;; Record which part of the buffer we are completing ;; so that choosing a completion from the list ;; knows how much old text to replace. ! (setq completion-base-size (1+ dirlength (PC-temp-minibuffer-message [Next char not unique])) nil) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Partial completion
Glenn Morris wrote: The 1+ part fixes a different bug that seems to be present in 21.4 as well. Whoops, no it doesn't. I don't use partial completion, but it seems to be pretty broken when one selects completion from a list. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Partial completion
Glenn Morris wrote: Glenn Morris wrote: The 1+ part fixes a different bug that seems to be present in 21.4 as well. Whoops, no it doesn't. I don't use partial completion, but it seems to be pretty broken when one selects completion from a list. This patch seems to do better, but is pretty much just trial-and-error. *** complete.el 03 Mar 2007 15:51:14 -0800 1.59 --- complete.el 03 Mar 2007 16:36:13 -0800 *** *** 617,623 ;; If ambiguous, try for a partial completion (let ((improved nil) ! prefix (pt nil) (skip \\`)) --- 617,623 ;; If ambiguous, try for a partial completion (let ((improved nil) ! prefix temp (pt nil) (skip \\`)) *** *** 662,668 (setq skip (concat skip (regexp-quote prefix) PC-ndelims-regex) ! prefix (try-completion (PC-chunk-after ;; not basestr, because that does ;; not reflect insertions --- 662,668 (setq skip (concat skip (regexp-quote prefix) PC-ndelims-regex) ! temp (try-completion (PC-chunk-after ;; not basestr, because that does ;; not reflect insertions *** *** 674,679 --- 674,680 (when (string-match skip x) (substring x (match-end 0 poss))) + (if (stringp temp) (setq prefix temp)) (or ( i 0) ( (length prefix) 0)) (or (not (eq mode 'word)) (and first ( (length prefix) 0) *** *** 709,715 ;; Record which part of the buffer we are completing ;; so that choosing a completion from the list ;; knows how much old text to replace. ! (setq completion-base-size dirlength))) (PC-temp-minibuffer-message [Next char not unique])) nil) --- 710,716 ;; Record which part of the buffer we are completing ;; so that choosing a completion from the list ;; knows how much old text to replace. ! (setq completion-base-size (1- beg (PC-temp-minibuffer-message [Next char not unique])) nil) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Fails for me in the same way on Solaris 10 with just: ./configure --with-gtk --with-xft Problem seems to be that LIB_XFT on Solaris 10 does NOT include -lX11, despite what it says in src/Makefile.in. `pkg-config --libs xft' returns: -R/usr/openwin/lib -R/usr/sfw/lib -R/usr/openwin/lib:/usr/openwin/sfw/lib -L/usr/openwin/lib -L/usr/sfw/lib -L/usr/openwin/sfw/lib -lXft -lfreetype -lXrender -lfontconfig This patch (reverts Jan 26 change) fixes it for me on Solaris 10, don't know if it breaks anything else. It can't hurt to include -lX11 twice, can it? *** Makefile.in 17 Feb 2007 02:36:10 - 1.338 --- Makefile.in 2 Mar 2007 22:48:07 - *** *** 403,410 #endif /* not USE_X_TOOLKIT */ #if HAVE_XFT - #undef LIB_X11_LIB /* XFT_LIBS includes -lX11 */ - #define LIB_X11_LIB [EMAIL PROTECTED]@ #endif /* HAVE_XFT */ --- 403,408 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
Stefan Monnier wrote: Yes, I saw that, but it's still not clear to me what's going on here. E.g. the match any non-identifier char can match a parenthesis, is that correct? I guess a quick fix is to replace [^()] by [^()\n]. Ping, anyone in CC land? The problematic [^()]* part was installed 12-Dec-99, before which it was just ^\\.*. If it really needs to match across newlines, maybe it could match up to some finite number. 1999-12-12 Martin Stjernholm [EMAIL PROTECTED] * cc-menus.el (cc-imenu-c++-generic-expression): Match classes with nonhanging open braces. Don't match the throws clause that might follow the function prototype in C++. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
Stefan Monnier wrote: Please try and play with the text being matched to try and see which part of the regexp is causing an overflow. Most likely the problem is that something is matching a much longer text than expected (e.g. tens/hundreds of nonempty lines rather than 1 or 2). Maybe it's the beginning: ^\\[^()]* since the \ only implies that the first char will be a word-constituent, and the [^()]* can then match any number of chars as long as there's no intervening parenthesis, which seems quite possible in a long comment. This will do it: (goto-char (point-max)) (re-search-backward ^\\[^()]*[^[:alnum:]_:~]) It matches the whole of etc/splash.xpm from static char... right through to the end, some 6 odd characters later. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
c-mode imenu: Stack overflow in regexp matcher
From the top-level directory of a recent Emacs build: ./src/emacs -Q --eval (add-hook 'c-mode-hook 'imenu-add-menubar-index) \ ./etc/splash.xpm Error in menu-bar-update-hook: (error Stack overflow in regexp matcher) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
Chong Yidong wrote: I can't reproduce this with the latest CVS sources: GNU Emacs 22.0.93.23 (i686-pc-linux-gnu, GTK+ Version 2.8.20) I see the problem on x86_64-unknown-linux-gnu (RHEL 4), but not on i686-pc-linux-gnu. (GNU Emacs 22.0.93.1, X toolkit in both cases.) Do any other x86_64-unknown-linux-gnu others see this problem? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
I've reduced the problem to a regexp search called from: (imenu--generic-function imenu-generic-expression) Evaluating the following in a buffer visiting splash.xpm as text causes a stack overflow in the regexp matcher: (goto-char (point-max)) (re-search-backward ^\\[^()]*[^[:alnum:]_:~]\\([[:alpha:]_][[:alnum:]_:~]*\\)\\([ \n]\\|\n\\)*(\\([ \n]\\|\n\\)*\\([^ \n(*][^)]*\\)?)\\([ \n]\\|\n\\)*[^ \n;(] nil t )) A 32-bit version works fine on x86_64, but the 64-bit version has the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
Chris Moore wrote: I don't know if this has been reported before - it's a bug that I've become so used to that I almost don't notice myself working around it any more... Ditto. I reported the issue with the very same manpage in May 2004: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00144.html The consensus then (off list, with the woman author) was that it would be nice if woman could at least say don't know how to format man pages of type FOO and produce no output, rather than displaying a broken page. And also it could suggest writing to the maintainer of the man pages in question to suggest using the standard macros... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Kenichi Handa wrote: I've just updated all AIST copyright years. It seems as if in every case, you just added every year from the first copyright date to the present. This is not exactly how it is supposed to work. The idea is, you should add every year where the file was released with a non-trivial amount of changes in either the file itself or the package (ie Emacs in this case). Since 2001, Emacs has been publicly available by anon CVS. This counts as a release every year. So any file that was in Emacs 21 (in 2001) should have the years 2001-2006 inclusive added. Files added to CVS since Emacs 21 should have the years N-2006 added, where N is the year of addition. Before 2001, you just need to add the dates of the Emacs releases (assuming the files were in Emacs at the time). I suspect that few files have actually had this done in a rigorous fashion. So if I were you, I probably would just have added the years 2001-2006. (disclaimer: this is my understanding). They are written by me and not modified by any other person. So, I think it's ok not having FSF copyright. OK (I just found it odd to see files in Emacs which the FSF has no claim on). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Kenichi Handa wrote: The files who have copyright year before 1997 were released every year as part of Mule package. Ok. Sorry for the lecture you did not need, then. They are integrated into Emacs in 1997. And Emacs were released in 1997, 1998, and 1999. So, perhaps I didn't have to add the year 2000, but I thought that having that year was not harmful. And actually most files are modified in 2000 too. I _think_ it does not matter if the files were modified that year, if those modifications were not released that year (though I agree with you that this is not a huge issue). The current maintain.texi does not seem to make it clear what rules apply if you are not using a public repository, as in 2000. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Nick Roberts wrote: PS Fun times ahead in 3 weeks when every single file in Emacs needs 2007 adding to the Copyright years... Doesn't this make it a bit silly then to just to do it for 2006? I'm not just doing it for 2006. I'm clearing up the mess (IMO) that remains several months after the copyright statements in general were supposedly all checked. Adding 2007 when the time comes ought to be almost totally automatic, as you say. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Kenichi Handa wrote: years that I modified the code. But, AIST keeps copyright for all continuous years. If we must list all years explicitely in such a case, could you please update the lines for AIST too? I've done my best, but I would ask you to check the files where AIST holds copyright to make sure that they are correct. In several cases, the AIST copyright had not been updated for many years (before Emacs 21), whereas the FSF one had. I therefore only updated the FSF years. You may want to update AIST years too. In particular, in lisp/language: chinese.el devan-util.el english.el hebrew.el japanese.el korea-util korean lao-util tibet-util tibetan viet-util vietnamese I would also draw attention to the following files, which have no FSF copyright at all, it seems. Maybe this is correct, I don't know: lisp/composite.el lisp/international/ja-dic-cnv.el lisp/international/ja-dic-utl.el lisp/language/greek.el lisp/language/misc-lang.el lisp/language/thai-word.el I am becoming increasingly unhappy with the state of the Emacs copyright headers, despite a big exercise earlier in the year where every subdirectory was supposedly signed off as up to date. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Eli Zaretskii wrote: There's not a single change that has been done in config.bat in the years 2003 and 2005. maintain.texi says (in node Copyright Notices): To update the list of year numbers, add each year in which you have made nontrivial changes to the package. Changes to the _package_, not to the _file_. So why add to config.bat years that didn't see any changes in that file? Because the Emacs package saw change in those years. Btw, why isn't this change reflected in ChangeLog? To be honest, because the prospect of potentially writing ChangeLog entries for 4000 files appalled me. These changes are all changes in comments (essentially), which have no impact on how the code performs. PS Fun times ahead in 3 weeks when every single file in Emacs needs 2007 adding to the Copyright years... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Nick Roberts wrote: And I thought we said that CC mode was added to Emacs in 1992, yet e.g ;;; cc-langs.el --- language specific settings for CC Mode ;; Copyright (C) 1985, 1987, 1992, 1993, 1994, 1995, 1996, 1997, 1998, ;; 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software ;; Foundation, Inc. i.e the years before 1992 are still in the header Yes, this is fine. Presumably cc-mode was released as a separate package several times before it was added to Emacs. So in 1992 the header may have looked like: 1985, 1987, 1992 John Smith Then when the copyright got assigned to the FSF in 1992, this changes to become: 1985, 1987, 1992 FSF The older years do not get removed, you just change the copyright holder. Q. to RMS: What *should* the header for t-mouse.el look like? Currently: ;; Copyright (C) 1994,1995 Alessandro Rubini [EMAIL PROTECTED] ;; parts are by Ian T Zimmermann [EMAIL PROTECTED], 1995,1998 ;; Copyright (C) 2006 ;; Free Software Foundation, Inc. If I may answer, then normally you remove the old names and replace them with FSF, but keep the old dates. So it would look like: 1994, 1995, 1998, 2006 FSF I suppose there are corner cases when things may be different. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Thanks for checking on the ones I was unsure of. Richard Stallman wrote: ps-bdf.el should have all the from 2001 to 2006. Do I update the years for AIST as well as FSF? t-mouse.el was added in 2006 so it is correct. It can't be correct. See my thread in emacs-devel. If Rubini and Zimmermann have signed assignments, their names should not appear as copyright holders. If they haven't, the file should not be in Emacs, AFAIU. I asked about composite.el. I have since checked lisp/ subdirs: calc, calendar, emacs-lisp, emulation and erc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
On this subject, was it ever decided whether 2001 (the year 21.1 was released) should be added to all files that were present in Emacs at that time? When we went through this copyright update process the first time, sometimes it was added and sometimes it was not. Or is it not important? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Richard Stallman wrote: On this subject, was it ever decided whether 2001 (the year 21.1 was released) should be added to all files that were present in Emacs at that time? Yes, it should be. Marvellous. It is missing from a large number of files. I just fixed lisp/*.el, which was enormous fun. If people want to jump in and do some others, that would be good. The only thing stopping it being automatic is files that were added to Emacs since 2001. Comparing with an Emacs-21.x tree can help spot these. I omitted these, which have odd copyrights: composite.el ps-bdf.el t-mouse.el ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 22.0.91 working, lazy-lock documentation inconsistency?
Stefan Monnier wrote: However, I had to comment out lazy-lock from my .emacs. Why? (I mean, it's good that you did, but Emacs should still work just fine with lazy-lock: i.e. should not have been forced) I see the .el file is now is lisp/obsolete where it does not get installed by default, It does get installed. And it is autoloaded. `make autoloads' does not process lisp/obsolete, so lazy-lock-mode and fast-lock-mode do not get autoloaded. emacs -q --no-site-file (require 'font-lock) (fboundp 'jit-lock-mode) ; t (fboundp 'lazy-lock-mode) ; nil (fboundp 'fast-lock-mode) ; nil So people with settings for font-lock-support-mode in .emacs that involve fast-lock and lazy-lock will encounter errors complaining that f-l-mode and l-l-mode are not functions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Nick Roberts wrote:
I updated copyright years in the progmodes directory (for 2005 and
2006). I might have overlooked 1992-2003 but I think I was
following guidance at the time - I can't remember. Discussion on
emacs-devel in 2005 about copyright years might shed some light.
Snippet from message from rms to emacs-devel:
Subject: Simpler rules for copyright notices
Date: Wed, 07 Dec 2005 17:58:24 -0500
[...]
Do not abbreviate the year list using a range; for instance, do not
write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Richard Stallman wrote: Should things of the form 1992-2003 be expanded to every member year? That is an interesting question. I don't think CC mode was part of Emacs during all those years. When did it become part of Emacs? And what copyright years did it have then? The CVS repository for cc-mode.el (from the cc-mode website) shows that the statements This file is part of GNU Emacs and Copyright FSF were added in 1992. http://cc-mode.cvs.sourceforge.net/cc-mode/cc-mode/cc-mode.el?r1=2.193r2=2.194 http://cc-mode.cvs.sourceforge.net/cc-mode/cc-mode/cc-mode.el?r1=2.192r2=2.193 I also see there that the Copyright years 1992-1998 were all listed explicitly at one point, then in 1999 got changed to the compact form. So it seems pretty clear they should be put back. A few other files have odd Copyright notices, eg leim/MISC-DIC/CTLau.html leim/quail/CTLau.el lisp/international/titdic-cnv.el lisp/language/thai-word.el Eg who owns the copyright for thai-word.el in 2006? Who has owned titdic-cnv.el since 2002? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse and horizontal scrolling with long lines
Scrolling with the mouse in a buffer with lines wider than the window (with truncate-lines enabled) is problematic. As an example: emacs -q --no-site-file Delete the newlines in the initial message in the scratch buffer (so as to get a single long line of text wider than the window). M-x toggle-truncate-lines Click with the mouse within 5 columns of the right margin, but do not release the mouse button. At this stage, the window scrolls to centre point horizontally. The mouse cursor remains where it was, close to the right margin. The buffer basically looks as one would want it to. Release the mouse. Now point jumps to where the mouse cursor is, and the region between here and where point just was gets selected. The window scrolls horizontally again so as to centre the new point. This last behaviour is unwanted, and makes it quite difficult to scroll horizontally with the mouse, let along click and drag to create a selection across the initial window edge. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
bad copyright years
These files still have bad Copyright years: Makefile.in lisp/progmodes: cc-align.el cc-awk.el cc-cmds.el cc-compat.el cc-defs.el cc-engine.el cc-langs.el cc-menus.el cc-mode.el cc-styles.el cc-vars.el vhdl-mode.el Should things of the form 1992-2003 be expanded to every member year? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
Eli Zaretskii wrote: I would assume that M-x calendar must use the database directly to find out _when_ DST starts and ends to print the calendar correctly. It can do that, but it doesn't have to: it could alternatively pass the corresponding time_t value to the time routines and get the DST flag back as the result. The Lisp primitives that return the current time or time string should support that already. Am I totally missing the point here? The question to be answered is: what day of the year does Daylight Saving Time start/end? This is so it can be printed as a diary/holiday entry, eg so people know when to change their clocks. How do I do find that date in your method? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
Here's a patch that works in the manner I have tried to describe. It works with no noticeable slow-down on my (admittedly, fairly new) machine. I can install if desired. *** cal-dst.el 07 Feb 2006 23:46:47 -0800 1.24 --- cal-dst.el 09 Nov 2006 01:37:31 -0800 *** *** 42,47 --- 42,57 (require 'calendar) (require 'cal-persia) + (defcustom calendar-dst-check-each-year-flag t + Non-nil means to check each year for DST transitions as needed. + Nil means to assume the next two transitions found after the + current date apply to all years. This is faster, but not always + correct, since the dates of Daylight Saving transitions sometimes + change. + :type 'boolean + :version 22.1 + :group 'calendar) + (defvar calendar-current-time-zone-cache nil Cache for result of calendar-current-time-zone.) *** *** 199,236 (cdr candidate-rules))) (car candidate-rules))) ! (defun calendar-current-time-zone () ! Return UTC difference, dst offset, names and rules for current time zone. ! ! Returns (UTC-DIFF DST-OFFSET STD-ZONE DST-ZONE DST-STARTS DST-ENDS ! DST-STARTS-TIME DST-ENDS-TIME), based on a heuristic probing of what the ! system knows: ! ! UTC-DIFF is an integer specifying the number of minutes difference between ! standard time in the current time zone and Coordinated Universal Time ! (Greenwich Mean Time). A negative value means west of Greenwich. ! DST-OFFSET is an integer giving the daylight savings time offset in minutes. ! STD-ZONE is a string giving the name of the time zone when no seasonal time ! adjustment is in effect. ! DST-ZONE is a string giving the name of the time zone when there is a seasonal ! time adjustment in effect. ! DST-STARTS and DST-ENDS are sexps in the variable `year' giving the daylight ! savings time start and end rules, in the form expected by ! `calendar-daylight-savings-starts'. ! DST-STARTS-TIME and DST-ENDS-TIME are integers giving the number of minutes ! after midnight that daylight savings time starts and ends. ! ! If the local area does not use a seasonal time adjustment, STD-ZONE and ! DST-ZONE are equal, and all the DST-* integer variables are 0. ! ! Some operating systems cannot provide all this information to Emacs; in this ! case, `calendar-current-time-zone' returns a list containing nil for the data ! it can't find. ! (or !calendar-current-time-zone-cache !(setq ! calendar-current-time-zone-cache ! (let* ((t0 (current-time)) (t0-zone (current-time-zone t0)) (t0-utc-diff (car t0-zone)) (t0-name (car (cdr t0-zone --- 209,219 (cdr candidate-rules))) (car candidate-rules))) ! (defun calendar-dst-find-data (optional time) ! Find data on the first Daylight Saving Time transitions after TIME. ! TIME defaults to `current-time'. Return value is as described ! for `calendar-current-time-zone'. ! (let* ((t0 (or time (current-time))) (t0-zone (current-time-zone t0)) (t0-utc-diff (car t0-zone)) (t0-name (car (cdr t0-zone *** *** 261,267 (if ( t0-utc-diff t1-utc-diff) (list t0-name t1-name t1-rules t2-rules t1-time t2-time) (list t1-name t0-name t2-rules t1-rules t2-time t1-time) ! ))) ;;; The following eight defvars relating to daylight savings time should NOT be ;;; marked to go into loaddefs.el where they would be evaluated when Emacs is --- 244,325 (if ( t0-utc-diff t1-utc-diff) (list t0-name t1-name t1-rules t2-rules t1-time t2-time) (list t1-name t0-name t2-rules t1-rules t2-time t1-time) ! ) ! ! (defvar calendar-dst-transition-cache nil ! Internal cal-dst variable storing date of Daylight Saving Time transitions. ! Value is a list with elements of the form (YEAR START END), where ! START and END are expressions that when evaluated return the ! start and end dates (respectively) for DST in YEAR. Used by the ! function `calendar-dst-find-startend'.) ! ! (defun calendar-dst-find-startend (year) ! Find the dates in YEAR on which Daylight Saving Time starts and ends. ! Returns a list (YEAR START END), where START and END are ! expressions that when evaluated return the start and end dates, ! respectively. This function first attempts to use pre-calculated ! data from `calendar-dst-transition-cache', otherwise it calls ! `calendar-dst-find-data' (and adds the results to the cache). ! (let ((e (assoc year calendar-dst-transition-cache)) ! f) ! (or e ! (progn ! (setq e (calendar-dst-find-data (encode-time 1 0 0 1 1 year)) ! f (nth 4 e) ! e (list year f (nth 5 e)) ! calendar-dst-transition-cache ! (append calendar-dst-transition-cache (list e))) !
Re: calendar gets wrong end for Daylight Savings Time
Eli Zaretskii wrote: In C, you pass probe time_t values to the function localtime, until you find the value for which the tm_isdst flag in the struct tm returned by localtime changes from 0 to 1 or vice versa. In Lisp, we will need some Lisp binding to localtime or its sibling functions, to do the same. Perhaps the iterative solution can be coded in C, with only the result exposed to Lisp. Does this make sense? Apologies if I'm missing something. No, this makes sense. I'm trying to say, this essentially is what cal-dst does already (see calendar-next-time-zone-transition) to find the dates when DST starts/ends. But it (essentially) just does it once, for the next year, then assumes that the result it gets applies to every year. I have presented a patch which makes it do this iterative check for every year, the first time it encounters a given year. It doesn't seem to take an appreciable amount of time, so I don't think it's necessary to rewrite it in C. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
Eli Zaretskii wrote: No, Windows doesn't support Posix timezoneinfo data bases. It has its own information in the Registry, which is usually (maybe always) only for the current year. Thanks. I'm not surprised it's different... I guess, if Emacs needs the timezone database, we could distribute tzdata and some of the code based on tzcode with Emacs, for those platforms that don't have it as part of the OS. I don't think we need to do this. I think I have a solution that will work fine. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
James Cloos wrote: As you can see from that output America/Phoenix has not done daylight time since 1944 (US wartime national Mandate). Ah, thank you again for enlightenment! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
Richard Stallman wrote: I would assume that M-x calendar must use the database directly to find out _when_ DST starts and ends to print the calendar correctly. I guess that is true, for the sake of the holiday display. Given a way to check any given time for DST, it would not be too terribly hard to binary-search thru the calendar to find the DST start and end dates. This is what it does now, only it only does it for the next year, then assumes the result applies to every year. As I said before, I will try making it do this for every year when needed. Extracting the information directly from the tz database (which must contain it, in some format) would require less CPU, but more of my CPU to figure out how to do it (especially in a system-portable way). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
T. V. Raman wrote: while fixing this bug, it might be appropriate to update calendar for next march -- when the US switches back to daylight saving time in mid-March (was legistlated earlier this year) The fact that it is _already_ using the new rules is the source of this problem. Rather, it uses the system C library routines to find the dates of the next daylight time transition after the present date. So if the system zoneinfo database has been updated with the changes for the US next year, now that Oct 29th of this year is past, the next savings change that calendar-next-time-zone-transition finds is the one in March 2007. It then assumes that the information for next year applies to all years, hence it gets it wrong for years before 2007 in the US. Hmmm. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: european-calendar-style customize bug
Thanks for the report. I've installed a fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comment region in fortran mode
I've discovered that removing the line in mouse-set-region-1 that turns on transient-mark-mode makes the problem go away, but I'm just flailing around... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comment region in fortran mode
Hezi Gildor wrote: emacs -Q file.f I drag the mouse to highlight a region mouse-1- fortran-comment region error message: mark is not active now if I do set-mark using ctrl-@ or such, then use arrows to highlight a region, then use the mouse to do comment region, it works fine. The cause seems to be the use of (custom-menu-create 'fortran) in fortran-mode-map. Because the fortran customization group has subgroups, this results in something like: (defvar fortran-mode-map ... ; define-key bindings (easy-menu-define fortran-menu map Menu for Fortran mode. '(Fortran Comment :filter (lambda (rest junk) (custom-menu-create 'fortran-comment ...) When this item is in the mode map, selecting any menu item seems to deactivate the mark, if it was defined by dragging with the mouse. Eg: M-x fortran-mode click and drag with mouse-1 to highlight a region Tools-Spell Checking-Spell-Check region The mark is not active now I don't see why this should be - can anyone help? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sh-mode font-lock error
Stefan Monnier wrote: Should be fixed now, The latest sh-script.el correctly fontifies everything I throw at it so far. Many thanks; I found this bug quite annoying. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sh-mode font-lock error
Stefan Monnier wrote:
#!/bin/bash
gbytes=`echo $bytes_total | gawk '{printf(%5.1f), $1 / (1024^3)}'`
echo The time is now `date`
This was messed up already a month ago, right? I.e. it's not related to my
recent changes?
Yes, this was broken by the changes in rev 1.181.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sh-mode font-lock error
Stefan Monnier wrote:
Well, I believe the one I just installed does fix it, this time.
It fixes the previously posted example, but now this snippet is messed
up:
#!/bin/bash
gbytes=`echo $bytes_total | gawk '{printf(%5.1f), $1 / (1024^3)}'`
echo The time is now `date`
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sh-mode font-lock error
Stefan Monnier wrote: This was messed up already a month ago, right? I.e. it's not related to my recent changes? Oh, could be. I just got back from vacation, so my previous version of the CVS was a few weeks old. I'll check and see when this stopped working... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sh-mode font-lock error
Stefan Monnier wrote: I believe the patch below (just installed) fixes it, Sorry, but the patch has no effect on this case AFAICS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
sh-mode font-lock error
The (unintended?) change to sh-font-lock-keywords-1 in rev 1.182 of sh-script.el breaks font-locking, eg of bash scripts: emacs -q --no-site-file M-x sh-mode then type export - Error during redisplay: (error No match 4 in highlight (4 font-lock-builtin-face)) Reverting from (4 font-lock-builtin-face) to (6 font-lock-builtin-face) in sh-font-lock-keywords-1 fixes it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: sh-mode font-lock error
Stefan Monnier wrote:
Thanks. I've reverted it. It's actually a patch I had suggested
(mistakenly as I know see) and was waiting for confirmation that it
fixes another bug. So, back to that other bug,
Thanks. I get the impression (catching up on emacs mailing lists) you
are trying to fix font-locking of quoted and nested things. FYI, the
following (not uncommon, I would have thought) construct currently
does not fontify correctly. I'm pretty sure it used to...
#!/bin/bash
echo the time is `date`
## now everything is fontified as string.
[ $i -eq $j ] {
echo blah
exit 1
}
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: appt-display-format has bad Customize default and no value menu
Drew Adams wrote: M-x customize-variable appt-display-format The standard value is `ignore', and this is a mismatch (`ignore' is not a valid value). This is by design. ignore is a special value, meaning fall back on the previous (now obsolete) way of doing it, which used different variables. The available customize values represent the new way of doing it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: appt-display-format has bad Customize default and no value menu
Sorry, I did not read carefully enough the first time. I see custom barfs if I have a default value which is not in the allowed value list. I guess I will have to add 'ignore to the allowed value list. I wanted to avoid this because I specifically wanted people to have to choose any of the other settings when they customized this variable. Maybe I'm going about this wrong... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Click on fancy diary entry cause error if diary buffer was killed
I think this is fixed now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
