Re: Cannot modify directory list GTK file dialog
On Tue, Dec 20 2005, Jan D. wrote: Stephen Berman wrote: [...] As a sanity check, I tried the same in Firefox, which uses the same GTK dialog, and it worked fine there. [...] I mainly use KDE and was doing so when I posted the bug report. I now tried it with Gnome, and there it worked fine, both for adding and removing directories. I also tried it with the other window managers I currently have installed -- windowmaker, blackbox, fvwm2, icewm, twm -- and it failed with all of these, just as with KDE. I think the window manager Gnome uses here is metacity. This is SUSE 10.0. [...] Suse has modified the GTK file chooser, and apparently they only mean for it to function under Gnome. I suggest you file a bug report to the Suse folks. Strange, why does modifying the directory list work for Stephen in Firefox then? FWIW, it works for me on SuSE 9.2 using fluxbox (no GNOME related processes running), both in Emacs and Firefox. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: kill-rectangle counts incorrectly
Am 20.12.2005 um 06:33 schrieb Richard M. Stallman: When I now go forward (right) by one char, the cursor in deed steps forward by two columns (because of the way the ASCII NUL is displayed) -- and the rectangle which is killed now, is two characters wide and not one! That's a bug -- in my opinion. That is not a bug. ^@ takes up two columns, and so the recntangle is two columns wide. It's only *presented* as a wide character ... Perhaps the presence of ^@ in a directory listing is a bug. Yes, there must be some reason for that -- and it only happens in GNU Emacsen, not in xterm or Terminal. -- Greetings Pete Either this man is dead or my watch has stopped. - Groucho Marx ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: normal-mode breaks VM recover-file
Why does Emacs think that Text mode is the right mode? Can you set it up to recognize automatically that VM mode is the right mode for these files? It was set to text-mode in normal-mode because of the default-major-mode (mine is set to text-mode). The VM mode was set when the command 'vm' is used to read a mail folder, which could be any file (with content in certain mail folder type). VM uses find-file-hook during recover-file and check if the buffer being recovered is a VM folder by checking the major mode. If it is not VM mode, VM skips. Should the major mode be preserved during recover-buffer? On Tuesday, December 20 2005, Richard M Stallman said: With latest CVS emasc I upgraded to last week, I found that VM would no longer be able to recover-file from an auto-saved copy properly. After further investigation, VM would not proceed with recovering because the major mode (VM mode) was reset to text-mode during the recovery in normal-mode (in files.el). I don't remember which bug this fixed, but I am sure it was a bug. Perhaps the bug was that if you delete the -*- line from a file and do M-x normal-mode, it would fail to switch to Fundamental mode. Why does Emacs think that Text mode is the right mode? Can you set it up to recognize automatically that VM mode is the right mode for these files? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
url-cookie-file noise
In the last few weeks, I've started to see the following message in the minibuffer at odd intervals: Cookies file /home/wohler/.url/cookies (see variable `url-cookie-file') is unwritable. I'm not using this package explicitly. Either it, or the package using it, should be ensuring that the url environment is set up correctly without user intervention. In this particular case, I assume that means creating ~/.url (which does not exist on my system). The last few entries in the url ChangeLog are as follows. Hmmm, timer sure sounds suspicious... 2005-12-07 Klaus Straubinger [EMAIL PROTECTED] (tiny change) * url-cookie.el (url-cookie-save-interval): Simplify. (url-cookie-setup-save-timer): Simplify. 2005-12-04 Klaus Straubinger [EMAIL PROTECTED] (tiny change) * url-history.el (url-history-list): Var deleted. (url-history-save-interval): Simplify. (url-history-setup-save-timer): Simplify. 2005-12-01 Kim F. Storm [EMAIL PROTECTED] * url-history.el (url-history-track): Fix last change. 2005-12-01 Klaus Straubinger [EMAIL PROTECTED] (tiny change) * url-history.el (url-history-track): Call url-history-setup-save-timer in :set function. :type allows three alternatives. (url-history-setup-save-timer): Test url-history-track. * url.el (url-retrieve): Test url-history-track. -- 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: url-cookie-file noise
Cookies file /home/wohler/.url/cookies (see variable `url-cookie-file') is unwritable. I'm not using this package explicitly. Either it, or the package using it, should be ensuring that the url environment is set up correctly without user intervention. In this particular case, I assume that means creating ~/.url (which does not exist on my system). Incidentally, ~/.url should probably be ~/.emacs.d/url instead. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: normal-mode breaks VM recover-file
On Mon, 19 Dec 2005, mjchan inbox wrote: With latest CVS emasc I upgraded to last week, I found that VM would no longer be able to recover-file from an auto-saved copy properly. After further investigation, VM would not proceed with recovering because the major mode (VM mode) was reset to text-mode during the recovery in normal-mode (in files.el). Do you have default-major-mode set to text-mode? I have a similar issue with recovering in vm but in my case (reported on the gnu.emacs.vm.bug list as news:[EMAIL PROTECTED]) I was seeing it set to fundamental-mode - which is my default-major-mode I found an entry in ChangeLog made by RMS on Aug. 9th that may be related: (normal-mode): Always set some major mode. I first spotted the issue in Sept 2005 which makes your diagnosis likely to be correct Robert -- La grenouille songe..dans son château d'eau ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
font-lock-fontify-buffer removes highlighting in non font-lock buffers
font-lock-fontify-buffer is an interactive command and when it is invoked as a buffer not intended for font-lock fontification, this breaks highlighting in all other non font-lock buffers. A simple way to reproduce: C-h i M-x font-lock-fontify-buffer RET and after this to see that highlighting is broken in all other buffers: M-x list-colors-display RET M-x list-faces-display RET ... That's because font-lock-default-fontify-buffer doesn't make the variable font-lock-keywords buffer-local, and its global value gets compiled to `(t nil)'. After creating new buffers, font-lock-default-function checks font-lock-keywords for nil, and since its global value is now `(t nil)', it calls font-lock-mode-internal which removes all highlighting from every non font-lock buffer. This bug was responsible for removing highlighting from Gnus buffers, and now it is avoided but not calling font-lock-fontify-buffer from hi-lock mode. But I think it should be fixed no matter if it called from hi-lock or not. I see at least three solutions: * check font-lock-keywords in font-lock-default-function for the compiled empty value `(t nil)' and don't call font-lock-mode-internal for this value; * make the variable font-lock-keywords automatically buffer-local; * in font-lock-default-fontify-buffer call font-lock-set-defaults regardless of the value of font-lock-mode, or depending on some other condition, e.g. if (local-variable-p 'font-lock-keywords). -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Cannot modify directory list GTK file dialog
Reiner Steib wrote: On Tue, Dec 20 2005, Jan D. wrote: Suse has modified the GTK file chooser, and apparently they only mean for it to function under Gnome. I suggest you file a bug report to the Suse folks. Strange, why does modifying the directory list work for Stephen in Firefox then? FWIW, it works for me on SuSE 9.2 using fluxbox (no GNOME related processes running), both in Emacs and Firefox. When compiling mozilla with gtk2, it links in a part og Gnome statically. I assume Firefox does the same, maybe that is the difference? You can specify different backends (unix, w32, etc.) for the GTK file chooser to use. Suse has such a backend (on my Suse at least). The error message must come from that backend, as no such message can be found in the GTK sources. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lazy-completion-table's args are evaluated too late
Looks like it works indeed, although it breaks my code because my code relies on lexical-let which doesn't work correctly when the lambdas are built at run time as is the case in your code. So maybe I'll be better off with the current code. Hmm I can install my fix, or I can leave it out, but I can't do both at once. The function as changed this way seems to be more capable and better, which seems to suggest I should install my fix. Can you fix your code to work with the function's new capability? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: normal-mode breaks VM recover-file
Should the major mode be preserved during recover-buffer? I don't think so. In principle, it should set the major mode according to what it finds when it reads the file. Please see if you can fix VM to DTRT. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lazy-completion-table's args are evaluated too late
Looks like it works indeed, although it breaks my code because my code relies on lexical-let which doesn't work correctly when the lambdas are built at run time as is the case in your code. So maybe I'll be better off with the current code. Hmm I can install my fix, or I can leave it out, but I can't do both at once. Too bad you're only a saint, eh? The function as changed this way seems to be more capable and better, which seems to suggest I should install my fix. Agreed. Can you fix your code to work with the function's new capability? That's what I'm about to try, Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(info (elisp)Other Display Specs)
In (info (elisp)Other Display Specs) the STRING display property is
listed twice:
`STRING'
Display STRING instead of the text that has this property.
[...]
`((margin nil) STRING)'
`STRING'
A display specification of this form means to display STRING
instead of the text that has the display specification, at the same
position as that text. This is a special case of marginal display
(*note Display Margins::).
Recursive display specifications are not supported--string display
specifications must not have `display' properties themselves.
Here's a patch that removes the first entry and moves the second one
to the top. It also reverses the order of the lines `((margin nil)
STRING)' and `STRING' so that `STRING' is less easy to miss
(presumably that's why it was added a second time).
--- display.texi21 Nov 2005 11:18:47 +0100 1.195
+++ display.texi21 Dec 2005 05:05:05 +0100
@@ -3275,7 +3275,14 @@
@table @code
@item @var{string}
-Display @var{string} instead of the text that has this property.
[EMAIL PROTECTED] ((margin nil) @var{string})
+A display specification of this form means to display @var{string}
+instead of the text that has the display specification, at the same
+position as that text. This is a special case of marginal display
+(@pxref{Display Margins}).
+
+Recursive display specifications are not supported---string display
+specifications must not have @code{display} properties themselves.
@item (image . @var{image-props})
This kind of display specification is an image descriptor (@pxref{Images}).
@@ -3291,16 +3298,6 @@
in the range 0.0--1.0 stands for that fraction of the width or height
of the entire image.
[EMAIL PROTECTED] ((margin nil) @var{string})
[EMAIL PROTECTED] @var{string}
-A display specification of this form means to display @var{string}
-instead of the text that has the display specification, at the same
-position as that text. This is a special case of marginal display
-(@pxref{Display Margins}).
-
-Recursive display specifications are not supported---string display
-specifications must not have @code{display} properties themselves.
-
@item (space-width @var{factor})
This display specification affects all the space characters within the
text that has the specification. It displays all of these spaces
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: url-cookie-file noise
Incidentally, ~/.url should probably be ~/.emacs.d/url instead. It should use the latter if .emacs.d exists and ~/.url does not exist. (That's the usual criterion.) Would you like to fix it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
lisp-complete-symbol is too loquacious in minibuffer
Hi, When I perform eval-expression in the minibuffer and complete some lisp symbol using the M-TAB key, the result is hidden by the message Making completion list...done for a while. That is annoying. It doesn't occur when I perform find-file, etc. Could it be modified as the following? Thanks in advance. --- lisp.el~2005-12-10 11:39:24 + +++ lisp.el 2005-12-21 06:08:50 + @@ -574,23 +574,27 @@ (delete-region beg end) (insert completion) (setq pattern completion)) - (message Making completion list...) - (let ((list (all-completions pattern obarray predicate))) -(setq list (sort list 'string)) -(or (eq predicate 'fboundp) -(let (new) - (while list -(setq new (cons (if (fboundp (intern (car list))) -(list (car list) f) - (car list)) -new)) -(setq list (cdr list))) - (setq list (nreverse new -(if ( (length list) 1) -(with-output-to-temp-buffer *Completions* - (display-completion-list list pattern)) - (delete-windows-on *Completions*))) - (message Making completion list...%s done))) + (let ((minibuf-is-in-use + (eq (minibuffer-window) (selected-window +(unless minibuf-is-in-use + (message Making completion list...)) +(let ((list (all-completions pattern obarray predicate))) + (setq list (sort list 'string)) + (or (eq predicate 'fboundp) + (let (new) +(while list + (setq new (cons (if (fboundp (intern (car list))) + (list (car list) f) +(car list)) + new)) + (setq list (cdr list))) +(setq list (nreverse new + (if ( (length list) 1) + (with-output-to-temp-buffer *Completions* +(display-completion-list list pattern)) +(delete-windows-on *Completions*))) +(unless minibuf-is-in-use + (message Making completion list...%s done) ;;; arch-tag: aa7fa8a4-2e6f-4e9b-9cd9-fef06340e67e ;;; lisp.el ends here ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
