9:37 p.m.
Adrian Aichner <adrian(a)xemacs.org> writes:
> Malcolm
>
> lisp/ChangeLog addition:
>
> 2005-10-10 Malcolm Purvis <malcolmp(a)xemacs.org>
>
> * minibuf.el:
> * minibuf.el (read-buffer): Follow GNU Emacs behaviour: Can return
> empty string if require-match is t and default is nil.
> * replace.el: Moved occur code to occur.el
> * simple.el:
> * simple.el (line-number-at-pos): New.
> * subr.el:
> * subr.el (delete-dups): New.
> * occur.el: New. Sync with 22.0.50.1 (CVS)
> * next-error.el: New. Sync with 22.0.50.1 (CVS)
Hi Malcolm,
are you aware that compile.el in the xemacs-base package also contains
a definition of
(defun next-error (&optional argp)
and your sync broke next-error functionality for me in
grep
igrep
igrep-find.
Any news on this one, Malcolm?
Best regards,
Adrian
Please take a look.
Thanks
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
11:24 a.m.
New subject: [PATCH] Sync of occur-mode with GNU Emacs CVS.
>>>> "Adrian" == Adrian Aichner
<adrian(a)xemacs.org> writes:
Adrian> Any news on this one, Malcolm?
I've ready committed what I thin is the necessary change (see
http://list-archive.xemacs.org/xemacs-patches/200511/msg00186.html)
Is the problem still occuring?
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
3:08 p.m.
New subject: [PATCH] Sync of occur-mode with GNU Emacs CVS.
Malcolm Purvis <malcolmp(a)xemacs.org> writes:
>>>>> "Adrian" == Adrian Aichner
<adrian(a)xemacs.org> writes:
Adrian> Any news on this one, Malcolm?
I've ready committed what I thin is the necessary change (see
http://list-archive.xemacs.org/xemacs-patches/200511/msg00186.html)
Is the problem still occuring?
Hi Malcolm, I already confirmed the fix for the issue above.
The remaining problem is with M-x next-error functionality.
Does
C-x ` next-error
work for you after
M-x compile
M-x grep
M-x igrep-find
?
It's broken for me, after I use
M-x list-matching-lines
once.
I better this is due to redefinition of next-error, which is also in
compile.el.
Also, I lack traceability of the decision (and consencus) to have
occur.el in core (I realize it used to be, being contained in
replace.el) and to even move next-error.el into core (functionality
that used to be in xemacs-base/compile.el, at least partially).
I'm surprised I'm the only one reporting these problems.
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
9:13 p.m.
New subject: [PATCH] Sync of occur-mode with GNU Emacs CVS.
On Sat, 03 Dec 2005, adrian(a)xemacs.org wrote:
Malcolm Purvis <malcolmp(a)xemacs.org> writes:
>>>>>> "Adrian" == Adrian Aichner <adrian(a)xemacs.org>
writes:
>
> Adrian> Any news on this one, Malcolm?
>
> I've ready committed what I thin is the necessary change (see
> http://list-archive.xemacs.org/xemacs-patches/200511/msg00186.html)
>
> Is the problem still occuring?
Hi Malcolm, I already confirmed the fix for the issue above.
The remaining problem is with M-x next-error functionality.
Does
C-x ` next-error
work for you after
M-x compile
M-x grep
M-x igrep-find
?
It's broken for me, after I use
M-x list-matching-lines
once.
I better this is due to redefinition of next-error, which is also in
compile.el.
Also, I lack traceability of the decision (and consencus) to have
occur.el in core (I realize it used to be, being contained in
replace.el) and to even move next-error.el into core (functionality
that used to be in xemacs-base/compile.el, at least partially).
I'm surprised I'm the only one reporting these problems.
I've noticed a different problem with igrep. I switch into the
*igrep* buffer and next/previous line looking at interesting lines.
Right after doing M-x igrep, the point in the *igrep* buffer is on the
last line that says (default igrep finished at ...). If you switch
into the *igrep* buffer (Eg C-x o) with the point on the last line,
the function compilation-find-file is very insistent on getting an
answer to some question.
Find this error in (default igrep finished at ...):
The line 'default igrep finished' is not an error that can be found.
When you C-g out of the question, you get thrown out of the *igrep*
buffer. You have to use scroll other window or some other similar
command to get the point in the *igrep* window away from the last
line.
The cause of this behavior is the (or buffer ...) code in compilation-find-file.
(defun compilation-find-file (marker filename dir &rest formats)
(or buffer
;; The file doesn't exist.
;; Ask the user where to find it.
;; If he hits C-g, then the next time he does
;; next-error, he'll skip past it.
(let* ((pop-up-windows t)
(w (display-buffer (marker-buffer marker))))
(set-window-point w marker)
(set-window-start w marker)
(let ((name (expand-file-name
(read-file-name
(format "Find this error in: (default %s) "
filename)
dir filename t))))
(if (file-directory-p name)
(setq name (expand-file-name filename name)))
(and (file-exists-p name)
(progn
(push-file-name-history name)
(find-file-noselect name))))))
-jeff
5:16 a.m.
New subject: [PATCH] Sync of occur-mode with GNU Emacs CVS.
>>>> "Adrian" == Adrian Aichner
<adrian(a)xemacs.org> writes:
Adrian> I'm surprised I'm the only one reporting these problems.
Thank you Adrian and Jeff for reporting these problems but I can seem to
reproduce it locally. Could you give a simple example?
With 'xemacs -vanilla' I've tried using occur in a buffer and then igrep and
next-error behaves as I expect. igrep and then occur seems to work as well.
This is on MacOS X and RedHat FC3.
Adrian> Also, I lack traceability of the decision (and consencus) to have
Adrian> occur.el in core (I realize it used to be, being contained in
Adrian> replace.el) and to even move next-error.el into core (functionality
Adrian> that used to be in xemacs-base/compile.el, at least partially).
occur is in replace.el so I thought it reasonable to keep it in core. The
only reason that it was split out was that because it now uses faces it
prevented replace.el from dumping (at least in replace.el's current place in
the dump list. I didn't think it was wise to move it).
next-error.el is in core because occur.el depends on it. I hadn't considered
the clash with compile.el and I'll see what I can do to resolve it.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
7:41 a.m.
New subject: [PATCH] Sync of occur-mode with GNU Emacs CVS.
Malcolm Purvis wrote:
>>>>>"Adrian" == Adrian Aichner
<adrian(a)xemacs.org> writes:
>>>>>
>>>>>
Adrian> I'm surprised I'm the only one reporting these problems.
Thank you Adrian and Jeff for reporting these problems but I can seem to
reproduce it locally. Could you give a simple example?
With 'xemacs -vanilla' I've tried using occur in a buffer and then igrep and
next-error behaves as I expect. igrep and then occur seems to work as well.
This is on MacOS X and RedHat FC3.
Adrian> Also, I lack traceability of the decision (and consencus) to have
Adrian> occur.el in core (I realize it used to be, being contained in
Adrian> replace.el) and to even move next-error.el into core (functionality
Adrian> that used to be in xemacs-base/compile.el, at least partially).
occur is in replace.el so I thought it reasonable to keep it in core. The
only reason that it was split out was that because it now uses faces it
prevented replace.el from dumping (at least in replace.el's current place in
the dump list. I didn't think it was wise to move it).
"move it" means rearranging the order of dumped files? this is no big
deal; if it creates problems it will be obvious.
next-error.el is in core because occur.el depends on it. I hadn't
considered
the clash with compile.el and I'll see what I can do to resolve it.
try the old (if (not (fboundp 'next-error)) (defun ...)) trick.
6928
days inactive
6931
days old
5 comments
4 participants
participants (4)
-
Adrian Aichner -
Ben Wing -
Jeff Mincy -
Malcolm Purvis