Re: crash: memcpy, XChangeProperty, XSetTextProperty, XSetWMIconName, x_set_name_internal
I always use -O0 -fno-inline, since that makes debugging easier. It can also make the bug disappear, thus making debugging impossible. If the bug depends on GCC options, that offers another way to debug it. You try compiling various parts of Emacs with different options until you narrow it down to one function. Then you read the assembler code for that function, made in the two different ways, and see what's different. Or you compare the assembler code that fails with the source code and see where the compiler produced invalid code. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error during redisplay with included diary file
I tracked down the source of the error and it turned out, probably not surprisingly, to be a simple mistake on my part. I give the details below for the record and because it may be instructive to some others (it certainly was to me!). Read on if you're still interested... On Tue, 06 Dec 2005 14:14:31 + Jason Rumney [EMAIL PROTECTED] wrote: Stephen Berman [EMAIL PROTECTED] writes: Further, as a string it is the value of a variable used in a function I wrote modelled on make-diary-entry. How exactly is it used in that function? That function and the variable turn out to have nothing to do with the error. Breakpoint 3, safe_eval_handler (arg=140906725) at xdisp.c:2236 2236 add_to_log (Error during redisplay: %s, arg, Qnil); #0 safe_eval_handler (arg=140906725) at xdisp.c:2236 #1 0x081508a8 in internal_condition_case_1 (bfun=0x81519c0 Feval, arg=139399637, handlers=137489449, hfun=0x806c440 safe_eval_handler) at eval.c:1496 #2 0x08064fad in safe_eval (sexpr=139399637) at xdisp.c:2261 #3 0x080773aa in display_mode_element (it=0xbf8e8e54, depth=1, field_width=0, precision=0, elt=value optimized out, props=137489401, risky=0) at xdisp.c:16587 #4 0x080779a9 in display_mode_line (w=value optimized out, face_id=HEADER_LINE_FACE_ID, format=139399757) at xdisp.c:16182 What is your mode-line-format? Does it use that function you wrote? This was the key to finding the source of the error; thanks for drawing attention to it! It's actually not the mode line where the error arises but, as indicated by the value of face_id, the header line. I use David Ponce's tabbar.el, which turns the header line into sets of tabs, e.g. for (groups of) visited buffers. I've made various modifications to tabbar.el to suit my needs; one was the following modification of the function tabbar-buffer-groups (only the relevant lines shown): (defun srb-tabbar-buffer-groups () Return the list of group names the current buffer belongs to. Return a list of one element based on major mode. (list (cond ... ((or ... ... (eval-after-load ~/.emacs.d/todo+cal+diary+appt.el (member (buffer-file-name) (srb-diary-files Diary) ...))) This assigns the buffer tab of a visited included diary file to the Diary buffer group by extracting the absolute file name from the diary file (that's what srb-diary-files, which is defined in the file named above, does). This works fine for creating the tab bar. But I overlooked, or failed to appreciate, that the form that eval-after-load operates on in the above is the value of `(member (buffer-file-name) (srb-diary-files))', which is in fact the string /home/steve/diary-Abendessen.txt (since that is #included in my diary-file), and consequently, `(/home/steve/diary-Abendessen.txt)' gets added to after-change-alist. And the subsequent attempt to eval this raises the error I saw in *Messages*: Error during redisplay: (invalid-function /home/steve/diary-Abendessen.txt) The immediate fix is simply to quote the form to be evalled, thereby making it a valid argument. However, while that no longer raises an error, it wrecks the grouping of buffers into tabs, since the quoted form is always a non-nil condition, which means the evaluation of the cond stops there and every subsequently visited buffer is grouped in the Diary tab. Rather, what's needed is for the loading of the file containing the definition of srb-diary-files to be conditioned on whether that function is void, i.e., whether its symbol is fboundp. So that's the happy end of my story. It was an interesting learning experience. Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
find-file sometimes doesn't
In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file) RET won't find the given file. However, the symptom is that if I'm editing buffer foo, and run find-file to open file bar, instead of getting two equally-sized windows containing foo and bar, I get two foo windows, one of which is only three lines high. There is a slight light show or noticeable flicker of buffers as if someone had forgotten to use save-excursion. There aren't any clues in the *Messages* buffer. Has anyone else seen this? Sorry, I not yet have a recipe, but will provide more details when and if I get them. Coincidentally in the last week, I've noticed that when Emacs starts, instead of the splash screen taking up the entire frame, the last buffer edited (I use desktop) appears, with a small GNU Emacs window at the bottom saying to use C-l to start editing. The coincidence is that this small window is also three lines and is accompanied by the same light show as I mentioned above. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: completion in find-file
From: Juri Linkov [EMAIL PROTECTED] Date: Wed, 07 Dec 2005 23:34:23 +0200 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org If so, is there a way to customize it and get back the old behaviour? The Emacs Manual says how to customize key bindings. I checked the Emacs Manual and can't find a place where it says about the fact that SPC is not bound in filename completion. It says in the node (info (emacs)Completion Commands) that SPC completes a word in the minibuffer and is bound to minibuffer-complete-word. Maybe is should warn that this doesn't work for file names? The manual _will_ document the changes in SPC binding when Emacs prompts for file names, once this change is reflected in documentation. Right now, etc/NEWS doesn't have the +++ mark near the entry which mentions this change, which is a sign that the docs was not yet updated as per this change. Also two new map variables are not documented in the Emacs Lisp manual. Likewise: the entry in NEWS lacks the +++ mark. Perhaps they should be documented in (info (elisp)Reading File Names) as old existing two map variables (i.e. with SPC binding) are already documented in (info (elisp)Completion Commands). Documentation patches are welcome. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(no subject)
Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier [EMAIL PROTECTED] * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I'm not sure if the MH-E code is broken and was living on borrowed time or whether a recent change broke Emacs. Please advise. (defun mh-folder-completing-read (prompt default allow-root-folder-flag) Read folder name with PROMPT and default result DEFAULT. If ALLOW-ROOT-FOLDER-FLAG is non-nil then \+\ is allowed to be a folder name corresponding to `mh-user-path'. (mh-normalize-folder-name (let ((minibuffer-completing-file-name t) (completion-root-regexp ^[+/]) (minibuffer-local-completion-map mh-folder-completion-map) (mh-allow-root-folder-flag allow-root-folder-flag)) (completing-read prompt 'mh-folder-completion-function nil nil nil 'mh-folder-hist default)) t)) -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
SPC no longer completes when minibuffer-completing-file-name is t
[Resending without a Mail-Followup-To and with a Subject :-(. If you responded to the previous copy, you may have to resend it to emacs-pretest-bug@gnu.org if this address wasn't a recipient.] Emacs now inserts a space when trying to complete an MH-E folder (for example, when visiting a folder or refiling a message). Could this change be responsible? 2005-12-06 Stefan Monnier [EMAIL PROTECTED] * minibuf.c (keys_of_minibuf): Just unbind SPC in Vminibuffer_local_filename_completion_map rather than forcing it explicitly to the same binding as the global map. In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I'm not sure if the MH-E code is broken and was living on borrowed time or whether a recent change broke Emacs. Please advise. (defun mh-folder-completing-read (prompt default allow-root-folder-flag) Read folder name with PROMPT and default result DEFAULT. If ALLOW-ROOT-FOLDER-FLAG is non-nil then \+\ is allowed to be a folder name corresponding to `mh-user-path'. (mh-normalize-folder-name (let ((minibuffer-completing-file-name t) (completion-root-regexp ^[+/]) (minibuffer-local-completion-map mh-folder-completion-map) (mh-allow-root-folder-flag allow-root-folder-flag)) (completing-read prompt 'mh-folder-completion-function nil nil nil 'mh-folder-hist default)) t)) -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SPC no longer completes when minibuffer-completing-file-name is t
Satyaki Das [EMAIL PROTECTED] wrote: On 12/7/05, Bill Wohler [EMAIL PROTECTED] wrote: In the code below, if I comment out the setting of minibuffer-completing-file-name, the space again performs completion and I can't discern any difference in the completion. What is the effect of setting minibuffer-completing-file-name? Is it kosher? Do any of the MH-E developers know why we do this? I remember adding the binding of minibuffer-completing-file-name because it was needed for proper highlighting of the next character to enter in CVS Emacs. If that isn't needed anymore we can remove it. I'm glad you remembered! Now that you mention it, that variable does have an effect on the highlighting. If it's there the highlighting is correct (I can still complete with TAB, just not with SPC); if it isn't, the highlighting is one character to the right of where it should be. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: find-file sometimes doesn't
In the last week, sometimes maybe 1 in 20 times, C-x C-f (find-file) RET won't find the given file. However, the symptom is that if I'm editing buffer foo, and run find-file to open file bar, instead of getting two equally-sized windows containing foo and bar, I get two foo windows, one of which is only three lines high. If you delete the second window and try again, does it fail again? Coincidentally in the last week, I've noticed that when Emacs starts, instead of the splash screen taking up the entire frame, the last buffer edited (I use desktop) appears, with a small GNU Emacs window at the bottom saying to use C-l to start editing. The coincidence is that this small window is also three lines and is accompanied by the same light show as I mentioned above. Is this reproducible? If so, can you please debug it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
