Menu bar is skrewed up when using filesets
If I want to use filesets and add (filesets-init) to my init file (~/.emacs.d/init.el) as suggested in the Emacs manual, the menu bar contains only the emacs and the fileset menu. All other menus (File, Edit, etc.) are missing. If have uploaded a screen shot to make clear what I am talking about: http://www.uni-jena.de/~p4buma/downloads/MissingMenus.png The problem seems to appear in every CVS Carbon Emacs I have built since end of January, before I never had this problem. There is no error message, even if I start Emacs using the --debug-init option. If i leave out the (filesets-init) line, everthing works fine. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.5.0) of 2006-03-17 on metallw08.timewe.uni-jena.de X server distributor `Apple Computers', version 10.4.5 configured using `configure '--without-x' '--prefix=/usr/local'' Important settings: value of $LC_ALL: de_DE.UTF-8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: encoded-kbd-mode: t global-balanced-mode: t balanced-mode: t recentf-mode: t iswitchb-mode: t msb-mode: t display-time-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 transient-mark-mode: t abbrev-mode: t Recent input: mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 home C-s f i l e s e t C-s C-x k return C-x b i n return help-echo help-echo down-mouse-2 mouse-2 wheel-down double-wheel-down triple-wheel-down triple-wheel-down wheel-down double-wheel-down help-echo help-echo help-echo help-echo tool-bar Back in history help-echo help-echo help-echo down-mouse-2 mouse-2 wheel-down double-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down help-echo help-echo help-echo help-echo tool-bar Back in history help-echo help-echo help-echo down-mouse-2 mouse-2 wheel-down wheel-up wheel-down double-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down M-x r e p o r t - e m a c s - n backspace b u g return Recent messages: Recognizing tables...done View mode: type C-h for help, h for commands, q to quit. Mark set self-insert-command: Buffer is read-only: #buffer PROBLEMS Loading debug...done Entering debugger... Mark set Mark saved where search started Unable to load color BrightBlack Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu bar is skrewed up when using filesets
On Mon, 20 Mar 2006 09:51:53 +0100, Martin Buchmann [EMAIL PROTECTED] said: If I want to use filesets and add (filesets-init) to my init file (~/.emacs.d/init.el) as suggested in the Emacs manual, the menu bar contains only the emacs and the fileset menu. All other menus (File, Edit, etc.) are missing. I could not reproduce it, but could you test if the following patch makes some difference on your side? YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/macmenu.c === RCS file: /cvsroot/emacs/emacs/src/macmenu.c,v retrieving revision 1.38 diff -c -r1.38 macmenu.c *** src/macmenu.c 22 Feb 2006 07:59:34 - 1.38 --- src/macmenu.c 20 Mar 2006 09:37:46 - *** *** 63,71 #include dispextern.h #define POPUP_SUBMENU_ID 235 ! #define MIN_POPUP_SUBMENU_ID 512 ! #define MIN_MENU_ID 256 ! #define MIN_SUBMENU_ID 1 #define DIALOG_WINDOW_RESOURCE 130 --- 63,71 #include dispextern.h #define POPUP_SUBMENU_ID 235 ! #define MIN_POPUP_SUBMENU_ID 4096 ! #define MIN_MENU_ID 1 ! #define MIN_SUBMENU_ID 256 #define DIALOG_WINDOW_RESOURCE 130 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: self-insert-command advice is not called when command is run
Oops! This bug was my mistake. Ignore it please; I had mistakenly deleted the remapping from self-insert-command to balanced-self-insert-command, which was put in explicitly to handle this case. -- MJF ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
edit-abbrevs questions - new edit-sorted-abbrevs function
Herewith a more detailed description of already mentioned problems with `edit-abbrevs' - proposed solutions inclusive. 1) in contrast with the documentation, which declares edit-abbrevs and list-abbrevs to differ only in displaying, I see no way to call edit-abbrevs with an option `local'. `edit-abbrevs' starts at the top of the *Abbrev*-Buffer with the complete listing of all abbrevs below. Presently its up to the user to select the abbrev-table to edit. As the mode-line of `my-file.el' I switched from displayed (Emacs-Lisp Abbrev), I concluded to edit the `(emacs-lisp-mode-abbrev-table)' - what was a mistake. Editing there had no effect, I had to edit `(lisp-mode-abbrev-table)', only then are new definitions afterwards are available. 2) if editing *Abbrevs* with narrowed buffer, a call of edit-abbrevs-redefine on this narrowed buffer deletes all other abbrevs without warning. That's dangerous. Proposed Solutions: AFAIS there is a quick solution to #2 by providing `(widen)' to `edit-abbrevs-redefine': *** ar-emacs/lisp/abbrev.el 2006-03-20 10:43:26.0 +0100 --- emacs/lisp/abbrev.el2006-03-17 21:02:38.0 +0100 *** *** 159,165 (defun edit-abbrevs-redefine () Redefine abbrevs according to current buffer contents. (interactive) - (widen) (define-abbrevs t) (set-buffer-modified-p nil)) --- 159,164 Proposal to #1: To facilitate the selection of the abbrev-table to edit, AFAIS there is a minor and a major solution. The latter I conceive in reverting the global-abbrev-editing approach into an table-by-table style, always editing and re-writing a section in order to avoid loading a big abbrev-file at once. The minor solution would always load the complete abbrev_defs, - as its the current state - introduce narrowing and use `(abbrev-table-name local-abbrev-table)' to set the `region-beginning'. Together with the already described introduction of `widen' there will be no harm. My results so far in the minor way (the option now is global, not local, as I usually need the mode-abbrevs to edit:) (defun edit-sorted-abbrevs (optional global) (interactive P) (save-excursion (let ((table local-abbrev-table) (table-name (abbrev-table-name local-abbrev-table))) (set-buffer (get-buffer-create *Abbrevs*)) (switch-to-buffer *Abbrevs*) (erase-buffer) (dolist (table abbrev-table-name-list) (insert-abbrev-table-description table t)) (goto-char (point-min)) (set-buffer-modified-p nil) (edit-abbrevs-mode) (unless global (re-search-forward (format (%s) table-name) nil t 1) (let ((table-head (line-beginning-position)) (start (progn (re-search-forward ^\ nil t 1) (match-beginning 0))) (end (save-excursion (re-search-forward ^[ \t]*(.+mode-abbrev-table nil t 1) (forward-line -1) (point (narrow-to-region start end) ;; multiline-abbrevs will make trouble when sort (save-excursion (if (re-search-forward ^[A-Za-zäöüÄÖÜß0-9 \t] nil t 1) (message %s %s Cann't sort. Don't declare multiline-abbrevs. Error at point: (point))) (beginning-of-line) (sort-lines nil start end)) (widen) (narrow-to-region table-head end) (goto-char (point-min)) (forward-line 1) (just-one-empty-line))) (when global (widen) (point-min) __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii [EMAIL PROTECTED] writes: Are you using MSYS? yes, i'm using MinGW + MSYS. Would you please stop offending the few volunteers who maintain the Windows port? Even if you believe the problem is still unsolved, that's not a reason good enough to say that ``nobody cares'' about it. Sorry, if you feel offended. I just happen to bump into a problem and searched the web and found the same problem has been reproted before. If some GNU Emacs developers feel offended by the referencing of an old report, I could just describe the problem next time, no more any referencing. But that is a quite strange request, I don't think it's anybody's fault if there's a subtle unsolved bug in a program, because different people has a diverse different system configuration. I'm not a native english speaker, I have to reference the dictionary many times while composing email in english, It's quite an opportunity I pick up a wrong word to express my thought. If some people feel offended, sorry for that. And finally, thanks for your correction of the grammer. The facts are utterly different from your assertion: out of the 3 problems reported in that message, 2 are already resolved (albeit in a way that is different from what was suggested there). As for the 3rd, the one with the absent DOC file, I asked at some point to provide details about it, but got no responses. If you can afford investing some effort in working with us on this problem, I'm sure we will resolve it in no time. May be I didn't describe the problem clearly. The problem is bootstrap stoped while compliling lisp/url/vc-dav.el, it complains that there's no DOC file in the etc/ directory, so I have to copy the `DOC' file from lib-src/ to etc/ manually and bootstrap again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Scrolling completions with Eshell on terminal.
In GNU Emacs 22.0.50.34 (i686-pc-linux-gnu, GTK+ Version 2.8.13) of 2006-03-15 on escpc40 X server distributor `The X.Org Foundation', version 11.0.6090 configured using `configure '--with-gtk'' When running on a terminal the *Completions* buffer isn't scrolled when there are more completions than fit in the window and TAB is hit at an Eshell prompt multiple times. This seems to be because the: (event-matches-key-specifier-p event 'tab) test in pcomplete-show-completions returns nil on a terminal. (Actually, event-matches-key-specifier-p in just an alias for eq in GNU Emacs.) The attached patch fixes this for me, but may not be the best fix. Thanks, Matt --- pcomplete.el 07 Feb 2006 07:59:09 + 1.23 +++ pcomplete.el 17 Mar 2006 08:41:55 + @@ -978,7 +978,9 @@ (set-window-configuration pcomplete-last-window-config) (setq pcomplete-last-window-config nil) (throw 'done nil)) - ((event-matches-key-specifier-p event 'tab) + ((or (event-matches-key-specifier-p event 'tab) +;; Needed on a terminal +(event-matches-key-specifier-p event 9)) (save-selected-window (select-window (get-buffer-window *Completions*)) (if (pos-visible-in-window-p (point-max)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C indentation error.
I got an error with some C indentation in macro definitions in GNU Emacs 22.0.50.34 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-03-02. Error is triggered by: With emacs -Q : In scratch, insert the following: #foo :\ bar Toggle to c-mode, and try to indent the last line. I get: Invalid search bound (wrong side of point). However, looking at the code of search_command, I'm wondering why an error could be output even if noerror is t or a symbol [1] ; fixing this that way : The noerror argument means no error if the search fails. Invalid arguments are a different issue. I will clarify this in the Lisp manual. So your proposed change in search.c should not be installed. Instead, the code in CC mode should be fixed not to pass invalid search bounds. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse wheel doesn't work
This bug report will be sent to the Free Software Foundation, not to your local site managers! Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Wheh I roll my mousewheel, I get the error message triple-wheel-up is undefined (or down). In emacs 21.3.1, using the same mouse, OS and .emacs, the mousewheel works. Scott In GNU Emacs 22.0.50.2 (i386-mingw-nt5.1.2600) of 2005-04-16 on LAPTOP Distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: show-paren-mode: t iswitchb-mode: t encoded-kbd-mode: t tooltip-mode: t menu-bar-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 line-number-mode: t transient-mark-mode: 1 next-error-follow-minor-mode: Fol Recent input: C-x C-f C-a C-f C-f C-f C-f C-b C-. C-x C-f C-a C-f C-f C-f C-. C-x C-f C-a C-f C-f C-f C-k . e m tab return wheel-down double-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down triple-wheel-down wheel-up double-wheel-up triple-wheel-up triple-wheel-up triple-wheel-up wheel-up double-wheel-up triple-wheel-up M-x e m a c s tab v e r tab return M-x r e p o r t - b u tab backspace backspace e m tab return Recent messages: Loading paren...done Toggling tool-bar-mode off; better pass an explicit argument. Toggling mouse-wheel-mode off; better pass an explicit argument. Loading ~/.emacs.gnu...done For information about the GNU Project and its goals, type C-h C-p. Quit [2 times] Loading jit-lock...done Loading goto-addr...done GNU Emacs 22.0.50.2 (i386-mingw-nt5.1.2600) of 2005-04-16 on LAPTOP Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Scrolling completions with Eshell on terminal.
-((event-matches-key-specifier-p event 'tab) +((or (event-matches-key-specifier-p event 'tab) +;; Needed on a terminal +(event-matches-key-specifier-p event 9)) Maybe you could use something like last-nonmenu-event instead so it also works for people who use some other key. Although I'm not sure it actually solves your problem (I can never remember which events are raw and which have been translated through function-key-map and friends). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Date: Sat, 18 Mar 2006 00:35:36 +0800 From: Zhang Wei [EMAIL PROTECTED] Cc: Bootstrap Emacs with MinGW under WindowsXP failed due to compiling lisp/usr/vc-dav.el requires file DOC must be present under directory etc/ Are you using MSYS? And I find this problem has been reported before, and a patch has been proposed: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00388.html It seems nobody care about that. Would you please stop offending the few volunteers who maintain the Windows port? Even if you believe the problem is still unsolved, that's not a reason good enough to say that ``nobody cares'' about it. The facts are utterly different from your assertion: out of the 3 problems reported in that message, 2 are already resolved (albeit in a way that is different from what was suggested there). As for the 3rd, the one with the absent DOC file, I asked at some point to provide details about it, but got no responses. If you can afford investing some effort in working with us on this problem, I'm sure we will resolve it in no time. So please consider providing a complete transcript of the bootstrap process in your environment, up to and including the portion where it fails due to the missing DOC file. I don't have MSYS installed, and in my environment the bootstrap succeeds every time. So I need to see the details of your build to understand what goes wrong and why. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii [EMAIL PROTECTED] writes: From: Dieter Deyke [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Date: Sat, 18 Mar 2006 09:22:56 -0700 I am seeing the DOC error too. My setup: english Windows XP Pro, MinGW-3.1.0-1, cygwin tool set, no msys. Logfile: [...] In toplevel form: url/vc-dav.el:29:1:Error: Cannot open doc string file c:/Users/deyke/emacs-build/work/etc/DOC make[1]: *** [compile-SH] Error 1 make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' make: *** [bootstrap-gmake] Error 2 Thanks, this gives me something that I can work with. Here's the problem: Emacs shouldn't even look for the file named DOC, it should look for DOC-X. This is because loadup.el has this fragment: (if (memq system-type '(ms-dos windows-nt)) (setq name (expand-file-name (if (fboundp 'x-create-frame) DOC-X DOC) ../etc)) (setq name (concat (expand-file-name ../etc/DOC-) name)) (if (file-exists-p name) (delete-file name)) (copy-file (expand-file-name ../etc/DOC) name t)) (Snarf-documentation (file-name-nondirectory name))) So, on Windows, since x-create-frame is bound, it calls Snarf-documentation with the argument DOC-X. Snarf-documentation then records this name in the variable internal-doc-file-name, and that name is dumped in emacs.exe. So when byte-compiling for some reason calls for a doc file, Emacs should look for DOC-X. Can you see where the above breaks on your system? In particular, when does Vdoc_file_name (defined in doc.c) gets assigned the file name which ends with DOC, not DOC-X? Thanks. I'm not sure on how to debug this. Let me start to point out that there were 3 errors about missing DOC, but the first 2 were not fatal: ... In toplevel form: url/url-dav.el:36:1:Error: Cannot open doc string file c:/Users/deyke/emacs-build/work/etc/DOC Compiling url/url-dired.el Wrote c:/Users/deyke/emacs-build/work/lisp/url/url-dired.elc Compiling url/url-expand.el Wrote c:/Users/deyke/emacs-build/work/lisp/url/url-expand.elc Compiling url/url-file.el ... In toplevel form: url/url-handlers.el:243:1:Error: Cannot open doc string file c:/Users/deyke/emacs-build/work/etc/DOC Compiling url/url-history.el Wrote c:/Users/deyke/emacs-build/work/lisp/url/url-history.elc Compiling url/url-http.el ... In toplevel form: url/vc-dav.el:29:1:Error: Cannot open doc string file c:/Users/deyke/emacs-build/work/etc/DOC make[1]: *** [compile-SH] Error 1 make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' make: *** [bootstrap-gmake] Error 2 Second, after that build stopped, a find | grep DOC came up empty, so if anything would expect to find DOC-X, there was none to be found. Next I probed loadup.el: system-type -- windows-nt (fboundp 'x-create-frame) -- t (setq name (expand-file-name (if (fboundp 'x-create-frame) DOC-X DOC) ../etc)) -- c:/Users/deyke/emacs-build/etc/DOC-X Finally, this is my current work-aound, which seems to give me a working emacs, although I do not know if the DOC strings are all OK: cd work/nt call configure.bat --with-gcc --no-debug --no-cygwin --cflags -IC:/Users/deyke/emacs-build/include --prefix C:/emacs make bootstrap REM The last command will have failed with errors, finish the job cd /d %basedir%\work\lib-src make DOC copy DOC ..\etc\DOC cd /d %basedir%\work\nt make cd /d %basedir%\work\lisp make recompile EMACS=../src/oo-spd/i386/emacs cd /d %basedir%\work\nt make info So, could you please guide me in what I have to do to debug this? Thanks, -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
From: Dieter Deyke [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Date: Sat, 18 Mar 2006 12:55:35 -0700 I'm not sure on how to debug this. Let me start to point out that there were 3 errors about missing DOC Yes, I've seen those as well in your transcript. Needless to say, in my builds none of them are present. but the first 2 were not fatal: No, they are all fatal. It's just that the shell's for loop invoked by Make doesn't stop until it finishes (you will see that url/vc-dav.el is the last Lisp file that is compiled), so Make only sees the non-zero exit status when the list of files to compile is exhausted and the subsidiary shell exits. Second, after that build stopped, a find | grep DOC came up empty, so if anything would expect to find DOC-X, there was none to be found. In my builds, I don't have DOC-X either, at this stage of the build. But the problems still don't happen for me. I think Emacs shouldn't look for the doc string file at all at this place. The DOC vs DOC-X thing was just another strange thing, so I mentioned it. So, could you please guide me in what I have to do to debug this? Well, one way to try to debug this is to say make bootstrap again (without the workaround), let it fail, then run Emacs under GDB and let it byte-compile the offending file vc-dav.el with precisely the same command-line arguments as when Emacs is run from Make. But before you run Emacs, after starting GDB, set a breakpoint in doc.c, in the function get_doc_string, on the line which says: error (Cannot open doc string file \%s\, name); (this is the line that displays the error message and aborts the compilation). When this breakpoint breaks, please post here the backtrace. Maybe that would give us some ideas. TIA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii [EMAIL PROTECTED] writes: Thanks. At this point, it would help if you do the following: . Print the value of filepos: (gdb) p filepos (gdb) pr . Print the value of Vdoc_file_name, which should be a string: (gdb) p Vdoc_file_name (gdb) pr . Print the value of Vdoc_directory, which should also be a string: (gdb) p Vdoc_directory (gdb) pr . Produce a Lisp backtrace: (gdb) xbacktrace . Post here the results. (gdb) break 196 Breakpoint 1 at 0x110d68c: file doc.c, line 196. (gdb) run Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/emacs.exe -f batch -byte-compile url/vc-dav.el Breakpoint 1, get_doc_string (filepos=-2047792, unibyte=0, definition=0) at doc.c:196 196 error (Cannot open doc string file \%s\, name); (gdb) source ../src/.gdbinit Environment variable DISPLAY not defined. Environment variable TERM not defined. Breakpoint 2 at 0x1152a76: file w32fns.c, line 8965. Breakpoint 3 at 0x109f0e6: file sysdep.c, line 1395. (gdb) p filepos $1 = -2047792 (gdb) pr warning: - warning: 2 warning: 5 warning: 5 warning: 9 warning: 7 warning: 4 (gdb) p Vdoc_file_name $2 = 35481283 (gdb) pr warning: warning: D warning: O warning: C warning: (gdb) p Vdoc_directory $3 = 35480707 (gdb) pr warning: warning: c warning: : warning: / warning: U warning: s warning: e warning: r warning: s warning: / warning: d warning: e warning: y warning: k warning: e warning: / warning: e warning: m warning: a warning: c warning: s warning: - warning: b warning: u warning: i warning: l warning: d warning: / warning: w warning: o warning: r warning: k warning: / warning: e warning: t warning: c warning: / warning: (gdb) xbacktrace ad-real-documentation ad-subr-arglist ad-arglist ad-make-advised-definition ad-activate-advised-definition ad-activate byte-code require byte-code load load-library eval-buffer let unwind-protect let* if load-with-code-conversion load let if 0x210aa65 Lisp type 5 funcall progn ---Type return to continue, or q return to quit--- condition-case if let let let command-line unwind-protect let if normal-top-level (gdb) -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C indentation error.
Richard Stallman [EMAIL PROTECTED] writes:
I got an error with some C indentation in macro definitions in GNU
Emacs 22.0.50.34 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2006-03-02.
Error is triggered by:
With emacs -Q :
In scratch, insert the following:
#foo :\
bar
Toggle to c-mode, and try to indent the last line.
I get: Invalid search bound (wrong side of point).
However, looking at the code of search_command, I'm wondering why
an error could be output even if noerror is t or a symbol [1] ;
fixing this that way :
The noerror argument means no error if the search fails.
Invalid arguments are a different issue.
I will clarify this in the Lisp manual.
So your proposed change in search.c should not be installed.
That's what I thought ; I was trying to get a reaction for this bug
report ;-)
Instead, the code in CC mode should be fixed not to pass invalid
search bounds.
After a little more search, I propose the following change :
Index: lisp/progmodes/cc-engine.el
===
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cc-engine.el,v
retrieving revision 1.47
diff -c -r1.47 cc-engine.el
*** lisp/progmodes/cc-engine.el 24 Feb 2006 15:33:02 - 1.47
--- lisp/progmodes/cc-engine.el 19 Mar 2006 17:59:56 -
***
*** 5916,5922
;; it shouldn't apply when we check the
;; preceding label.
c-record-type-identifiers)
!(c-forward-syntactic-ws)
(c-forward-label nil pte start
;; Check that the next nonsymbol token is :. Allow '('
--- 5916,5922
;; it shouldn't apply when we check the
;; preceding label.
c-record-type-identifiers)
!(c-forward-syntactic-ws pte)
(c-forward-label nil pte start
;; Check that the next nonsymbol token is :. Allow '('
--
Well... It fixes the bug, really, but it doesn't investigate the bug
as it probably should be ; the bug _may_ be in c-forward-sws, a too
long function for me to work on ;-)
Bye !
--
Michael Cadilhac, a.k.a. Micha [mika] |
Epita/LRDE promo 2007 | )\._.,--,'``.
123 av. de Fontainebleau | 08.70.65.13.14 | /. _.. \ _\ (` ._,.
94270 Le Kremlin Bicetre | 06.23.20.31.30 | '._.-(,_..'--(,_...`-..'
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Xft Jhd refresh
2006/3/20, Jan Djärv [EMAIL PROTECTED]: The branch you are using is probably not going to be updated much more. There is (or will be?) another branch that merges the Xft changes with the unicode-2 Emacs branch. However, I don't see a tag for it in CVS. I never created the branch because the guy who wanted to hack on it didn't actually have CVS write access, so it didn't seem useful (might as well just apply the diff to his own sources), and he didn't seem to be an arch user. I'm happy to create and maintain a branch if it's useful for something though. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu bar is skrewed up when using filesets
Hi, YAMAMOTO Mitsuharu said the following on 20.03.2006 10:45 Uhr: I could not reproduce it, but could you test if the following patch makes some difference on your side? Thanks for your efforts. Applying your patch, doesn't change anything after recompiling. After I erased all of the customization for the filesets section and the ~/.filesets-cache.el file, filesets are working fine again. Nevertheless, I don't understand how a corrupted cache file or a wrong customization could lead to this behaviour. Best regards Martin -- No one can make you feel inferior without your consent. -- Eleanor Roosevelt ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse wheel doesn't work
Date: Sun, 19 Mar 2006 06:57:12 -0800 From: Scott Otterson [EMAIL PROTECTED] Wheh I roll my mousewheel, I get the error message triple-wheel-up is undefined (or down). In emacs 21.3.1, using the same mouse, OS and .emacs, the mousewheel works. Thank you for your report. In GNU Emacs 22.0.50.2 (i386-mingw-nt5.1.2600) of 2005-04-16 on LAPTOP Distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' This is a very old build of the CVS codebase. In the current CVS, the error message does not appear, so it appears that the problem was solved since then. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tooltip-mode = nil only displays first line of multi-line text-properties or overlays
Date: Sun, 19 Mar 2006 21:52:00 -0800 From: M Jared Finder [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Richard Stallman wrote: I think this is intentional. Changing the height of the echo area as you move the mouse would be rather unpleasant. It could combine the tooltip string lines, and display as much text as will fit in the echo area. Would that be better? If this is intentional, the documentation for tooltip-mode should be changed (as well as the info page on tooltips). I rather think it's a bug. We already change the height of the echo area when a multi-line string is displayed there, so I don't see any reason to avoid that for help echo. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse cursor bug?
Hi all, I finally figure out how to reproduce this bug though I have known it for a while. 1. Fire up gnus 2. middle click a group with a small number of unread articles so that you won't be interrupted to enter the number of articles. Make sure you mouse cursor won't be on any clickable text when enter the group. *NB*: You may need to hold down the middle button slightly longer than usual when middle click the group. Your mouse cursor will still has a 'hand shape' after entering the group. I have recorded this process in a gif file located here: http://people.pwf.cam.ac.uk/sl392/emacs/emacs_cursor.gif Hope you can reproduce this and fix it. -- Leon GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of 2006-03-20 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tooltip-mode = nil only displays first line of multi-line text-properties or overlays
I think this is intentional. Changing the height of the echo area as you move the mouse would be rather unpleasant. It could combine the tooltip string lines, and display as much text as will fit in the echo area. Would that be better? If this is intentional, the documentation for tooltip-mode should be changed (as well as the info page on tooltips). I rather think it's a bug. We already change the height of the echo area when a multi-line string is displayed there, so I don't see any reason to avoid that for help echo. IIRC the miniwindow used to resize for tooltips and it was changed specifically because it was found to be annoying. I.e. it's a feature. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: file-cache doc should state that the cache is non-persistent
I said: Looking at both the File Name Cache node in the Emacs manual and the Lisp source code, I see nothing that indicates whether or not the cache is persistent. This is an important piece of information. The doc should make it clear that the cache is not persistent and that it launches `find' each time you use it to find a file. Sorry; strike the last phrase about `find'. I believe the rest is accurate, though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
File name completion in mini-buffer cannot expand Cé
Hello! A file with the name Cécile does not expand when I type C-x f Cé TAB. When I type C-x f C TAB a *Completions* buffer shows Possible completions are: CDRecord CPUs Calender.pdf Calender.ps Cécile Chaos Country Domain Names Courier New.cmap.xml From this list I can select with mouse-2 the file name. In Mac OS X file names are saved as de-composed UTF-8, the name Cécile becomes Ce¨cile. The *Completions* buffer indeed shows Ceboxcile, and the box itself is: character: (332481, #o1211301, #x512c1, U+0301) charset: mule-unicode-0100-24ff (Unicode characters of the range U+0100..U+24FF.) code point: #x25 #x41 syntax: w which means: word category: ^:Combining diacritic or mark buffer code: #x9C #xF4 #xA5 #xC1 file code: #xCC #x81 (encoded by coding system mule-utf-8-unix) display: by this font (glyph code) -bh-lucida sans typewriter-bold-r-normal--10-98-74-74-m-60- iso10646-1 (#x301) In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.5.0, X toolkit, Xaw3d scroll bars) of 2006-03-17 on Latsche.local X server distributor `The XFree86 Project, Inc', version 11.0.4040 configured using `configure '--without-sound' '--without-pop' '--with- xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--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 -mabi=altivec -mcpu=7450 -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=-dead_strip -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: nil 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: Shell Minor modes in effect: desktop-save-mode: t display-time-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 transient-mark-mode: t -- Greetings Pete ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence?'' -- Peter Flynn ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: self-insert-command advice is not called when command is run
self-insert-command is handled specially by the command loop. Is it actually useful nowadays? Couldn't we get rid of this optimization? I am not sure. Yes, computers are faster. But this is the most common command in Emacs--most of the keystrokes are this command. However, it would be ok to verify that the command has not been redefined from its normal value, before executing it directly. That way the optimization would still apply in normal circumstances. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tooltip-mode = nil only displays first line of multi-line text-properties or overlays
Date: Tue, 21 Mar 2006 05:54:06 +0900 From: Miles Bader [EMAIL PROTECTED] Cc: M Jared Finder [EMAIL PROTECTED], emacs-pretest-bug@gnu.org 2006/3/21, Eli Zaretskii [EMAIL PROTECTED]: I rather think it's a bug. We already change the height of the echo area when a multi-line string is displayed there, so I don't see any reason to avoid that for help echo. It could be _quite_ annoying; tooltips tend to pop up more often, and more randomly than normal echo-area messages. But we are talking about a very rare situation: (a) the user deliberately asked for the help echo to be displayed in the echo area, and (b) the help echo text is multi-line. If they are _quite_ annoyed, they can go back to the normal tooltips. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tooltip-mode = nil only displays first line of multi-line text-properties or overlays
Cc: M Jared Finder [EMAIL PROTECTED], emacs-pretest-bug@gnu.org From: Stefan Monnier [EMAIL PROTECTED] Date: Mon, 20 Mar 2006 16:06:41 -0500 IIRC the miniwindow used to resize for tooltips and it was changed specifically because it was found to be annoying. Perhaps back when the MS-Windows port didn't have real tooltips, it was annoying. Nowadays this will happen only if the user really wants them to go to the echo area. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
