follow mode for occur

follow mode for occur

[Dan Nicolaescu]

The code below implements a follow mode for the *Occur*, this was
inspired by `reftex-toc-follow-mode'. 
Pointer motion in the *Occur* buffer determines motion in the
original buffer. This allows one to quickly browse the *Occur*
buffer while seeing the corresponding matches in the original buffer. 

To try this out just evaluate the elisp code below. 
C-c C-f toggles the follow mode. 

Is there an interest to have something like this included in Emacs? 
If there is I can provide a patch acceptable for inclusion. 

How about implementing something similar for compile.el? 
I can provide code for that too. 

Please let me know what do you think about this. 

Thanks.

        --dan


(defcustom occur-follow-mode t
  "*Non-nil means that poing motion in the Occur buffer causes the file to follow.")

;;; Internal variable for `occur-mode-post-command-hook'.
(defvar occur-follow-last-line nil)

;;; Used as a post-command-hook for the *Occur* buffer.
(defun occur-mode-post-command-hook ()
  (when occur-follow-mode
    (unless (equal occur-follow-last-line (line-number-at-pos))
      (setq occur-follow-last-line (line-number-at-pos))
      (condition-case nil
	  (occur-mode-display-occurrence)
	(error t)))))

(add-hook 'occur-mode-hook 
	  (lambda ()   
	    (add-hook 'post-command-hook 'occur-mode-post-command-hook)))

(defun toggle-occur-follow-mode ()
  (interactive)
  (setq occur-follow-mode (not occur-follow-mode)))

(define-key occur-mode-map "\C-c\C-f" 'toggle-occur-follow-mode)

Re: follow mode for occur

[Sun Yi Ming]

i put all the code in .emacs,but it just dosn't work,i already C-c C-f 
to toggle the occur-follow-mode to t, what to do?

Thanks

Sun

Re: follow mode for occur

[Dan Nicolaescu]

Sun Yi Ming <lonewalker@vip.sina.com> writes:

  > i put all the code in .emacs,but it just dosn't work,i already C-c C-f 
  > to toggle the occur-follow-mode to t, what to do?

The code is on by default, so C-c C-f will just turn it off. 

Is it just me or the emacs-devel list is very very slow? 

Emacs-devel list IS slow [was Re: follow mode for occur]

[Kim F. Storm]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Is it just me or the emacs-devel list is very very slow? 

There is DEFINITELY a problem at gnu.org again.

For example, the following message has been waiting inside
gnu.org for more than 24 hours.

Received: from monty-python.gnu.org (monty-python.gnu.org [199.232.76.173])
	by ds12.enavn.org (8.10.2/8.10.2) with ESMTP id i4S04Xu19976
	for <storm@cua.dk>; Fri, 28 May 2004 02:04:33 +0200
Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	by monty-python.gnu.org with esmtp (Exim 4.34)	id 1BTSTD-00062w-EL
	for storm@cua.dk; Thu, 27 May 2004 17:31:23 -0400
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34)
	id 1BT7in-0007UC-GQ
	for emacs-devel@gnu.org; Wed, 26 May 2004 19:22:05 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34)
	id 1BT7i5-0007N8-4q
	for emacs-devel@gnu.org; Wed, 26 May 2004 19:21:52 -0400
Received: from [192.47.44.130] (helo=tsukuba.m17n.org)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1BT7i3-0007ML-Pk
	for emacs-devel@gnu.org; Wed, 26 May 2004 19:21:20 -0400

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: follow mode for occur

[Juri Linkov]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> The code below implements a follow mode for the *Occur*, this was
> inspired by `reftex-toc-follow-mode'. 

You could look also at color-moccur.el which already implements
follow mode for *Moccur* buffers.  Instead of using `post-command-hook'
it follows matches in the original buffer by special functions
`moccur-next' and `moccur-prev' bound to vertical motion keys.
And it toggles the follow mode by `t'.

> Is there an interest to have something like this included in Emacs? 
> If there is I can provide a patch acceptable for inclusion. 

This is a very useful thing.

However, your current implementation has one drawbacks: its indication
for the current match in the original buffer is not seen when
`cursor-in-non-selected-windows' is nil.  To solve this problem,
`occur-mode-display-occurrence' could be modified to call `next-error'
which would use location highlighting methods `next-error-highlight'
and `next-error-highlight-no-select'.

> How about implementing something similar for compile.el? 
> I can provide code for that too. 

It definitely needs to work in all modes supporting `next-error'
functionality: compile, grep, diff, occur.  This can be achieved by
generalizing all error functions and creating unified functions
like I suggested yesterday on emacs-devel.  For example, using
`goto-error-no-select' instead of `occur-mode-display-occurrence'.

