Re: visiting certain .c file adds to kill ring
Kevin Ryde <[EMAIL PROTECTED]> writes: > With my recent cvs build or the debian snapshot, and starting from > "emacs -Q", visiting the file foo.c below with > > C-x C-f foo.c > > leaves the first line in the kill ring, > > C-y > => inserts "/* hello */ > > where I hoped it would leave the kill ring alone. (In particular it's > not good to have the kill changed when you're doing a cut and paste > from another file into that one.) > > I suspect c-remove-any-local-eval-or-mode-variables in cc-mode.el > shouldn't be using kill-line, but cc-mode is hellishly complicated ... I can't reproduce this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > What I did test was that reverting the changes in revisions 1.38 and > 1.40 (the one from today) and then applying the patch below, not only > solves the three bugs reported today, but also solves the three > problems described in the above paragraph. The first two, I checked. > The third one I could not actually check, because I do not use eshell, > but it _should_ be fixed, as my patch eliminates dependence from these > history lists. I verified that this works. The patch looks good, so I checked it in. Thanks! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
>From my previous message: What I did test was that reverting the changes in revisions 1.38 and 1.40 (the one from today) Meant was: 1.41 (the one from today) All references to 1.40 in my replies actuaaly referred to 1.41 Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
As a complement to my previous message, here is a diff showing _all_
changes since 1.37 _after_ applying the two reversions and my patch,
to show that all revisions in between are unrelated:
===File ~/locate-diff-1=
*** locate.el 20 Apr 2007 18:51:04 -0500 1.37
--- locate.el 20 Apr 2007 20:10:42 -0500
***
*** 1,7
;;; locate.el --- interface to the locate command
;; Copyright (C) 1996, 1998, 2001, 2002, 2003, 2004,
! ;; 2005, 2006 Free Software Foundation, Inc.
;; Author: Peter Breton <[EMAIL PROTECTED]>
;; Keywords: unix files
--- 1,7
;;; locate.el --- interface to the locate command
;; Copyright (C) 1996, 1998, 2001, 2002, 2003, 2004,
! ;; 2005, 2006, 2007 Free Software Foundation, Inc.
;; Author: Peter Breton <[EMAIL PROTECTED]>
;; Keywords: unix files
***
*** 115,120
--- 115,122
;; Variables
(defvar locate-current-filter nil)
+ (defvar locate-local-filter nil)
+ (defvar locate-local-search nil)
(defgroup locate nil
"Interface to the locate command."
***
*** 300,305
--- 302,309
(erase-buffer)
(setq locate-current-filter filter)
+ (set (make-local-variable 'locate-local-search) search-string)
+ (set (make-local-variable 'locate-local-filter) filter)
(if run-locate-command
(shell-command search-string locate-buffer-name)
***
*** 422,428
(save-excursion
(forward-line 0)
(looking-at (concat "."
! (make-string (1- locate-filename-indentation) ?\ )
"\\(/\\|[A-Za-z]:\\)"
(defun locate-mouse-view-file (event)
--- 426,432
(save-excursion
(forward-line 0)
(looking-at (concat "."
! (make-string (1- locate-filename-indentation) ?\s)
"\\(/\\|[A-Za-z]:\\)"
(defun locate-mouse-view-file (event)
***
*** 469,475
;; This should support both Unix and Windoze style names
(setq directory-listing-before-filename-regexp
(concat "^."
! (make-string (1- locate-filename-indentation) ?\ )
"\\(/\\|[A-Za-z]:\\)\\|"
(default-value 'directory-listing-before-filename-regexp)))
(make-local-variable 'dired-actual-switches)
--- 473,479
;; This should support both Unix and Windoze style names
(setq directory-listing-before-filename-regexp
(concat "^."
! (make-string (1- locate-filename-indentation) ?\s)
"\\(/\\|[A-Za-z]:\\)\\|"
(default-value 'directory-listing-before-filename-regexp)))
(make-local-variable 'dired-actual-switches)
***
*** 477,483
(make-local-variable 'dired-permission-flags-regexp)
(setq dired-permission-flags-regexp
(concat "^.\\("
! (make-string (1- locate-filename-indentation) ?\ )
"\\)\\|"
(default-value 'dired-permission-flags-regexp)))
(make-local-variable 'revert-buffer-function)
--- 481,487
(make-local-variable 'dired-permission-flags-regexp)
(setq dired-permission-flags-regexp
(concat "^.\\("
! (make-string (1- locate-filename-indentation) ?\s)
"\\)\\|"
(default-value 'dired-permission-flags-regexp)))
(make-local-variable 'revert-buffer-function)
***
*** 501,507
(locate-insert-header search-string)
(while (not (eobp))
! (insert-char ?\ locate-filename-indentation t)
(locate-set-properties)
(forward-line 1)))
(goto-char (point-min)))
--- 505,511
(locate-insert-header search-string)
(while (not (eobp))
! (insert-char ?\s locate-filename-indentation t)
(locate-set-properties)
(forward-line 1)))
(goto-char (point-min)))
***
*** 580,586
"Revert the *Locate* buffer.
If `locate-update-when-revert' is non-nil, offer to update the
locate database using the shell command in `locate-update-command'."
! (let ((str (car locate-history-list)))
(and locate-update-when-revert
(yes-or-no-p "Update locate database (may take a few seconds)? ")
;; `expand-file-name' is used in order to autoload Tramp if
--- 584,590
"Revert the *Locate* buffer.
If `locate-update-when-revert' is non-nil, offer to update the
locate database using the shell command in `locate-update-command'."
! (let ((locate-buffer-name (buffer-name)))
(and locate-update-when-revert
(yes-or-no-p "Update locate database (may take a few seconds)? ")
;; `expand-file-name' is used in order to autoload Tramp if
***
*** 588,594
;; is remote.
(let ((default-directory (expand-file-name locate-update-path)))
(shell-command locate-update-command)))
! (locate st
Re: patch for locate.el when called with prefix arg
After studying the patch that introduced this, it seems to me that the one line (buffer-disable-undo) in locate.el:472 was sneaked in without further justification. As was other stuff that causes bugs too. Luc, could you test if removing this line solves your problem? Also, could you see if the original problem addressed by this patch, i.e. It solves one of the two bugs I reported but not the other. It leaves very strange looking code in locate.el, which I suspect to have other problems than the ones we yet know about. Also, could you see if the original problem addressed by this patch, i.e. Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. remains solved after removing that line? What I did test was that reverting the changes in revisions 1.38 and 1.40 (the one from today) and then applying the patch below, not only solves the three bugs reported today, but also solves the three problems described in the above paragraph. The first two, I checked. The third one I could not actually check, because I do not use eshell, but it _should_ be fixed, as my patch eliminates dependence from these history lists. Note that my patch below only changes six lines (4 trivial and 2 very simple) compared to 1.37, whereas 1.38 changes 40 lines in a complex way. All problems which 1.38 tried to solve concerned only the function locate-update. My patch affects only that function. Rev 1.38 affected all of locate, causing various bugs. Patch to be applied _after_ reverting revisions 1.37 and 1.40: ===File ~/locate-diff-2= *** locate.el 20 Apr 2007 18:51:04 -0500 1.37 --- locate.el 20 Apr 2007 20:37:21 -0500 *** *** 115,120 --- 115,122 ;; Variables (defvar locate-current-filter nil) + (defvar locate-local-filter nil) + (defvar locate-local-search nil) (defgroup locate nil "Interface to the locate command." *** *** 300,305 --- 302,309 (erase-buffer) (setq locate-current-filter filter) + (set (make-local-variable 'locate-local-search) search-string) + (set (make-local-variable 'locate-local-filter) filter) (if run-locate-command (shell-command search-string locate-buffer-name) *** *** 580,586 "Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'." ! (let ((str (car locate-history-list))) (and locate-update-when-revert (yes-or-no-p "Update locate database (may take a few seconds)? ") ;; `expand-file-name' is used in order to autoload Tramp if --- 584,590 "Revert the *Locate* buffer. If `locate-update-when-revert' is non-nil, offer to update the locate database using the shell command in `locate-update-command'." ! (let ((locate-buffer-name (buffer-name))) (and locate-update-when-revert (yes-or-no-p "Update locate database (may take a few seconds)? ") ;; `expand-file-name' is used in order to autoload Tramp if *** *** 588,594 ;; is remote. (let ((default-directory (expand-file-name locate-update-path))) (shell-command locate-update-command))) ! (locate str))) ;;; Modified three functions from `dired.el': ;;; dired-find-directory, --- 592,598 ;; is remote. (let ((default-directory (expand-file-name locate-update-path))) (shell-command locate-update-command))) ! (locate locate-local-search locate-local-filter))) ;;; Modified three functions from `dired.el': ;;; dired-find-directory, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> I suggest not changing this until we have time to discuss this, > i.e. after the release. It would not be good to introduce a security > risk into Emacs at the 11th hour. Obviously. I didn't even byte-compile the code (let alone run it). Stefan ___ 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
visiting certain .c file adds to kill ring
With my recent cvs build or the debian snapshot, and starting from
"emacs -Q", visiting the file foo.c below with
C-x C-f foo.c
leaves the first line in the kill ring,
C-y
=> inserts "/* hello */
where I hoped it would leave the kill ring alone. (In particular it's
not good to have the kill changed when you're doing a cut and paste
from another file into that one.)
I suspect c-remove-any-local-eval-or-mode-variables in cc-mode.el
shouldn't be using kill-line, but cc-mode is hellishly complicated ...
In GNU Emacs 22.0.98.2 (i586-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-04-18 on blah
configured using `configure 'CFLAGS=-O' '--prefix=/down/emacs/b/inst'
'--with-x-toolkit=gtk''
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: en_AU
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: C/l
Minor modes in effect:
encoded-kbd-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
abbrev-mode: t
/* hello */
int
main ()
{
return 0;
}
/*
Local Variables:
c-file-style: "gnu"
End:
*/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
python.el
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? Apart from the legal issues it's bizarre the way you reject so many improvements and then either put them in two or three years later or have others reimplement them or something very similar. Apart from wasting the original effort, it can't encourage people you do still approve of to contribute if they see that happening. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tumme fails with default custom settings
Mathias Dahl <[EMAIL PROTECTED]> writes: Hi Matthias, > Could someone else test as well? Here, the thumbs are displayed properly, and RET opens a *tumme-display-image* buffer with a scaled image. (The original icon is 64x64, and the buffer shows about a 350x350 version) When I type `f' a small, empty square is displayed -- not the image. `s' gets me back to the scaled image. However, the fix of Stephen doesn't help here. I removed the +profile "*" option and set the changes for the current session, killed the *tumme-display-image* buffer and typed RET on a thumb to open a new image buffer. Still the image transforms to an empty box with `f'. Bye, Tassilo -- The easiest way to determine Chuck Norris' age is to cut him in half and count the rings. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Please install your patch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Undo no longer works in a locate buffer. This is a serious bug and a > regression in Emacs 22 if it does not get fixed. You are supposed to > be able to do essentially everything you can do in a dired buffer > (including undo) in a locate buffer. That is the very purpose of > locate-mode. After studying the patch that introduced this, it seems to me that the one line (buffer-disable-undo) in locate.el:472 was sneaked in without further justification. Luc, could you test if removing this line solves your problem? Also, could you see if the original problem addressed by this patch, i.e. Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. remains solved after removing that line? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Stefan Monnier <[EMAIL PROTECTED]> writes: >>> Now, when desktop.el loads it, it asks if I want to apply the >>> font-lock-keywords customisation, because it is risky (is it?). > >> Font-lock can modify arbitrary text properties, such as display >> strings, and not just faces. > > And it can also directly run any code, which is even more immediately scary. > We should probably write a font-lock-keywords-safe-p. Something like the > one below, maybe. > > +(put 'font-lock-keywords 'safe-local-variable 'font-lock-keywords-safe-p) I suggest not changing this until we have time to discuss this, i.e. after the release. It would not be good to introduce a security risk into Emacs at the 11th hour. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
>> Now, when desktop.el loads it, it asks if I want to apply the >> font-lock-keywords customisation, because it is risky (is it?). > Font-lock can modify arbitrary text properties, such as display > strings, and not just faces. And it can also directly run any code, which is even more immediately scary. We should probably write a font-lock-keywords-safe-p. Something like the one below, maybe. Stefan --- orig/lisp/font-lock.el +++ mod/lisp/font-lock.el @@ -454,6 +454,23 @@ user-level keywords, but normally their values have been optimized.") +(defun font-lock-keywords-safe-p (val) + (catch 'unsafe +(while (consp val) + (let ((kw (pop val))) +(unless (stringp (pop kw)) (throw 'unsafe nil)) +(while (consp kw) + (let ((hl (pop kw))) +(unless (natnump (pop hl)) (throw 'unsafe nil)) +(unless (or (symbolp (car hl)) +(and (eq 'quote (safe-car (car hl))) + (symbolp (safe-car (cdar hl) + (throw 'unsafe nil +(when kw (throw 'unsafe nil +(when val (throw 'unsafe nil)) +t)) +(put 'font-lock-keywords 'safe-local-variable 'font-lock-keywords-safe-p) + (defvar font-lock-keywords-alist nil "Alist of additional `font-lock-keywords' elements for major modes. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
>From my previous message: Undo no longer works in a locate buffer. This is a serious bug and a regression in Emacs 22 if it does not get fixed. To explain the seriousness: I often perform "work" in locate buffers. For instance, I often "clean up" the buffer by manually marking and killing search results that were irrelevant. If I kill a line by mistake (which happens, I am absent-minded), it is important to be able to get that line back by undo. Getting it back by a new search looses all my previous work. Actually, to me `undo' is _more_ important in locate buffers than in regular Dired buffers. This also shows why the second bug is serious too: after the overwrite, I can conduct the original search over again, but I loose all my work in the process. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: filling long html href
> Would you please install your patch? Done, Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Francesco Potorti` <[EMAIL PROTECTED]> wrote: > >A bug was apparently introduced in locate.el, but I did not check when >and why. > > That was not the only bug introduced by the following change: > > 2006-09-09 Matt Hodges <[EMAIL PROTECTED]> > > * locate.el (locate-current-search): New variable. > (locate): Set buffer local value. Use current buffer if it is > in Locate mode. > (locate-mode): Disable undo here. > (locate-do-setup): Use locate-current-filter from buffer to be killed. > (locate-update): Use locate-current-search and locate-current-filter. > > Undo no longer works in a locate buffer. This is a serious bug and a > regression in Emacs 22 if it does not get fixed. You are supposed to > be able to do essentially everything you can do in a dired buffer > (including undo) in a locate buffer. That is the very purpose of > locate-mode. > > From the above changelog entry, this bug seems to have been introduced > _on purpose_. What was the purpose of the above changes? They seem to > have been made by somebody who does not understand how other people > use locate mode and only cares about the way he personally uses it. > Who knows what else these changes broke. FWIW, the only discussion of this I could find is here: http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-09/msg00068.html From: Matt Hodges Subject: Reverting locate buffers. Date: Tue, 05 Sep 2006 14:08:37 +0100 Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. The attached patch has suggested changes to address these issues. If suitable, a ChangeLog entry is: 2006-09-05 Matt Hodges <[EMAIL PROTECTED]> * locate.el (locate-current-search): New variable. (locate): Set buffer local value. Use current buffer if it is in Locate mode. (locate-mode): Disable undo here. (locate-do-setup): Use locate-current-filter from buffer to be killed. (locate-update): Use locate-current-search and locate-current-filter. Thanks, Matt ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
non-bug with 22.0.98
I was about to report a bug with 22.0.96, but I decided to install
22.0.98 first, and much to my pleasure, the bug is not present in
22.0.98. However, the problem seems like maybe it could have been
fixed by accident since I couldn't find any mention of it in the
ChangeLog.
Using boost::function's template syntax of boost::function, 22.0.96 fails to indent properly in some cases. In the
following example, which compiles correctly, the commented line
indents properly with 22.0.98 but not with 22.0.96. If this was
recently fixed, great. If not, well, it works in 22.0.98, and it
might be worth adding it to any kind of test suite that there may be
for this. :-)
I hope I haven't overstepped by ccing [EMAIL PROTECTED], but that's the name
on most of the cc-engine ChangeLog entries.
#include
class A
{
public:
void f1(boost::function);
// <-- this line indents correctly with 22.0.98 but not with 22.0.96.
};
--
Jay Berkenbilt <[EMAIL PROTECTED]>
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
redisplay
;;; This ...
(progn (new-frame)
(redisplay t)
(x-popup-dialog t '("Foo" ("Bar" . 1
;;; ... produces a blank frame while the popup dialog is active,
;;; i.e., (redisplay t) fails to wait for redisplay to finish.
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: nil
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
encoded-kbd-mode: t
hi-lock-mode: t
display-time-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
mouse-wheel-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
auto-compression-mode: t
temp-buffer-resize-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
m a c s SPC l i s p SPC m SPC
C-p C-p C-M-k M-( p r o g n SPC M-(
n e w - f r a m e M-) M-( r e d i s
SPC t M-) M-( x - p o d
SPC t SPC ' M-( M-" F O o M-- M-c C-f SPC M-( M-" B
a r C-f SPC . SPC 1 C-n C-x C-e C-M-h
M-w M-x r e p o r t SPC e m SPC SPC
Recent messages:
Fill column set to 56 (was 70)
Mark set
Undo...
Undo!
Mark set [2 times]
Auto save file for draft message exists; consider M-x mail-recover
Mark set [3 times]
Auto-saving...done
1
Mark set [2 times]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
>From my previous message: I believe that _instead_ of applying your patch, the apparently misguided 2006-09-09 changes should be completely reverted (before releasing Emacs 22), getting rid of all three _regressive_ bugs we know about, as well as of those we do not know about yet that were introduced by that change. I know see that these changes were made to address the following problems: Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. These problems can, and should, obviously be addressed in locate-update, without affecting other stuff. Anyway, the problems described above are not regressions and could be fixed properly after the release (or before, but that would imply a delay), whereas the problems introduced by their "fix" are regressions, at least two of which are currently not fixed. (And looking at the code, I strongly suspect that these two bugs are not the only ones.) Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
read-number: Ask again if error reading input
emacs -Q M-: (read-number ":" 5) Type "(foo" End of file during parsing Minor patch to `read-number': (cond ((zerop (length str)) default) ((stringp str) (read str))) (unless (numberp n)... Should be: (cond ((zerop (length str)) default) ((stringp str) (condition-case nil (read str) (error nil (unless (numberp n)... That way, if the user inputs something that causes a read error, s?he is just asked again, instead of getting an error message that s?he might not understand. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
And here is yet another regressive bug introduced by that change: I do `M-x locate RET autorevert', then `M-x rename-uniquely' to start conducting a second locate search (the routine recommended way to start a new search while keeping the results of the previous one) and then do `M-x locate RET ielm'. My autorevert results now get overwritten. in spite of the `M-x rename-uniquely'. This is yet another regressive bug. I believe that _instead_ of applying your patch, the apparently misguided 2006-09-09 changes should be completely reverted (before releasing Emacs 22), getting rid of all three _regressive_ bugs we know about, as well as of those we do not know about yet that were introduced by that change. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Francesco Potorti` <[EMAIL PROTECTED]> wrote: A bug was apparently introduced in locate.el, but I did not check when and why. That was not the only bug introduced by the following change: 2006-09-09 Matt Hodges <[EMAIL PROTECTED]> * locate.el (locate-current-search): New variable. (locate): Set buffer local value. Use current buffer if it is in Locate mode. (locate-mode): Disable undo here. (locate-do-setup): Use locate-current-filter from buffer to be killed. (locate-update): Use locate-current-search and locate-current-filter. Undo no longer works in a locate buffer. This is a serious bug and a regression in Emacs 22 if it does not get fixed. You are supposed to be able to do essentially everything you can do in a dired buffer (including undo) in a locate buffer. That is the very purpose of locate-mode. >From the above changelog entry, this bug seems to have been introduced _on purpose_. What was the purpose of the above changes? They seem to have been made by somebody who does not understand how other people use locate mode and only cares about the way he personally uses it. Who knows what else these changes broke. Sincerely, Luc Teirlinck. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No doc string for `read-number'
`read-number' should have a doc string. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tumme fails with default custom settings
Stephen Berman <[EMAIL PROTECTED]> writes: > Yesterday I tried tumme again for the first time since last August > and encountered problems I don't recall having before. I found a > very easy fix, by changing the default custom settings of two > variables, but these defaults have been around a long time, so I > wonder if there's something about my system that's causing the > problems (I'm running openSUSE 10.2, last August it was SUSE 10.0). > But in case this is an Emacs bug, here's a detailed recipe for > reproducing the problems (which is reliable on my system). And a very detailed recipe it is, thanks! > The convert(1) man page is just a stub and makes no mention of the > +profile flag, and I haven't had time to delve into the online doc. I > don't know what I'm missing by not using +profile, but it makes tumme > work for me. So is this a bug in tumme or Emacs or convert? As a > test I ran convert twice from the shell on an image file using the > default tumme options: Using the -profile or +profile options you add or remove certain "profiles" to the image. You can read more here: http://www.imagemagick.org/script/command-line-options.php#profile Tumme will probably work just perfect without the +profile option but I think the thumbnail files might be larger, if the original contained these profiles. Why the use of this makes things fail on your system, I don't know. I just followed your recipe (in a terminal, so I could not see any images, but I got no errors and the thumbnail files was created without any problem. I will test more later.) in a new CVS Emacs. Could someone else test as well? > This is my convert version: > > Version: ImageMagick 6.3.0 02/08/07 Q16 http://www.imagemagick.org > Copyright: Copyright (C) 1999-2006 ImageMagick Studio LLC Mine is: Version: ImageMagick 6.2.9 08/30/06 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2006 ImageMagick Studio LLC /Mathias ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: filling long html href
Would you please install your patch? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Francesco Potorti` <[EMAIL PROTECTED]> writes: >> > I answer y, but I get the message: Toggling font-lock-mode off; >> > better pass an explicit argument. >> >>This is done in `hack-one-local-variable' where >> >> (funcall mode) >> >>simply executes `font-lock-mode' which toggles font-lock mode off since >>it does not get an argument. > > Why does it do that? Shouldn't it simply set font-lock-keywords to the > value I specified? This is what happened in Emacs 21, as far as I can > tell. Not because of font-lock-keywords, but because of this line: # mode: font-lock Note that font-lock-mode is now turned on by default. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Francesco Potorti` <[EMAIL PROTECTED]> writes: > Now, when desktop.el loads it, it asks if I want to apply the > font-lock-keywords customisation, because it is risky (is it?). Font-lock can modify arbitrary text properties, such as display strings, and not just faces. So one can imagine a trojan horse that works through font-lock (probably not practical, but not obviously impossible either). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Francesco Potorti` <[EMAIL PROTECTED]> writes: > Calling C-u M-x locate RET gives no results, whatever the command line. > > A bug was apparently introduced in locate.el, but I did not check when > and why. I found the problem in 22.0.96, but, by looking at the source, > it is still there in 22.0.98. > > Here is a patch and Changelog entry: Thanks. I've checked the patch in. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Tumme fails with default custom settings
Yesterday I tried tumme again for the first time since last August and encountered problems I don't recall having before. I found a very easy fix, by changing the default custom settings of two variables, but these defaults have been around a long time, so I wonder if there's something about my system that's causing the problems (I'm running openSUSE 10.2, last August it was SUSE 10.0). But in case this is an Emacs bug, here's a detailed recipe for reproducing the problems (which is reliable on my system). 1. Make sure that ~/.emacs.d/tumme/ is empty or does not exist. 2. emacs -Q 3. M-x tumme RET RET 4. Now the window is vertically split: in the upper window a dired buffer of , in the lower window a *tumme* buffer contains as many 32x32 squares as there are picture files in . The squares are empty. *Messages* contains the following: (/users/steve/cvsroot/emacs/src/emacs -Q) For information about the GNU Project and its goals, type C-h C-p. Loading tumme... Loading regexp-opt...done Loading tumme...done Loading image-file...done Marking matching files... 7 matching files marked. tumme-thumbnail-mode enabled (New file) [14 times] Cannot find image file `/home/steve/.emacs.d/tumme/rimg0008_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0009_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0018_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0024_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0031_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0038_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0047_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0008_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0009_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0018_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0024_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0031_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0038_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0047_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0008_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0009_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0018_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0024_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0031_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0038_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0047_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0008_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0009_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0018_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0024_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0031_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0038_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' Cannot find image file `/home/steve/.emacs.d/tumme/rimg0047_6b04c414f112b054d20d63fb83d2cf4b.thumb.jpg' All of these files exist. 5. Clicking with mouse-2 or pressing RET on one of the squares in the *tumme* buffer pops open a *tumme-display-image* buffer containing a single 32x32 empty square. If I type `s' (tumme-display-current-image-sized) with the cursor on this square, the echo area reports "Full size image displayed" but all I see is the same empty square; *Messages* now also has "Cannot find image file `~/.emacs.d/tumme/.tumme_temp'" and in fact this file does not exist. 6. If I type `f' (tumme-display-current-image-full) with the cursor on this square, again the echo area reports "Full size image displayed" and now the buffer does indeed display the full-sized image; moreover, ~/.emacs.d/tumme/.tumme_temp now exists. However, now typing `s' again still does nothing. Now, here's the fix I found for these problems. Do `M-x customize-group RET tumme RET', then change the value o
patch for locate.el when called with prefix arg
Calling C-u M-x locate RET gives no results, whatever the command line. A bug was apparently introduced in locate.el, but I did not check when and why. I found the problem in 22.0.96, but, by looking at the source, it is still there in 22.0.98. Here is a patch and Changelog entry: 2007-04-20 Francesco Potort=8ec <[EMAIL PROTECTED]> * locate.el (locate): Output from shell-command should go in the current buffer rather than *Shell Command Output*. --- /home/pot/gnu/emacs-22.0.96/lisp/locate.el~ 2007-01-21 04:53:11.0 +0100 +++ /home/pot/gnu/emacs-22.0.96/lisp/locate.el 2007-04-20 13:40:35.0 +0200 @@ -310,7 +310,7 @@ the docstring of that function for its m (set (make-local-variable 'locate-current-filter) filter) (if run-locate-command -(shell-command search-string) +(shell-command search-string (current-buffer)) (apply 'call-process locate-cmd nil t nil locate-cmd-args)) (and filter Diff finished. Fri Apr 20 13:40:55 2007 In GNU Emacs 22.0.96.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.8.20) of 2007-04-02 on tucano.isti.cnr.it configured using `configure '--with-gtk'' Important settings: value of $LC_ALL: C value of $LC_COLLATE: [EMAIL PROTECTED] value of $LC_CTYPE: [EMAIL PROTECTED] value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: C value of $LC_TIME: nil value of $LANG: nil locale-coding-system: nil default-enable-multibyte-characters: t Major mode: Diff Minor modes in effect: display-time-mode: t shell-dirtrack-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t Recent input: x ESC O A RET - i SPC e i f f e l RET c C-x b * S h e TAB RET C-c C-g C-x k RET ESC O B C-h f RET ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C C-h f RET ESC O A ESC O A ESC O A C-a C-k ESC O B ESC O B C-e ESC O D SPC ( c u r r e n t - b u f f e r ) ESC O D ESC O D C-h f C-g C-h v C-g C-h f RET ESC O A ESC O A ESC C-x C-u ESC x l o c a t e RET - i SPC E I F F E L RET RET n C-x k RET q C-x 0 C-x C-s ESC x b y t e SPC c o m RET RET C-x C-j ESC O B ESC O B C-@ ESC O A ESC O A = RET C-x k RET C-x C-v ESC O D ESC O D ESC O D ESC O D ESC O D ESC O D DEL 8 RET ESC x r e v e r t RET y e s RET C-s s h e l l - c o m m RET C-x k RET C-x k RET C-x o C-x h ESC w ESC x r e p o TAB ESC DEL C-g C-h a p r e t e s t RET C-x 4 m C-u ESC x r m a RET M a i SPC DEL TAB C-g C-x o ESC x r e p o r t SPC e m a c s SPC b u SPC RET Recent messages: Compiling /home/pot/gnu/emacs-22.0.96/lisp/locate.el...done Wrote /home/pot/gnu/emacs-22.0.96/lisp/locate.elc Mark set Loading diff-mode...done Use M-x make-directory RET RET to create the directory and its parents Mark saved where search started Mark set [2 times] Making completion list... Quit No apropos matches for `pretest' Quit ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> > # font-lock-keywords : ("^\\s-*:0" "##+")
> > # End:
> >
> > Now, when desktop.el loads it, it asks if I want to apply the
> > font-lock-keywords customisation, because it is risky (is it?).
>
>The question is asked by `hack-local-variables-confirm'.
Fine.
> > I
> > answer y, but I get the message:
> > Toggling font-lock-mode off; better pass an explicit argument.
>
>This is done in `hack-one-local-variable' where
>
>(funcall mode)
>
>simply executes `font-lock-mode' which toggles font-lock mode off since
>it does not get an argument.
Why does it do that? Shouldn't it simply set font-lock-keywords to the
value I specified? This is what happened in Emacs 21, as far as I can
tell.
> > I then again do M-x font-lock-mode RET, and it says
> > Font-Lock mode enabled
> > but I still see no colours.
>
>Look at the value of `font-lock-keywords' in this buffer - it's probably
>(t nil).
Yes, it is.
>You should modify this either by setting `font-lock-defaults'
>or via `font-lock-add-keywords' or `font-lock-remove-keywords'.
So, what is now the recommended way to set file-specific font-lock
keywords using file-local variables? If this has changed, it should be
specified in the NEWS. I can write an entry once I understand the
answer to my questions above.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> # Local Variables:
> # mode: indented-text
> # fill-column: 95
> # mode: font-lock
> # font-lock-keywords : ("^\\s-*:0" "##+")
> # End:
>
> Now, when desktop.el loads it, it asks if I want to apply the
> font-lock-keywords customisation, because it is risky (is it?).
The question is asked by `hack-local-variables-confirm'.
> I
> answer y, but I get the message:
> Toggling font-lock-mode off; better pass an explicit argument.
This is done in `hack-one-local-variable' where
(funcall mode)
simply executes `font-lock-mode' which toggles font-lock mode off since
it does not get an argument.
> and font lock is apparently inactive, as I see no colours. If I toggle
> it, it says
> Font-Lock mode disabled
> I then again do M-x font-lock-mode RET, and it says
> Font-Lock mode enabled
> but I still see no colours.
Look at the value of `font-lock-keywords' in this buffer - it's probably
(t nil). You should modify this either by setting `font-lock-defaults'
or via `font-lock-add-keywords' or `font-lock-remove-keywords'.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
