fringe arrow conflict between compile and gud?
Hi, I have: (setq next-error-highlight 'fringe-arrow) If I find error while compiling, next-error put a fringe arrow in the error line. If I fix the error and compile again, the fringe arrow does not dissapear (I do not if this is intended to be this way). If the I open a gud session, I cannot track execution on file where compilation fringe arrow is (I suppose some sort of conflict occurs). Sometimes an error occurs: Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) set-window-point(#window 382 on *Backtrace* nil) gud-display-line(/home/leon/Testing/C/foo.c 2182) gud-display-frame() gud-filter(#process gud-a.out /home/leon/Testing/C/foo.c:2182:59257:beg:0x805663b\n) And sometimes no error, but next and step gud commands do not scroll to line where program execution is. Of course these problems dissapear as soon I reload source file where fringe arrow was. -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Not really a bug ...
Am 23.03.2005 um 01:58 schrieb Richard Stallman: It is supposed to be a quick click only that will visit the file. A long click should move point. Doesn't it do that? Yes, after I read about it, I found that it works exactly as described. Since I stick to click-to-focus to have control to where my input goes it can happen that I open a file or follow a link unwillingly, so the other way 'round would be more sensible: short click is usual behaviour, longer click opens/follows. -- Greetings Pete ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Fw:
$B40A4L5NA3NDj!*!*!*(B
$B:#$^$G![EMAIL PROTECTED],(B
$B9%I$K$D$-!A49q3HBg!*!*:#$,%A%c%s%9$G$9!#(B
$B(%3%3$KEPO?$7$F$k=w$N;R$OK\Ev$G$9!#(B
1.$B5U!{=u4uK[EMAIL PROTECTED](B
2.$B#S#M4uK[EMAIL PROTECTED](B
3.$B:#F|[EMAIL PROTECTED](B
4.$BITNQ4uK[EMAIL PROTECTED](B
[EMAIL PROTECTED]|Bj(B
$BAa$/$7$J$$$H#S#O#L#D!!#O#U#T(B
http://loves.qsv20.com/
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
fringe arrow conflict between compile and gud?
Here's my take on this: In the beginning there was just one overlay-arrow-position shared between GUD and Edebug. Now there are more modes competing for it, there are conflicts. Compilation modes, as you describe uses it in two places and tries to get round the problem by making overlay-arrow-position a local-variable. I think this is the wrong way. Kim Storm created a variable overlay-arrow-variable-list to allow multiple overlay arrows (see info). I have used this for buffers displaying assembler in gdb-ui.el (gdb-overlay-arrow-position). I can offer to try fix this problem but my analysis might be wrong. There may be others who understand it better than me and who can fix it. Nick I have: (setq next-error-highlight 'fringe-arrow) If I find error while compiling, next-error put a fringe arrow in the error line. If I fix the error and compile again, the fringe arrow does not dissapear (I do not if this is intended to be this way). If the I open a gud session, I cannot track execution on file where compilation fringe arrow is (I suppose some sort of conflict occurs). Sometimes an error occurs: Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) set-window-point(#window 382 on *Backtrace* nil) gud-display-line(/home/leon/Testing/C/foo.c 2182) gud-display-frame() gud-filter(#process gud-a.out /home/leon/Testing/C/foo.c:2182:59257:beg:0x805663b\n) And sometimes no error, but next and step gud commands do not scroll to line where program execution is. Of course these problems dissapear as soon I reload source file where fringe arrow was. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
problems with utf8 chars
Symptoms: utf-8 chars doesnt work in todays emacs. they show up as empty spaces. I tried emacs -nw --no-init and typed some swedish chars =8e5=8e4=8f6. swedish chars do work at the shell prompt. im running this on a redhat fedora core 2 gnu/linux box remotely over ssh using the putty ssh w32 client. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.4.14) of 2005-03-22 on naru.home configured using `configure '--with-gtk' '--with-x' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' 'CFLAGS=-g'' 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.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Shell Minor modes in effect: auto-compression-mode: t display-time-mode: t show-paren-mode: t erc-truncate-mode: t erc-log-mode: t erc-bbdb-mode: t erc-autoaway-mode: t erc-autojoin-mode: t erc-button-mode: t erc-ring-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-fill-mode: t erc-stamp-mode: t erc-netsplit-mode: t erc-smiley-mode: t which-function-mode: t encoded-kbd-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t transient-mark-mode: t Recent input: C DEL c k s =8c3 =8a5 SPC C-x b p h RET p DEL o c h s =8c3 =8a5 DEL DEL DEL DEL DEL o c k s =8c3 =8a5 DEL DEL DEL DEL DEL h m m RET C-x b RET C-c C-s C-x b b u i RET RET RET RET c d SPC e m a c s RET ESC x e m a c s SPC b SPC DEL r e p SPC o SPC DEL DEL DEL DEL C-a C-k r e p o SPC r SPC e m SPC b SPC RET Recent messages: Mark set [2 times] Auto-saving...done Auto-saving...done Sending... Sending via mail... nnimap: Updating info for nnimap+naru:imapmail/Sent...done Sending...done /net/builds/emacs Making completion list... Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
icomplete too intrusive
Symptoms: When icomplete is switched on, it is a bit too intrusive: On sending a bug report, the user is asked to put a bug description in the subject. While the description is typed in, (No matches) is displayed all the time. This is annoying because how can there be matches? In dired mode, press `d' on a file, and then `x'. You will be asked whether you want the file to be deleted (yes or no question). When you type the answer, (No matches) is displayed. Either it should not appear at all, or match on yes or no. In GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-03-22 on cc.at.coli.uni-sb.de Distributor `The XFree86 Project, Inc', version 11.0.40201000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: POSIX value of $LC_CTYPE: en_GB.ISO8859-15 value of $LC_MESSAGES: en_GB.ISO8859-15 value of $LC_MONETARY: [EMAIL PROTECTED] value of $LC_NUMERIC: en_GB.ISO8859-15 value of $LC_TIME: en_GB.ISO8859-15 value of $LANG: en_GB.ISO8859-15 locale-coding-system: iso-8859-15 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: icomplete-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: help-echo help-echo escape x i c o m p tab return C-x C-j escape x d i r e d C-g C-x C-f backspace return D C-g escape x i c o m tab return escape x up return d x y e s help-echo C-x C-f C-g C-g C-x C-f a a d f s a j s f escape backspace C-g help-echo up u down C-x C-f l i s tab / C h tab return C-s i c o m p l e t e C-x k return help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Quit Icomplete mode disabled Icomplete mode enabled Quit find-file-read-args: Command attempted to use minibuffer while in minibuffer Quit [4 times] Loading add-log...done Loading vc-cvs...done Mark saved where search started Loading emacsbug...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Somehow disp-table.el gets loaded on Mac OS X
So, which terminal-coding-system should we set by default when LANG is de_DE.UTF-8(en_US.UTF-8), iso-latin-1 or utf-8? The terminal coding system does not necessarily depend on LANG. It seems that OSX's Terminal.app uses utf-8 by default, independently from any locale. Maybe it can be set to something else, of course. The problem I have now is: how can we detect when Emacs is running in Terminal.app. The TERM envvar is set to xterm-color, just like it is in several X11 terminals (which don't use utf-8 by default). UTF-8 should be the natural/native encoding in dired-mode, shell, shell-command-on-region, find-grep. file-name-coding-system on OSX already defaults to utf-8. And a different object is Carbon Emacs! When running in Terminal.app, it should be no different. Although too a Mac OS X binary it comes directly from Mac OS 9 and seems to have no good idea of Unicode and UTF-8. I do not know from where you get this misconception. It handles Unicode *exactly* like the rest since it's using the exact same code. It's fontsets are Mac-Roman oriented and it's close to impossible for Latin scripts to use the whole spectrum. Maybe the default font settings need to be changed. 'defaults read com.apple.Terminal StringEncoding' would reveal the default encoding of Terminal, % defaults read com.apple.Terminal StringEncoding 2005-03-23 07:43:09.466 defaults[9360] The domain/default pair of (com.apple.Terminal, StringEncoding) does not exist % -- Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
2 character comment starter bug
I've got comment characters defined like this for tacl-mode
(modify-syntax-entry ?\~ / st) ; ~ gets Escape syntax
(modify-syntax-entry ?\{ st) ; comment start {
(modify-syntax-entry ?\} st) ; comment end }
(modify-syntax-entry ?\= _ b12 st) ; comment start ==
(modify-syntax-entry ?\n b st) ; eol ends == comment
By my understanding == start a comment in all cases except
this: ~== because ~ has escape syntax. But that is not true.
code == This is a comment
code== This should be a comment but isn't!
My testing indicates that if the character immediately prior
to == has word `w' or symbol `_' syntax the == sequence is
not recognized as comment start.
Single character comment starters have no such problem
code{properly recognized comment here}
Richard Bielawski
612-667-5039
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Acrobat Pro 7.0 $69.95 Macromedia
Title: 2887726 Browse Search Shop My eSoft Community Back to Software Overview Home All Categories Computers Software Operating Systems Windows All Items Auctions Buy It Now Windows Adobe Macromedia Refine Search Top Sellers 1 Windows XP Pro 2 Office XP 2002 Pro 3 Adobe Acrobat 7.0 Professional 4 Adobe Photoshop CS 8.0 5 Office 2003 Pro 6 Macromedia Dream Weaver MX 2004 7 Macromedia Flash MX 2004 Pro 8 MS 2003 Server (Enterprise Edition) 9 Norton Antivirus 2005 10 CorelDraw Graphics Suite 12.0 11 Adobe Creative Suite Premium 12 Alias Wavefront
next-error-follow-minor-mode selects location window until next keystroke
Hi, I have set (setq next-error-highlight-no-select 2.0) In the following please suppose that I have activated `next-error-follow-minor-mode'. If in a grep or compilation buffer I move the cursor, the hit location buffer is shown in another window. Problem, IMHO, it that this window seems to be the selected one (cursor is not hollow and modeline shows it as selected window) until next keystroke (that is sent to grep or compilation buffer). This is quite confusing for me (specially now that great `mode-line-inactive' feature allows a faster visual recognition of witch is the selected window). OTHO, while `next-error-highlight-no-select' works great on compilation and grep buffers (and I really like it), occur buffers seems to ignore this variable (and also `next-error-highlight'). -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 2 character comment starter bug
(modify-syntax-entry ?\= _ b12 st) ; comment start == Yes, it seems the problem is that your 2-char comment sequence is made of symbol-chars, so there are cases where the code does things like oh, here's a symbol, let's skip it without checking whether some of the chars that compose the symbol happen to also be a comment-marker. Does your = char really need to have symbol syntax (i.e. _) or could it have punctuation syntax instead (i.e. .) ? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: icomplete too intrusive
,-- On Wed, 23 Mar 2005 08:43:44 -0500, Stefan wrote: | | On sending a bug report, the user is asked to put a bug description in | the subject. While the description is typed in, (No matches) is | displayed all the time. This is annoying because how can there be | matches? | | Sorry, I think I've fixed it now, | Looks OK now. Thanks, Frederik ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: next-error-follow-minor-mode selects location window until next keystroke
JUAN-LEON Lahoz Garcia [EMAIL PROTECTED] writes: (setq next-error-highlight-no-select 2.0) In the following please suppose that I have activated `next-error-follow-minor-mode'. If in a grep or compilation buffer I move the cursor, the hit location buffer is shown in another window. Problem, IMHO, it that this window seems to be the selected one (cursor is not hollow and modeline shows it as selected window) until next keystroke (that is sent to grep or compilation buffer). This is quite confusing for me (specially now that great `mode-line-inactive' feature allows a faster visual recognition of witch is the selected window). OTHO, while `next-error-highlight-no-select' works great on compilation and grep buffers (and I really like it), occur buffers seems to ignore this variable (and also `next-error-highlight'). Does the following patch produce good results for you? If yes, it could be also implemented for occur buffers too. BTW, `next-error-follow-minor-mode' should be renamed to `next-error-follow-mode' to follow Emacs naming conventions. Index: lisp/progmodes/compile.el === RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v retrieving revision 1.347 diff -u -r1.347 compile.el --- lisp/progmodes/compile.el 3 Mar 2005 20:08:21 - 1.347 +++ lisp/progmodes/compile.el 23 Mar 2005 19:38:54 - @@ -1613,6 +1613,8 @@ (compilation-set-window-height w) (when highlight-regexp + (if (timerp next-error-highlight-timer) + (cancel-timer next-error-highlight-timer)) (unless compilation-highlight-overlay (setq compilation-highlight-overlay (make-overlay (point-min) (point-min))) @@ -1632,12 +1634,18 @@ (move-overlay compilation-highlight-overlay (point) end (current-buffer))) (if (numberp next-error-highlight) - (sit-for next-error-highlight)) - (if (not (eq next-error-highlight t)) + (setq next-error-highlight-timer + (run-at-time next-error-highlight nil 'delete-overlay + compilation-highlight-overlay))) + (if (not (or (eq next-error-highlight t) +(numberp next-error-highlight))) (delete-overlay compilation-highlight-overlay)) (when (and (eq next-error-highlight 'fringe-arrow)) (set (make-local-variable 'overlay-arrow-position) (copy-marker (line-beginning-position)) + +(defvar next-error-highlight-timer nil) + (defun compilation-find-file (marker filename dir rest formats) Find a buffer for file FILENAME. -- 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: Somehow disp-table.el gets loaded on Mac OS X
Am 23.03.2005 um 19:52 schrieb Stefan Monnier: Does the patch below help? No. Still I have: (Quellen/Emacs_CVS/emacs/src/emacs) Loading disp-table...done Loading encoded-kb...done Sind jetzt in PETEs .emacs but at least I can see my UTF-8 file names in dired correctly. BTW, xterm too can display some UTF-8 glyphs too: Current language environment: German # Section 2. Display Terminal: xterm Coding system of the terminal: utf-8 This is the corresponding mule-diagnosis in Terminal.app: Current language environment: German # Section 2. Display Terminal: xterm-color Coding system of the terminal: utf-8 I launched the newly patched Emacs in both. -- Greetings Pete They're putting dimes in the hole in my head to see the change in me. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
