Re: void-variable c-subword-mode with debug-on-error
> From: Ralf Angeli <[EMAIL PROTECTED]> > Date: Sat, 08 Apr 2006 21:23:21 +0200 > > When starting Emacs with > > emacs -Q -f toggle-debug-on-error test.c > > the following error occurs: > > Debugger entered--Lisp error: (void-variable c-subword-mode) > > Ater quitting the debugger with `q' the error can be provoked as well > by clicking with the mouse on a menu. (That's in fact the way I > noticed this at all.) I cannot reproduce this with the current CVS. Neither of your two recipes causes an error. Is there something special about test.c? is it an existing file? (I tried with both non-existing file and one of the Emacs source files, but perhaps you have something in test.c that triggers this problem.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse pointer changes to I-bar over menu items
> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org > From: Jason Rumney <[EMAIL PROTECTED]> > Date: Sat, 08 Apr 2006 19:08:41 +0100 > > Eli Zaretskii <[EMAIL PROTECTED]> writes: > > > Does the change below look good? It fixes the problem for me. > > Yes, that looks like it will do the right thing. Thanks, committed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
void-variable c-subword-mode with debug-on-error
When starting Emacs with emacs -Q -f toggle-debug-on-error test.c the following error occurs: Debugger entered--Lisp error: (void-variable c-subword-mode) Ater quitting the debugger with `q' the error can be provoked as well by clicking with the mouse on a menu. (That's in fact the way I noticed this at all.) In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.16) of 2006-04-08 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-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_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: C/l Minor modes in effect: tooltip-mode: t auto-compression-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 line-number-mode: t abbrev-mode: t Recent input: p C-p C-SPC C-n M-w q M-x r e p o r t - m e m Recent messages: (emacs -Q -f toggle-debug-on-error test.c) For information about the GNU Project and its goals, type C-h C-p. Debug on Error enabled (New file) Loading cc-mode...done Loading debug...done Entering debugger... Mark set Back to top level. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash in xdisp.c: show_mouse_face
On Apr 3, 2006, at 2:42 AM, YAMAMOTO Mitsuharu wrote: Phil, do you possibly set the variable `mouse-highlight' to some integer? I've confirmed that nothing I am doing uses mouse-highlight. Thanks, Phil ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse pointer changes to I-bar over menu items
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Does the change below look good? It fixes the problem for me. Yes, that looks like it will do the right thing. > Index: src/w32fns.c > === > RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v > retrieving revision 1.267 > diff -u -p -r1.267 w32fns.c > --- src/w32fns.c 8 Apr 2006 12:26:25 - 1.267 > +++ src/w32fns.c 8 Apr 2006 12:57:27 - > @@ -3297,6 +3297,14 @@ w32_wnd_proc (hwnd, msg, wParam, lParam) >return (msg == WM_XBUTTONDOWN || msg == WM_XBUTTONUP); > > case WM_MOUSEMOVE: > + /* Ignore mouse movements as long as the menu is active. These > + movements are processed by the window manager anyway, and > + it's wrong to handle them as if they happened on the > + underlying frame. */ > + f = x_window_to_frame (dpyinfo, hwnd); > + if (f && f->output_data.w32->menubar_active) > + return 0; > + >/* If the mouse has just moved into the frame, start tracking >it, so we will be notified when it leaves the frame. Mouse >tracking only works under W98 and NT4 and later. On earlier ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fcitx and Emacs fights over C-Space key compostion.
"Yiyi Hu" <[EMAIL PROTECTED]> writes: > Since I prefer use fcitx to the im built-in within Emacs, > > But the problem now is, if you are in X, you can no longer activate > fcitx within emacs. > > If anyone need more info on this, please tell me. > > yours: xinming I would bet that few people in this list are using fcitx. Does it help if you unset the C-space key binding for emacs? -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fcitx and Emacs fights over C-Space key compostion.
Richard Stallman <[EMAIL PROTECTED]> writes: > What is fcitx? It's an app to input Chinese chars. http://packages.debian.org/unstable/utils/fcitx -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: frame-set-background-mode changes frame background for special-display frames
Just wanted to let you know that I was mistaken - I do not think there is an Emacs bug here. Thanks for letting us know. And thanks for reporting the bug when you thought it was one. But please do always find a precise recipe (for a reproducible bug), to make sure the report is useful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fcitx and Emacs fights over C-Space key compostion.
What is fcitx? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse pointer changes to I-bar over menu items
> Date: Sat, 08 Apr 2006 09:53:24 +0300 > From: Eli Zaretskii <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > Btw, there's a similar slightly annoying problem with the cursor > shape: start with the mouse pointer outside the Emacs frame, and then > move the mouse so that it enters the Emacs frame's tool bar from the > right, where normally there are no buttons---the cursor shape retains > its <--> shape until you either move out of the tool bar or hit the > first button. The correct behavior would be to have the <--> shape > only on the border of the frame, and then immediately switch to the > normal arrow shape. After some digging, it looks like, when the mouse crosses the Emacs frame border, we leave the mouse cursor shape change to the Windows GUI. Is that true? If so, I'm unsure how to fix this without writing lots of code to handle the WM_SETCURSOR message in our code instead of leaving that to Windows. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse pointer changes to I-bar over menu items
> More likely the mouse move messages when we are over a menu do not > correspond to any frame, and instead of discarding them, we use the > same x/y coordinates in the default frame and go through all the > mouse highlight and pointer code (though that does not explain why > this does not happen with a single frame). Thanks for checking this. I hesitated to send the bug report because I didn't see a sure-fire recipe for this - sometimes it happens and sometimes it doesn't. Like Jason, I noticed more than one pointer change sometimes, but the second change was to the hourglass, so I figured maybe something was busy somehow. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse pointer changes to I-bar over menu items
> Cc: "Drew Adams" <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org > From: Jason Rumney <[EMAIL PROTECTED]> > Date: Sat, 08 Apr 2006 09:51:13 +0100 > > More likely the mouse move messages when we are over a menu do not > correspond to any frame, and instead of discarding them, we use the > same x/y coordinates in the default frame and go through all the > mouse highlight and pointer code (though that does not explain why > this does not happen with a single frame). I think you are right. Does the change below look good? It fixes the problem for me. Index: src/w32fns.c === RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v retrieving revision 1.267 diff -u -p -r1.267 w32fns.c --- src/w32fns.c8 Apr 2006 12:26:25 - 1.267 +++ src/w32fns.c8 Apr 2006 12:57:27 - @@ -3297,6 +3297,14 @@ w32_wnd_proc (hwnd, msg, wParam, lParam) return (msg == WM_XBUTTONDOWN || msg == WM_XBUTTONUP); case WM_MOUSEMOVE: + /* Ignore mouse movements as long as the menu is active. These +movements are processed by the window manager anyway, and +it's wrong to handle them as if they happened on the +underlying frame. */ + f = x_window_to_frame (dpyinfo, hwnd); + if (f && f->output_data.w32->menubar_active) + return 0; + /* If the mouse has just moved into the frame, start tracking it, so we will be notified when it leaves the frame. Mouse tracking only works under W98 and NT4 and later. On earlier ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Bug-AUCTeX] 11.82; flyspell-mode mouse-2 yanks as well
* Eli Zaretskii (2006-04-08) writes: >> From: Ralf Angeli <[EMAIL PROTECTED]> >> >> I can sort of reproduce this with a Windows build of 2006-03-09 [...] > This bug, which was indeed specific to MS-Windows, was fixed on > 2006-03-11 Argh, sooo close. (c: -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Bug-AUCTeX] 11.82; flyspell-mode mouse-2 yanks as well
> From: Ralf Angeli <[EMAIL PROTECTED]> > Date: Sat, 08 Apr 2006 14:25:47 +0200 > Cc: bug-auctex@gnu.org, Alun Pope <[EMAIL PROTECTED]> > > The following bug report originally was sent to the AUCTeX bug list. > I can sort of reproduce this with a Windows build of 2006-03-09 in > Text mode, so this is rather an Emacs issue than one of AUCTeX. I am > writing "sort of" because I cannot reproduce it reliably. The yank > does not happen every time when trying to correct a word. > > Unfortunately I cannot check a newer build because I don't have easy > access to a broad-band connection and doing a cvs up over a modem > connection in my local repository for the Windows build takes forever > (I interrupted the update after about 50 minutes). Thanks for reporting this. This bug, which was indeed specific to MS-Windows, was fixed on 2006-03-11, with this change: 2006-03-11 Eli Zaretskii <[EMAIL PROTECTED]> * w32fns.c (w32_wnd_proc): Ignore middle and extra button events if a menu is already active (the menubar_active flag is on). So upgrading to the latest CVS should make the problem go away. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Bug-AUCTeX] 11.82; flyspell-mode mouse-2 yanks as well
The following bug report originally was sent to the AUCTeX bug list.
I can sort of reproduce this with a Windows build of 2006-03-09 in
Text mode, so this is rather an Emacs issue than one of AUCTeX. I am
writing "sort of" because I cannot reproduce it reliably. The yank
does not happen every time when trying to correct a word.
Unfortunately I cannot check a newer build because I don't have easy
access to a broad-band connection and doing a cvs up over a modem
connection in my local repository for the Windows build takes forever
(I interrupted the update after about 50 minutes).
* Alun Pope (2006-04-06) writes:
> Here is a short example file, which also explains the problem. This seems to
> have to do with the
> beta-version of Emacs I got for using preview with auctex. So it
> seems to be about the auctex-emacs interaction which is why i have
> sent it to the list.
>
> %---example
> \documentclass{article}
> \begin{document}
>
> Turn flyspell-mode on.
>
> Then delete some stuff. Deleted text is SPURIOUS JUNK. (Deleted by
> mouse-highlighting and delete key.)
>
> Now make a spelling mistake: false.
>
>
> SPURIOUS JUNK
>
>
> The sequence was false was spelled flase, mouse-2 to correct, select
> correct text then left-click. Then the correction is made but the extra
> text SPURIOUS JUNK appears two lines further on, presumably because it
> is being yanked by the mouse-2, in addition to the correct behaviour
> (flyspell-mode's correct-at-point). If there is text on the line
> SPURIOUS JUNK is appended.
> \end{document}
>
>
> %%% Local Variables:
> %%% mode: latex
> %%% TeX-master: t
> %%% End:
> %end example
>
>
>
> Emacs : GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195)
> of 2006-01-29 on NEUTRINO
> Package: 11.82
>
> current state:
> ==
> (setq
> AUCTeX-date "2005-12-17"
> window-system 'w32
> LaTeX-version "2e"
> TeX-style-path '("style" "auto" "c:/MyLatexDocs/BibFiles/style"
> "c:/MyLatexDocs/BibFiles/auto"
> "c:/emacs/Emacs/site-lisp/auctex/style" "../var/auctex")
> TeX-auto-save t
> TeX-parse-self t
> TeX-master "h:/SGI/SGI - Premium Principles/PremiumPricing80to85"
> TeX-command-list '(("View pdf" "acrord32.exe %s.pdf" TeX-run-command
> nil t)
> ("All pdf" "texify --pdf %s.tex" TeX-run-command
> nil t)
> ("Clean"
>"del %s.log *.aux %s.out %s.exa %s.ilg %s.idx
> %s.ind %s.lof %s.lot %s.toc %s.bbl %s.blg %s.dvi %s.ps %s.2.ps
> %s.pdf" TeX-run-command nil t)
> ("All" "texify --tex-opt=--src %s.tex"
> TeX-run-command nil
>t)
> ("SmallGhostview" "gsview32.exe %s-2.ps"
> TeX-run-command
>nil t)
> ("HalfSize" "psnup -2 %f %s-2.ps" TeX-run-command
> nil t)
> ("TeX" "%(PDF)%(tex) %S%(PDFout) \"%(mode)\\input
> %t\""
>TeX-run-TeX nil
>(plain-tex-mode ams-tex-mode texinfo-mode) :help
>"Run plain TeX")
> ("LaTeX" "%l \"%(mode)\\input{%t}\"" TeX-run-TeX
> nil
>(latex-mode doctex-mode) :help "Run LaTeX")
> ("Makeinfo" "makeinfo %t" TeX-run-compile nil
>(texinfo-mode) :help "Run Makeinfo with Info
> output")
> ("Makeinfo HTML" "makeinfo --html %t"
> TeX-run-compile nil
>(texinfo-mode) :help "Run Makeinfo with HTML
> output")
> ("AmSTeX" "%(PDF)amstex %S%(PDFout)
> \"%(mode)\\input %t\""
>TeX-run-TeX nil (ams-tex-mode) :help "Run
> AMSTeX")
> ("ConTeXt" "texexec --once --texutil
> %(execopts)%t"
>TeX-run-TeX nil (context-mode) :help "Run ConTeXt
> once")
> ("ConTeXt Full" "texexec %(execopts)%t"
> TeX-run-TeX nil
>(context-mode) :help "Run ConTeXt until
> completion")
> ("ConTeXt Clean" "texutil --purgeall"
> TeX-run-interactive
>nil (context-mode) :help "Clean temporary ConTeXt
> files")
> ("BibTeX" "bibtex %s" TeX-run-BibTeX nil t :help
>"Run BibTeX")
> ("View" "%V" TeX-run-discard t t :help "Run
> Viewer")
> ("Print" "%p" TeX-run-command t t :help "Print the
> file")
> ("Queue" "%q" TeX-run-background nil t :help
>"View the printer queue" :visible
> TeX-queue-command)
> ("File" "%(o?)dvips %d -o %f " TeX-run-command t t
> :help
>"Generate PostScript file")
> ("Index" "makeindex %s" TeX-run-command nil t
> :help
>"Create index file")
> ("Check" "lacheck %s" TeX-run-compile nil
> (latex-mode)
>:help "Check LaTeX file for correctness")
> ("Spell" "" TeX-run-ispell-on-document
> nil t
>:help "Spell-check the document")
> ("Other" "" TeX-run-command t t :help
>"Run an arbitrary command")
> )
> )
>
>
> -
> Dr Alun Pope
>
> Group Credit
> St.George Bank
> Level 9
> 182 George St
> Sydney NSW 2000
>
> (T): 02 9236 1442
> (F): 02 9236 1570
>
>
> **
> * IMPORTANT INFORMATION*
> This document should be read only by those persons to
Re: mouse pointer changes to I-bar over menu items
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Confirmed. I think this is related to redisplay cycles: in some > situations we forget to change the cursor type back to the arrow > shape. When I reproduced it, my mouse never left the menus, and changed from an arrow to an I-bar back to an arrow, then to a hand. I think it is more than forgetting to change the cursor back, as the cursor should never have become an I-bar or hand. More likely the mouse move messages when we are over a menu do not correspond to any frame, and instead of discarding them, we use the same x/y coordinates in the default frame and go through all the mouse highlight and pointer code (though that does not explain why this does not happen with a single frame). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
