* follow mode for occur @ 2004-05-27 0:35 Dan Nicolaescu 2004-05-27 15:16 ` Sun Yi Ming ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Dan Nicolaescu @ 2004-05-27 0:35 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-05-27 0:35 follow mode for occur Dan Nicolaescu @ 2004-05-27 15:16 ` Sun Yi Ming 2004-05-27 16:48 ` Dan Nicolaescu 2004-05-28 8:47 ` Juri Linkov 2004-05-28 12:44 ` Stephen Eglen 2 siblings, 1 reply; 12+ messages in thread From: Sun Yi Ming @ 2004-05-27 15:16 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-05-27 15:16 ` Sun Yi Ming @ 2004-05-27 16:48 ` Dan Nicolaescu 2004-05-28 8:43 ` Emacs-devel list IS slow [was Re: follow mode for occur] Kim F. Storm 2004-05-28 10:37 ` follow mode for occur Sun Yi Ming 0 siblings, 2 replies; 12+ messages in thread From: Dan Nicolaescu @ 2004-05-27 16:48 UTC (permalink / raw) Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Emacs-devel list IS slow [was Re: follow mode for occur] 2004-05-27 16:48 ` Dan Nicolaescu @ 2004-05-28 8:43 ` Kim F. Storm 2004-05-29 14:16 ` Eli Zaretskii 2004-05-28 10:37 ` follow mode for occur Sun Yi Ming 1 sibling, 1 reply; 12+ messages in thread From: Kim F. Storm @ 2004-05-28 8:43 UTC (permalink / raw) Cc: Sun Yi Ming, emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs-devel list IS slow [was Re: follow mode for occur] 2004-05-28 8:43 ` Emacs-devel list IS slow [was Re: follow mode for occur] Kim F. Storm @ 2004-05-29 14:16 ` Eli Zaretskii 0 siblings, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2004-05-29 14:16 UTC (permalink / raw) Cc: system-hackers, dann, emacs-devel > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-05-27 16:48 ` Dan Nicolaescu 2004-05-28 8:43 ` Emacs-devel list IS slow [was Re: follow mode for occur] Kim F. Storm @ 2004-05-28 10:37 ` Sun Yi Ming 1 sibling, 0 replies; 12+ messages in thread From: Sun Yi Ming @ 2004-05-28 10:37 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-05-27 0:35 follow mode for occur Dan Nicolaescu 2004-05-27 15:16 ` Sun Yi Ming @ 2004-05-28 8:47 ` Juri Linkov 2004-05-28 18:56 ` Dan Nicolaescu 2004-05-28 12:44 ` Stephen Eglen 2 siblings, 1 reply; 12+ messages in thread From: Juri Linkov @ 2004-05-28 8:47 UTC (permalink / raw) Cc: emacs-devel 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-05-28 8:47 ` Juri Linkov @ 2004-05-28 18:56 ` Dan Nicolaescu 2004-06-04 18:41 ` Dan Nicolaescu 0 siblings, 1 reply; 12+ messages in thread From: Dan Nicolaescu @ 2004-05-28 18:56 UTC (permalink / raw) Cc: emacs-devel 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-05-28 18:56 ` Dan Nicolaescu @ 2004-06-04 18:41 ` Dan Nicolaescu 2004-06-04 19:18 ` David Kastrup 2004-06-05 11:56 ` Robert J. Chassell 0 siblings, 2 replies; 12+ messages in thread From: Dan Nicolaescu @ 2004-06-04 18:41 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-06-04 18:41 ` Dan Nicolaescu @ 2004-06-04 19:18 ` David Kastrup 2004-06-05 11:56 ` Robert J. Chassell 1 sibling, 0 replies; 12+ messages in thread From: David Kastrup @ 2004-06-04 19:18 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: follow mode for occur 2004-06-04 18:41 ` Dan Nicolaescu 2004-06-04 19:18 ` David Kastrup @ 2004-06-05 11:56 ` Robert J. Chassell 1 sibling, 0 replies; 12+ messages in thread From: Robert J. Chassell @ 2004-06-05 11:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* follow mode for occur 2004-05-27 0:35 follow mode for occur Dan Nicolaescu 2004-05-27 15:16 ` Sun Yi Ming 2004-05-28 8:47 ` Juri Linkov @ 2004-05-28 12:44 ` Stephen Eglen 2 siblings, 0 replies; 12+ messages in thread From: Stephen Eglen @ 2004-05-28 12:44 UTC (permalink / raw) Cc: emacs-devel > 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! ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-06-05 11:56 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-05-27 0:35 follow mode for occur Dan Nicolaescu 2004-05-27 15:16 ` Sun Yi Ming 2004-05-27 16:48 ` Dan Nicolaescu 2004-05-28 8:43 ` Emacs-devel list IS slow [was Re: follow mode for occur] Kim F. Storm 2004-05-29 14:16 ` Eli Zaretskii 2004-05-28 10:37 ` follow mode for occur Sun Yi Ming 2004-05-28 8:47 ` Juri Linkov 2004-05-28 18:56 ` Dan Nicolaescu 2004-06-04 18:41 ` Dan Nicolaescu 2004-06-04 19:18 ` David Kastrup 2004-06-05 11:56 ` Robert J. Chassell 2004-05-28 12:44 ` Stephen Eglen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.