So, if you want to develop this idea further, please take all this
into consideration.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: follow mode for occur

[Sun Yi Ming]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> The code is on by default, so C-c C-f will just turn it off. 
> 
> Is it just me or the emacs-devel list is very very slow? 
> 
> 
Oh,perhaps i should check the emacs setup again,but i alread set the 
occur-follow-mode to t.anyway thanks.
BTW,the emacs-devel list runs fast to me.

follow mode for occur

[Stephen Eglen]

 > The code below implements a follow mode for the *Occur*, this was
 > inspired by `reftex-toc-follow-mode'. 
 > Pointer motion in the *Occur* buffer determines motion in the
 > original buffer. This allows one to quickly browse the *Occur*
 > buffer while seeing the corresponding matches in the original buffer. 
 > 
A few years ago, I too wrote a "follow mode" based on the reftex
code.  You can get it from:
 http://www.anc.ed.ac.uk/~stephen/emacs/fm.el

Best wishes,
Stephen
[relevant doc appended below]

;;; Commentary:

;; As you move through the lines of an output buffer (such as from
;; `grep' or `occur'), another window highlights the corresponding
;; line of the source buffer.

;; This is inspired by the table of contents code from reftex.el.
;; http://www.strw.leidenuniv.nl/~dominik/Tools/

;;; Installation
;; To use the mode, do M-x fm-start in the output buffer.  Or just add
;; it to the mode hooks, e.g.:
;; (add-hook 'occur-mode-hook 'fm-start)
;; (add-hook 'compilation-mode-hook 'fm-start)
;; 

;;; Examples:
;;  
;; Do an occur for the word `package' in the NEWS file:
;; C-h n
;; M-x occur RTN package RTN

;; or test it on the current file:
;; (grep "grep -n 'def' fm.el")
;; (occur "def")

;; Once following is activated in a buffer, it can be toggled with the
;; "f" key in that buffer.

;; To extend this code to handle other types of output buffer, you
;; need to add an entry to the alist `fm-modes'.

;; If you want to use fm in a buffer that doesn't have a useful major
;; mode, you can always set the value of fm-defun yourself.  For
;; example, the cscope buffer is in fundamental mode, so in this case
;; we set fm-defun as a local variable to be the defun to use for
;; visiting the corresponding line of the source buffer.

(add-hook 'cscope-query-hook 'cscope-run-fm)

