Re: fringe arrow conflict between compile and gud?
> "Nick" == Nick Roberts writes: > > I don't use more than one arrow per buffer. However, I do think compile > should use overlay-arrow-variable-list instead of making > overlay-arrow-position a local variable. I now can reproduce the conflict > that > Juan-Leon reports. GUD and Compile are operating on the same source buffer > and > the local variable masks the global one when set in gud-display-line. The > global value is used to set window-point and this remains unchanged (from > nil): > I can trigger the error with following sequence: emacs -Q (setq next-error-highlight 'fringe-arrow) C-x C-e C-x C-f foo.c create a foo.c with errors M-x compile gcc -g foo.c Jump to errors pressing RET on compilation buffer and fix it without deleting line where fringe arrow is, so it remains after doing: M-x compile gcc -g foo.c M-x gdb (line is gdb --fullname a.out) b main run now I get an error: error in process filter: Wrong type argument: integer-or-marker-p, nil error in process filter: gud-display-line: Wrong type argument: integer-or-marker-p, nil The overlay arrow is updated fine, but buffer is not scrolled to new position (if you make foo.c 100 lines long, the compilation error were in line 2 and main is in line 90 you'll see better this). Maybe this info regarding what I have may help with this: /compile.el/1.346/Wed Feb 9 15:50:36 2005// /gud.el/1.29/Wed Feb 2 05:52:51 2005// gdb --version = GNU gdb 5.1 Regards -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ibuffer-toggle-sorting-mode problem
In ibuffer, I can use the (default) key "," to call function `ibuffer-toggle-sorting-mode', that rotates between modes "sorting by size", "sorting by alphabetic", "sorting by major-mode", "sorting by mode-name" and "sorting by recency". Problem is that when toggling to "sorting by recency" ibuffer does not update the order (but it updates OK if right after this I press the "g" key, bound to `ibuffer-update') This is the revisions of ibuffer related files I have: /ibuf-ext.el/1.41/Wed Mar 2 21:27:05 2005// /ibuf-macs.el/1.16/Mon May 10 18:13:07 2004// /ibuffer.el/1.66/Wed Feb 9 15:50:42 2005// Regards -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fringe arrow conflict between compile and gud?
On Thu, 24 Mar 2005 23:27:27 +0200, Juri Linkov <[EMAIL PROTECTED]> wrote: > > 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). > > What is the most suitable time for the fringe arrow to disappear? > After recompile? After a delay for specified time? After the user > clicks on the fringe arrow? Maybe this should be configurable. IMHO, most suitable time would be when recompiling again. But despite of this, there is no guarantee that some other "package" (like gud) will not try to use the fringe arrow before recompiling, so making arrow to disapear based on user actions may be not the right solution. -- juanleon ___ 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
On Wed, 23 Mar 2005 21:43:12 +0200, Juri Linkov <[EMAIL PROTECTED]> wrote: > 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. > Yes, it works great. Thanks for looking into this. -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fringe arrow conflict between compile and gud?
On Thu, 24 Mar 2005 11:33:45 +1200, Nick Roberts <[EMAIL PROTECTED]> wrote: > FWIW I could not reproduce Juan-Leon's error. In fact if I set > next-error-highlight to 'fringe-arrow I could only get one arrow to display > (in the compilation buffer). The source buffer showed nothing. This is what > I would expect, however, because the same thing happened in gdb-ui when > both the source buffer and assembler buffer until you made the changes which > allowed multiple overlay arrows. With Gnus and GUD, don't they constantly > steal the arrow from each other? > > Juan-Leon can you see an arrow in the compilation buffer and source buffer > at the same time? Yes, I can. If I hit RET on an error, both arrow are present. -- juanleon ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
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
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(# nil)
gud-display-line("/home/leon/Testing/C/foo.c" 2182)
gud-display-frame()
gud-filter(#
"/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
Problem at backup-buffer for writable files in not writable dirs
Hi, When you edit and save a writable file in a non writable dir, and you have `backup-by-copying' to nil (the default), backup-buffer fails to make a backup in the place user has defined with variable `backup-directory-alist' (because you cannot move files that are in a not writable dir, despite of file ownership), so it copies it to file "~/%backup%~". [ I know having writable files in non writable files is not very usual, but I have to edit some conf files in such directories and I got this ~/%backup%~ file around all the time ] IMHO this one-liner patch solves the problem, by detecting this situation as one of the cases where a copy should be used to backup the file instead of moving. You may want to review and/or apply it. Regards juanleon --- files.el.oriThu Mar 10 09:29:31 2005 +++ files.elThu Mar 10 10:02:00 2005 @@ -2686,6 +2686,7 @@ backup-by-copying ;; Don't rename a suid or sgid file. (and modes (< 0 (logand modes #o6000))) + (not (file-writable-p (file-name-directory real-file-name))) (and backup-by-copying-when-linked (> (file-nlinks real-file-name) 1)) (and (or backup-by-copying-when-mismatch ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
