Re: flyspell.el: down-mouse-2 leads to unwanted text insertion
Ralf Angeli [EMAIL PROTECTED] writes: The symptoms are the following: When pressing mouse-2 on a misspelled word, the flyspell menu will appear as soon as mouse-2 is released and will stay opened. I can close it again by clicking with mouse-1 somewhere in the buffer. As soon as this happens, text will get yanked at the point of the original mouse-2 click. This behavior only happens if clicking and releasing the mouse button is done fast. Does it happen if you set mouse-1-click-follow-link to nil ? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ido-mode and customized read-buffer-function
Roland Winkler [EMAIL PROTECTED] writes: On Sun Apr 24 2005 Kim F. Storm wrote: Roland Winkler [EMAIL PROTECTED] writes: Does this patch give good results ? Thanks a lot for the quick reply. I think there is a minor bug (see below). You are right. Thanks. I installed the change. I thought I tested all possibilities. But maybe I didn't. Does this patch give better results? *** ido.el 24 Apr 2005 21:06:21 +0200 1.52 --- ido.el 27 Apr 2005 10:34:42 +0200 *** *** 1347,1365 ( (prefix-numeric-value arg) 0) (not ido-everywhere))) (when (get 'ido-everywhere 'file) ! (setq read-file-name-function (get 'ido-everywhere 'file)) (put 'ido-everywhere 'file nil)) (when (get 'ido-everywhere 'buffer) ! (setq read-buffer-function (get 'ido-everywhere 'buffer)) (put 'ido-everywhere 'buffer nil)) (when ido-everywhere (when (memq ido-mode '(both file)) ! (unless (get 'ido-everywhere 'file) ! (put 'ido-everywhere 'file read-file-name-function)) (setq read-file-name-function 'ido-read-file-name)) (when (memq ido-mode '(both buffer)) ! (unless (get 'ido-everywhere 'buffer) ! (put 'ido-everywhere 'buffer read-buffer-function)) (setq read-buffer-function 'ido-read-buffer --- 1347,1363 ( (prefix-numeric-value arg) 0) (not ido-everywhere))) (when (get 'ido-everywhere 'file) ! (setq read-file-name-function (car (get 'ido-everywhere 'file))) (put 'ido-everywhere 'file nil)) (when (get 'ido-everywhere 'buffer) ! (setq read-buffer-function (car (get 'ido-everywhere 'buffer))) (put 'ido-everywhere 'buffer nil)) (when ido-everywhere (when (memq ido-mode '(both file)) ! (put 'ido-everywhere 'file (cons read-file-name-function nil)) (setq read-file-name-function 'ido-read-file-name)) (when (memq ido-mode '(both buffer)) ! (put 'ido-everywhere 'buffer (cons read-buffer-function nil)) (setq read-buffer-function 'ido-read-buffer -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell.el: down-mouse-2 leads to unwanted text insertion
* Kim F. Storm (2005-04-27) writes: Ralf Angeli [EMAIL PROTECTED] writes: The symptoms are the following: When pressing mouse-2 on a misspelled word, the flyspell menu will appear as soon as mouse-2 is released and will stay opened. I can close it again by clicking with mouse-1 somewhere in the buffer. As soon as this happens, text will get yanked at the point of the original mouse-2 click. This behavior only happens if clicking and releasing the mouse button is done fast. Does it happen if you set mouse-1-click-follow-link to nil ? Yes. Also, increasing the value in `mouse-1-click-follows-link' does not have any effect on the time it takes for the menu to show up when I keep the mouse button pressed. So this seems to be unrelated. Could this be an interaction problem with GTK? I noticed that e.g. in The Gimp a fast click/release with mouse-3 opens a context menu which stays after releasing the mouse button. But if you keep the mouse button pressed for some time, releasing it will make the menu disappear. BTW, it would be nice if e.g. the font selection menu one gets with S-down-mouse-1 would behave this way as well. Currently it will get closed as soon as the mouse button is released no matter how fast you click/release. -- Ralf ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: X11 resource to turn on visible-bell
I find the bell sound very annoying, adding (setq visible-bell t) to .emacs gets rid of it nicely. But that does not work when running emacs -q. It would be nice to have an X11 resource to use visible-bell. Xterm has a resource called visualBell, Emacs could use the same name. Would something like this be a good addition to Emacs? I don't know how visible bell is implemented, but I suspect it has an effect on redisplay, so you should not turn it on if emacs-basic-display (-D) is t. Jan D. *** startup.el 23 Apr 2005 20:40:35 -0700 1.355 --- startup.el 26 Apr 2005 13:48:20 -0700 *** *** 727,732 --- 727,738 '(off false) (setq no-blinking-cursor t)) + (when (and (not noninteractive) +(memq window-system '(x w32 mac)) +(member (x-get-resource visualBell VisualBell) + '(on true))) + (setq visible-bell t)) + ;; If frame was created with a menu bar, set menu-bar-mode on. (unless (or noninteractive emacs-basic-display ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
As I said, I agree with the general idea that save-window-excursion shouldn't affect point, but I indeed think it's more important that it shouldn't cause any window's cursor to move. Copying the value of one window's point to another window's point is (to me) always a bug. So, yes, I really think it should be changed. I doubt it's risky, but there's no hurry, so we can keep it for post-22. I am sure it is risky. There is, or was, code that depended on the precise details of this behavior. Perhaps none will break with the specific change that you have in mind. Or perhaps yes some will break. We don't know--so it is risky. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: X11 resource to turn on visible-bell
I don't think this is worth the effort to documentn it. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
cperl-mode Parsing Bug
Symptoms:
cperl-mode 5.0-Emacs does not properly parse POD, regular expressions,
or q* operators. When I start emacs -Q and enable font-lock-mode and
load the following program under cperl-mode, the regular expression is
not properly parsed and highlighted (if I were to insert a ' into it,
it would think that the rest of the script was a string!). The POD is
not recognized as separate from the program, and the qq{} operator in
the last line is not marked as a string.
#!/usr/bin/perl -w
use strict;
my $foo = shift;
print Yep\n if $foo =~ /what/;
=pod
This is a test
=cut
print qq{This should work\n};
__END__
In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.8.0)
of 2005-04-14 on geertz.kineticode.com
Distributor `Apple Computers', version 10.3.9
configured using `configure '--with-carbon' '--without-x''
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-latin-1
default-enable-multibyte-characters: t
Major mode: CPerl
Minor modes in effect:
encoded-kbd-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-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
next-error-follow-minor-mode: Fol
Recent input:
down-mouse-1 mouse-1 C-x C-f b i n / t r y return
M-x c p e r l tab m o tab backspace backspace
return M-x r e p o tab r tab return
Recent messages:
Loading tool-bar...done
Loading image...done
Loading tooltip...done
Loading encoded-kb...done
For information about the GNU Project and its goals, type C-h C-p.
Loading perl-mode...done
Loading cperl-mode...done
Making completion list...
Loading help-mode...done
Loading emacsbug...done
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cperl-mode Parsing Bug
cperl-mode 5.0-Emacs does not properly parse POD, regular expressions,
or q* operators. When I start emacs -Q and enable font-lock-mode and
load the following program under cperl-mode, the regular expression is
not properly parsed and highlighted (if I were to insert a ' into it,
it would think that the rest of the script was a string!). The POD is
not recognized as separate from the program, and the qq{} operator in
the last line is not marked as a string.
Thank you. I've installed the patch below which I believe should fix
your problem.
Index: lisp/progmodes/cperl-mode.el
===
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cperl-mode.el,v
retrieving revision 1.60
diff -u -r1.60 cperl-mode.el
--- lisp/progmodes/cperl-mode.el25 Mar 2005 10:06:23 - 1.60
+++ lisp/progmodes/cperl-mode.el27 Apr 2005 19:44:16 -
@@ -1514,7 +1514,7 @@
(make-local-variable 'font-lock-syntactic-keywords)
(setq font-lock-syntactic-keywords
(if cperl-syntaxify-by-font-lock
- '(t (cperl-fontify-syntaxically))
+ '((cperl-fontify-syntaxically))
'(t)
(make-local-variable 'cperl-old-style)
(if (boundp 'normal-auto-fill-function) ; 19.33 and later
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re:
=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#= = =--- ---= . =--- , , . , , ) 25O I250 6$* ) 1250 2501-5 . 8$* ) 25Ol . I0$* *- , ---= . 9I6-l9-72 =--- =#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#=-=#= ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