(defun cscope-run-fm ()
  "Run cscope in the fm buffer."
  (set (make-local-variable 'fm-defun) '(cscope-interpret-output-line))
  (fm-start))

;; If you are using this in the compile mode, you may find it easier
;; to use the key M-p to go to the previous error.  Otherwise, you may
;; find that if you go up one line, and this line doesn't have an
;; error on it, it goes down one line again, taking you back where you
;; started!

Re: follow mode for occur

[Dan Nicolaescu]

I want to thank everybody for all the feedback. 
Based on it I have a new version of this code. 

It is still based on post-command-hook because I believe it works
better this way.

It works in *Occur*, *compilation* and *grep* buffers. It works by
using the `next-error-no-select' function. I have not tested it on
diff buffers, but it seems that it should work there too. 

In *compilation*/*grep* buffers it does not work as smoothly as it
could because `compilation-goto-locus' ends up unconditionally calling
`set-window-start'. 
Would the compile.el maintainers accept a patch to fix this? 

It would also be nice if `compilation-mode' had a function similar to 
`occur-mode-display-occurrence' (and bound to the same key) to
display the error on the current line without switching from the
compilation buffer. 

Please let me know what do you think about the new version. 

(defcustom next-error-follow-mode t
  ;; FIXME: fix this docstring
  "*Non-nil means that point motion in the *** buffer causes the file to follow."
  ;; FIXME: find a proper group
  :group 'matching)

;;; Internal variable for `next-error-mode-post-command-hook'.
(defvar next-error-follow-last-line nil)

;;; Used as a post-command-hook for the *Compilation* *grep* 
;;; and *Occur* buffers.
(defun next-error-mode-post-command-hook ()
  (when next-error-follow-mode
    (unless (equal next-error-follow-last-line (line-number-at-pos))
      (setq next-error-follow-last-line (line-number-at-pos))
      (condition-case nil
	  ;;(save-window-excursion
	  (progn
	    (setq compilation-current-error (point))
	    (next-error-no-select 0))
	(error t)))))

(defun toggle-next-error-follow-mode ()
  (interactive)
  (setq next-error-follow-mode (not next-error-follow-mode)))

;;; All this stuff will be put in the corresponding files
;;; the *-hook-functions will be just pasted in the corresponing 
;;; *-mode functions

(defun compilation-follow-hook-function ()   
  (make-variable-buffer-local 'next-error-follow-last-line) 
  (add-hook 'post-command-hook 'next-error-mode-post-command-hook nil t))

(defun occur-follow-hook-function ()   
  (make-variable-buffer-local 'next-error-follow-last-line) 
  (add-hook 'post-command-hook 'next-error-mode-post-command-hook nil t))

(add-hook 'compilation-mode-hook 'compilation-follow-hook-function)
(add-hook 'occur-mode-hook 'occur-follow-hook-function)

;;; Key bindings 
;;; FIXME: Are these good? 
;;; FIXME: Should there be a menu entry for the toggle? 
(eval-after-load "compile"
  '(define-key compilation-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode))

(eval-after-load "grep"
  '(define-key grep-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode))

(define-key occur-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode)

Re: Emacs-devel list IS slow [was Re: follow mode for occur]

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 28 May 2004 10:43:53 +0200
> 
> Dan Nicolaescu <dann@ics.uci.edu> writes:
> 
> > Is it just me or the emacs-devel list is very very slow? 
> 
> There is DEFINITELY a problem at gnu.org again.
> 
> For example, the following message has been waiting inside
> gnu.org for more than 24 hours.

Here's another example.  Note that it took 3 hours for the message to
make the leg from mail to the list:

    Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34)
	    id 1BTMah-0004pp-KT
	    for emacs-devel@gnu.org; Thu, 27 May 2004 11:14:43 -0400
    Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34)
	    id 1BTJjj-00068U-HL
	    for emacs-devel@gnu.org; Thu, 27 May 2004 08:12:23 -0400

and the whopping 22 hours from the list back to email:

    Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	    by monty-python.gnu.org with esmtp (Exim 4.34)
	    id 1BThng-0007zS-R9
	    for eliz@gnu.org; Fri, 28 May 2004 09:53:32 -0400
    Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34)
	    id 1BTMah-0004pp-KT
	    for emacs-devel@gnu.org; Thu, 27 May 2004 11:14:43 -0400

Can someone on system-hackers please explain what is going on and why?

The full message follows:

Mail-from: From emacs-devel-bounces+eliz=gnu.org@gnu.org Fri May 28 17:58:29 2004
Return-path: <emacs-devel-bounces+eliz=gnu.org@gnu.org>
Envelope-to: eliz@gnu.org
Delivery-date: Fri, 28 May 2004 17:58:29 -0400
Received: from monty-python.gnu.org ([199.232.76.173])
	by fencepost.gnu.org with esmtp (Exim 4.34)
	id 1BTpMz-0005PA-JX
	for eliz@gnu.org; Fri, 28 May 2004 17:58:29 -0400
Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	by monty-python.gnu.org with esmtp (Exim 4.34)
	id 1BThng-0007zS-R9
	for eliz@gnu.org; Fri, 28 May 2004 09:53:32 -0400
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34)
	id 1BTMah-0004pp-KT
	for emacs-devel@gnu.org; Thu, 27 May 2004 11:14:43 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34)
	id 1BTJjj-00068U-HL
	for emacs-devel@gnu.org; Thu, 27 May 2004 08:12:23 -0400
Received: from [192.114.186.23] (helo=aragorn.inter.net.il)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1BTJji-000685-LA
	for emacs-devel@gnu.org; Thu, 27 May 2004 08:11:51 -0400
Received: from zaretski (pns03-196-231.inter.net.il [80.230.196.231])
	by aragorn.inter.net.il (MOS 3.4.6-GR) with ESMTP id CYN22387;
	Thu, 27 May 2004 15:04:51 +0300 (IDT)
Date: Thu, 27 May 2004 15:02:59 +0200
From: "Eli Zaretskii" <eliz@gnu.org>
To: storm@cua.dk (Kim F. Storm)
Message-Id: <4038-Thu27May2004150259+0300-eliz@gnu.org>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <m3y8neutsp.fsf@kfs-l.imdomain.dk> (storm@cua.dk)
References: <m3iseihohi.fsf@kfs-l.imdomain.dk>
	<8296-Thu27May2004095925+0300-eliz@gnu.org>
	<m3y8neutsp.fsf@kfs-l.imdomain.dk>
Cc: emacs-devel@gnu.org
Subject: Re: Improving emacs process performance (for free?)
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Eli Zaretskii <eliz@gnu.org>
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Sender: emacs-devel-bounces+eliz=gnu.org@gnu.org
Errors-To: emacs-devel-bounces+eliz=gnu.org@gnu.org

> From: storm@cua.dk (Kim F. Storm)
> Date: 27 May 2004 11:02:30 +0200
> 
> So a minimum stack usage would be 3*10+16 = 46KB + what's allocated
> elsewhere.  Pretty close to 64K if you ask me :-|

Do we have some system supported by Emacs where the stack is merely a
64KB?  I think Emacs cannot run on such systems anyway; in the old
days when DJGPP (used to produce the DOS port) had a 256KB limit on
the stack, the Emacs binary was produced specially to have twice that
much, i.e. 512KB, because 256KB were not enough.

I think 512KB used by the DOS port is the smallest amount of stack we
have on any supported platform.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: follow mode for occur

[Dan Nicolaescu]

Here is a new incarnation of this code. It is a minor mode now. 
It works with very well occur, compile, grep and diff-mode. 
It is _not_ turned on by default.

Now there's the question of defaults. 

Should this mode be on by default? 
IMVHO it would be nice to have it on by default at least in  occur-mode
and diff-mode. 

How should it be turned on? Using a menu entry? 

Feedback would be appreciated. 

;;; Internal variable for `next-error-minor-mode-post-command-hook'.
(defvar next-error-follow-last-line nil)

;;;###autoload
(define-minor-mode next-error-follow-minor-mode
  "Minor mode for compilation, occur and diff modes.
When turned on cursor motion in the compilation, occur or diff
buffer determines the cursor in the corresponding buffer to move
to the corresponding position .  " 
  nil " Fol" nil
  (if (not next-error-follow-minor-mode)
      (remove-hook 'post-command-hook 'next-error-minor-mode-post-command-hook t)
    (add-hook 'post-command-hook 'next-error-minor-mode-post-command-hook nil t)
    (make-variable-buffer-local 'next-error-follow-last-line) 
    ))

;;; Used as a post-command-hook for the *Compilation* *grep* 
;;; and *Occur* buffers.
(defun next-error-minor-mode-post-command-hook ()
  (unless (equal next-error-follow-last-line (line-number-at-pos))
    (setq next-error-follow-last-line (line-number-at-pos))
    (condition-case nil
	(let ((compilation-context-lines nil))
	  (setq compilation-current-error (point))
	  (next-error-no-select 0))
      (error t))))

(defun toggle-next-error-follow-mode ()
  (interactive)
  (next-error-follow-minor-mode (not next-error-follow-minor-mode)))

;;; All this stuff will be put in the corresponding files: compile.el
;;; grep.el diff-mode.el and simple.el

;;; FIXME: Should there be a menu entry for the toggle? 
(eval-after-load "compile"
  '(define-key compilation-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode))

(eval-after-load "grep"
  '(define-key grep-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode))


(eval-after-load "diff-mode"
  '(define-key diff-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode))


(define-key occur-mode-map "\C-c\C-f" 'toggle-next-error-follow-mode)

Re: follow mode for occur

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Here is a new incarnation of this code. It is a minor mode now. 
> It works with very well occur, compile, grep and diff-mode. 
> It is _not_ turned on by default.
> 
> Now there's the question of defaults. 
> 
> Should this mode be on by default? 
> IMVHO it would be nice to have it on by default at least in  occur-mode
> and diff-mode. 
> 
> How should it be turned on? Using a menu entry?

What's wrong with the key ?f ?  It would appear that most of those
modes don't have a useful binding for it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: follow mode for occur

[Robert J. Chassell]

Today's CVS snapshot, Sat, 2004 Jun  5  10:53 UTC
GNU Emacs 21.3.50.41 (i686-pc-linux-gnu, GTK+ Version 2.2.4)

I just tried Dan Nicolaescu's new follow minor mode for occur.  In a
short test, it works fine for both *Occur* and *compilation* buffers.

    Should this mode be on by default? 

I think so.  I really like this.  I don't know how non-programmers who
first use Emacs will respond, but I think they will like it, too.

I suppose a menu entry is a good idea, too.  I don't use the menus so
my only thought about them is that we should make sure they have good
human factors.  

Presumably occur and its follow mode fit into `Tools' along with grep
and multi-occur.  Or perhaps a human factors analysis will put them
into `Edit' along with isearch.  On thinking more about this, I think
they should all go into `Edit'.

Perhaps the listing could add `Search and List' between the existing 
`Search' and `Replace' entries, like this:


    Search            ->
    Search and List   ->
    Replace           ->

After all, these capabilities are all various forms of navigation
used in editing:

  * search and list within a single `file' (that is how many people
    think of buffers) for occur and occur follow mode

  * search and list within the buffers you have visited for
    multi-occur

  * search and list within a set of files for grep

By the way, it looks to me that isearch should come before string
search in the `Edit -> Search' menu.  It is easy to learn isearch and
easy to switch from string search to isearch if you already know
string search.  So the better interface should come first.  Put
`string search' in a sub-sub-menu.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com