isearch multiple buffers

isearch multiple buffers

[Juri Linkov]

Below is a patch that implements a feature allowing isearch to search
multiple files/buffers.  I wrote documentation strings and comments
in every new function, so for details please look there.

This general feature is implemented in isearch.el and can be used by other
packages.  add-log.el is the first package that uses it, and below is also
a patch for add-log.el that allows C-s to search through a set of all
ChangeLog files in one directory:

Index: lisp/add-log.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/add-log.el,v
retrieving revision 1.196
diff -c -r1.196 add-log.el
*** lisp/add-log.el	20 Sep 2007 14:06:13 -0000	1.196
--- lisp/add-log.el	6 Oct 2007 19:43:40 -0000
***************
*** 760,766 ****
         'change-log-resolve-conflict)
    (set (make-local-variable 'adaptive-fill-regexp) "\\s *")
    (set (make-local-variable 'font-lock-defaults)
!        '(change-log-font-lock-keywords t nil nil backward-paragraph)))
  
  ;; It might be nice to have a general feature to replace this.  The idea I
  ;; have is a variable giving a regexp matching text which should not be
--- 760,792 ----
         'change-log-resolve-conflict)
    (set (make-local-variable 'adaptive-fill-regexp) "\\s *")
    (set (make-local-variable 'font-lock-defaults)
!        '(change-log-font-lock-keywords t nil nil backward-paragraph))
!   (add-hook 'isearch-mode-hook 'isearch-buffers-init nil t)
!   (set (make-local-variable 'isearch-search-fun-function)
!        'isearch-buffers-search-fun)
!   (set (make-local-variable 'isearch-wrap-function)
!        'isearch-buffers-wrap)
!   (set (make-local-variable 'isearch-push-state-function)
!        'isearch-buffers-push-state)
!   (set (make-local-variable 'isearch-buffers-next-buffer-function)
!        'change-log-isearch-next-buffer))
! 
! (defun change-log-isearch-next-buffer (&optional buffer wrap)
!   "Return the next buffer for multiple buffers isearch.
! A sequence of buffers is formed by ChangeLog files with decreasing
! numeric file name suffixes in the directory of the initial ChangeLog
! file were isearch was started."
!   (let* ((name (change-log-name))
! 	 (files (cons name (sort (file-expand-wildcards (concat name "[-.][0-9]*"))
! 				 (lambda (a b)
! 				   (version< (substring b (length name))
! 					     (substring a (length name)))))))
! 	 (files (if isearch-forward files (reverse files))))
!     (find-file-noselect
!      (if wrap
! 	 (car files)
!        (cadr (member (file-name-nondirectory (buffer-file-name buffer))
! 		     files))))))
  
  ;; It might be nice to have a general feature to replace this.  The idea I
  ;; have is a variable giving a regexp matching text which should not be

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.303
diff -c -r1.303 isearch.el
*** lisp/isearch.el	29 Aug 2007 05:28:05 -0000	1.303
--- lisp/isearch.el	6 Oct 2007 19:48:51 -0000
***************
*** 2035,2042 ****
  			   (if isearch-forward (< pos2 pos1) (> pos2 pos1))))
  	      (setq pos1 pos2)
  	      (set-match-data match-data)))))
!     (if pos1
! 	(goto-char pos1))
      pos1))
  
  (defun isearch-search ()
--- 2035,2046 ----
  			   (if isearch-forward (< pos2 pos1) (> pos2 pos1))))
  	      (setq pos1 pos2)
  	      (set-match-data match-data)))))
!     (when pos1
!       ;; When using multiple buffers isearch, switch to the new buffer here,
!       ;; because `save-excursion' above doesn't allow doing it inside funcall.
!       (if isearch-buffers-current-buffer
! 	  (switch-to-buffer isearch-buffers-current-buffer))
!       (goto-char pos1))
      pos1))
  
  (defun isearch-search ()
***************
*** 2243,2248 ****
--- 2247,2344 ----
  	      (setq isearch-hidden t)))))))
  
  \f
+ ;; Search multiple buffers
+ 
+ (defvar isearch-buffers-current-buffer nil
+   "The buffer where the search currently stays.
+ The value is nil when the search still is in the initial buffer.")
+ 
+ (defvar isearch-buffers-next-buffer-function nil
+   "Function to call to get the next buffer to search.
+ The first argument of this function is the CURRENT-BUFFER that defined
+ the base buffer relative to which to find the next buffer.  When the
+ isearch direction is backward (when isearch-forward is nil), this
+ function should return the previous buffer.
+ 
+ If the second argument of this function WRAP is non-nil, then it
+ should return the first buffer in a buffer sequence; and for the
+ backward search, it should return the last buffer in a sequence.")
+ 
+ (defun isearch-buffers-init ()
+   "Set up isearch to search multiple buffers.
+ Intended to be added to `isearch-mode-hook'."
+   (setq isearch-buffers-current-buffer nil))
+ 
+ (defun isearch-buffers-search-fun ()
+   "Return the proper search function, for isearch in multiple buffers."
+   (lambda (string bound noerror)
+     (let ((search-fun
+ 	   ;; Use standard functions to search within one buffer
+ 	   (cond
+ 	    (isearch-word
+ 	     (if isearch-forward 'word-search-forward 'word-search-backward))
+ 	    (isearch-regexp
+ 	     (if isearch-forward 're-search-forward 're-search-backward))
+ 	    (t
+ 	     (if isearch-forward 'search-forward 'search-backward))))
+ 	  found buffer)
+       (or
+        ;; 1. First try searching in the initial buffer
+        (funcall search-fun string bound noerror)
+        ;; 2. If the above search fails, start visiting next/prev buffers
+        ;; successively, and search the string in them.  Do this only
+        ;; when bound is nil (i.e. not while lazy-highlighting search
+        ;; strings in the current buffer).
+        (unless bound
+ 	 (if isearch-buffers-current-buffer
+ 	     (condition-case nil
+ 		 (progn
+ 		   (while (not found)
+ 		     (setq buffer (funcall isearch-buffers-next-buffer-function buffer))
+ 		     (with-current-buffer buffer
+ 		       (goto-char (if isearch-forward (point-min) (point-max)))
+ 		       (setq isearch-barrier (point) isearch-opoint (point))
+ 		       ;; After visiting the next/prev buffer search the
+ 		       ;; string in them again, until the function in
+ 		       ;; isearch-buffers-next-buffer-function raises an error
+ 		       ;; at the beginning/end of the buffer list.
+ 		       (setq found (funcall search-fun string bound noerror))))
+ 		   (if buffer (setq isearch-buffers-current-buffer buffer))
+ 		   ;; Return point of the new search result
+ 		   found)
+ 	       ;; Return nil when isearch-buffers-next-buffer-function fails
+ 	       (error nil))
+ 	   (signal 'search-failed (list string "initial buffer"))))))))
+ 
+ (defun isearch-buffers-wrap ()
+   "Wrap the multiple buffers search when search is failed.
+ Switch buffer to the first buffer for a forward search,
+ or to the last buffer for a backward search.
+ Set `isearch-buffers-current-buffer' to the current buffer to display
+ the isearch suffix message [initial buffer] only when isearch leaves
+ the initial buffer."
+   (if isearch-buffers-current-buffer
+       (progn
+ 	(switch-to-buffer
+ 	 (funcall isearch-buffers-next-buffer-function (current-buffer) t))
+ 	(goto-char (if isearch-forward (point-min) (point-max))))
+     (setq isearch-buffers-current-buffer (current-buffer))
+     (setq isearch-wrapped nil)))
+ 
+ (defun isearch-buffers-push-state ()
+   "Save a function restoring the state of multiple buffers search.
+ Save the current buffer to the additional state parameter in the
+ search status stack."
+   `(lambda (cmd)
+      (isearch-buffers-pop-state cmd ,(current-buffer))))
+ 
+ (defun isearch-buffers-pop-state (cmd buffer)
+   "Restore the multiple buffers search state.
+ Switch to the buffer restored from the search status stack."
+   (unless (equal buffer (current-buffer))
+     (switch-to-buffer (setq isearch-buffers-current-buffer buffer))))
+ 
+ \f
  ;; General utilities
  
  (defun isearch-no-upper-case-p (string regexp-flag)

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

Re: isearch multiple buffers

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > Below is a patch that implements a feature allowing isearch to search
  > multiple files/buffers.  I wrote documentation strings and comments
  > in every new function, so for details please look there.
  > 
  > This general feature is implemented in isearch.el and can be used by other
  > packages.  add-log.el is the first package that uses it, and below is also
  > a patch for add-log.el that allows C-s to search through a set of all
  > ChangeLog files in one directory:

This is great, thanks for doing this!

Re: isearch multiple buffers

[Richard Stallman]

I am not sure I understand the code in that patch, but it looks like
isearch-buffers-search-fun will search all the buffers without a
pause.  Is that right?

I don't think that is the right UI for this feature.  I think the
search should fail when it can't find another occurrence in the
current buffer.  Then if you type C-s again it should go to the next
buffer which has an occurrence, and search there.

The documentation of `isearch-buffers-next-buffer-function' should
clearly state what it means to search multiple buffers.

    +   "The buffer where the search currently stays.

The word "stays" is not used in this way in English.

Re: isearch multiple buffers

[Juri Linkov]

> I am not sure I understand the code in that patch, but it looks like
> isearch-buffers-search-fun will search all the buffers without a
> pause.  Is that right?
>
> I don't think that is the right UI for this feature.  I think the
> search should fail when it can't find another occurrence in the
> current buffer.  Then if you type C-s again it should go to the next
> buffer which has an occurrence, and search there.

The patch I proposed implements exactly the same behavior as
you described.

> The documentation of `isearch-buffers-next-buffer-function' should
> clearly state what it means to search multiple buffers.

(defvar isearch-buffers-next-buffer-function nil
  "Function to call to get the next buffer to search.

When this variable is set to a function that returns a buffer, then
after typing another C-s or C-r at a failing search, the search goes
to the next buffer in the series and continues searching for the next
occurrence.  The first argument of this function is the current buffer
where the search is currently searching.  It defines the base buffer
relative to which this function should find the next buffer.  When the
isearch direction is backward (when isearch-forward is nil), this
function should return the previous buffer to search. If the second
argument of this function WRAP is non-nil, then it should return
the first buffer in the series; and for the backward search, it
should return the last buffer in the series.")

>     +   "The buffer where the search currently stays.
>
> The word "stays" is not used in this way in English.

(defvar isearch-buffers-current-buffer nil
  "The buffer where the search is currently searching.
The value is nil when the search still is in the initial buffer.")

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

Re: isearch multiple buffers

[Eric Hanchrow]

>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:

    >> I don't think that is the right UI for this feature.  I think
    >> the search should fail when it can't find another occurrence in
    >> the current buffer.  Then if you type C-s again it should go to
    >> the next buffer which has an occurrence, and search there.

    Juri> The patch I proposed implements exactly the same behavior as
    Juri> you described.

Good -- in other words, it works just the way isearch works in info?

Re: isearch multiple buffers

[Juri Linkov]

>     >> I don't think that is the right UI for this feature.  I think
>     >> the search should fail when it can't find another occurrence in
>     >> the current buffer.  Then if you type C-s again it should go to
>     >> the next buffer which has an occurrence, and search there.
>
>     Juri> The patch I proposed implements exactly the same behavior as
>     Juri> you described.
>
> Good -- in other words, it works just the way isearch works in info?

Yes, I understood that this is what Richard wants.

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

Re: isearch multiple buffers

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

>>     >> I don't think that is the right UI for this feature.  I think
>>     >> the search should fail when it can't find another occurrence in
>>     >> the current buffer.  Then if you type C-s again it should go to
>>     >> the next buffer which has an occurrence, and search there.
>>
>>     Juri> The patch I proposed implements exactly the same behavior as
>>     Juri> you described.
>>
>> Good -- in other words, it works just the way isearch works in info?
>
> Yes, I understood that this is what Richard wants.

Maybe. Isearch in info complains when it reaches the end of the node
where the search started, but moves through the following nodes without
stopping.

I think perhaps Richard wants the search to pause at the end of every
buffer.

-- 
Johan Bockgård

Re: isearch multiple buffers

[Juri Linkov]

>>> Good -- in other words, it works just the way isearch works in info?
>>
>> Yes, I understood that this is what Richard wants.
>
> Maybe. Isearch in info complains when it reaches the end of the node
> where the search started, but moves through the following nodes without
> stopping.
>
> I think perhaps Richard wants the search to pause at the end of every
> buffer.

This would be a hassle.  When you want to search 12 ChangeLog files you
need additional 12 C-s key presses.  Even an additional C-s at a failing
search in the initial buffer where the search started is inconvenient
when you want to leave the first buffer without stopping.  But this is
necessary for users who are not aware that isearch will continue searching
in next buffers.

Perhaps, we should add a new user option with 3 possible values:
1. don't stop in the initial buffer
2. stop once in the initial buffer
3. stop in every next buffer

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

Re: isearch multiple buffers

[Stefan Monnier]

> Perhaps, we should add a new user option with 3 possible values:
> 1. don't stop in the initial buffer
> 2. stop once in the initial buffer
> 3. stop in every next buffer

I think the two behaviors are quite different conceptually: if we switch to
another buffer without requiring an additional C-s, we're giving the
illusion that all the files are really just a single file, whereas otherwise
we're just making it easier to search through several files.

Both are attractive.  The first option is pretty powerful: you can use it as
an alternative to C-x b (e.g. if you set
isearch-buffers-next-buffer-function to cycle through all the files in your
project, for example).


        Stefan

Re: isearch multiple buffers

[Juri Linkov]

>> Perhaps, we should add a new user option with 3 possible values:
>> 1. don't stop in the initial buffer
>> 2. stop once in the initial buffer
>> 3. stop in every next buffer
>
> I think the two behaviors are quite different conceptually: if we switch to
> another buffer without requiring an additional C-s, we're giving the
> illusion that all the files are really just a single file, whereas otherwise
> we're just making it easier to search through several files.

Making the multi-buffer search space continuous is more preferable when
the goal is to find the string no matter in what buffer it is located.

> Both are attractive.  The first option is pretty powerful: you can use it as
> an alternative to C-x b (e.g. if you set
> isearch-buffers-next-buffer-function to cycle through all the files in your
> project, for example).

Hmm, I did not think of this feature as a way of switching buffers.
This is an interesting POV: switching by content instead of buffer names.

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

Re: isearch multiple buffers

[Richard Stallman]

    > Maybe. Isearch in info complains when it reaches the end of the node
    > where the search started, but moves through the following nodes without
    > stopping.
    >
    > I think perhaps Richard wants the search to pause at the end of every
    > buffer.

I think it should pause at the end of each buffer
in which point was displayed during the search.
This includes the starting buffer, and each
buffer in which an occurrence is found.

However, if search scans a whole buffer (which was not the first) and
finds nothing, it should move on silently to the next buffer.

In other words, once search redisplays with point
in a certain buffer, you should have to type C-s to move
on from there.

    Perhaps, we should add a new user option with 3 possible values:
    1. don't stop in the initial buffer
    2. stop once in the initial buffer
    3. stop in every next buffer

I don't mind having some of those as optional behaviors, but the
default I've described above is none of those three.

Re: isearch multiple buffers

[Juri Linkov]

> I think it should pause at the end of each buffer
> in which point was displayed during the search.
> This includes the starting buffer, and each
> buffer in which an occurrence is found.
>
> However, if search scans a whole buffer (which was not the first) and
> finds nothing, it should move on silently to the next buffer.
>
> In other words, once search redisplays with point
> in a certain buffer, you should have to type C-s to move
> on from there.
>
>     Perhaps, we should add a new user option with 3 possible values:
>     1. don't stop in the initial buffer
>     2. stop once in the initial buffer
>     3. stop in every next buffer
>
> I don't mind having some of those as optional behaviors, but the
> default I've described above is none of those three.

Actually, under the 3-rd variant I meant the same variant as you
described, i.e.

  3. stop in every buffer which contains the search string
     (and always stop in the first buffer)

So there are three useful options (and let's try using the 3-rd as the
default).

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

Re: isearch multiple buffers

[Johan Bockgård]

Juri Linkov <juri@jurta.org> writes:

> Actually, under the 3-rd variant I meant the same variant as you
> described, i.e.

As did I, FWIW.

>   3. stop in every buffer which contains the search string

-- 
Johan Bockgård

Re: isearch multiple buffers

[Richard Stallman]

    >     Perhaps, we should add a new user option with 3 possible values:
    >     1. don't stop in the initial buffer
    >     2. stop once in the initial buffer
    >     3. stop in every next buffer
    >
    > I don't mind having some of those as optional behaviors, but the
    > default I've described above is none of those three.

    Actually, under the 3-rd variant I meant the same variant as you
    described, i.e.

      3. stop in every buffer which contains the search string
	 (and always stop in the first buffer)

    So there are three useful options (and let's try using the 3-rd as the
    default).

If you want to implement all three, please do.

Re: isearch multiple buffers

[Stefan Monnier]

> If you want to implement all three, please do.

We may as well start with just the right default and later when-and-if the
need for more flexibility comes up we can add it (at which point we may
know better how and when to provide the choice: a global setting may very
well not be the right thing to do).


        Stefan

Re: isearch multiple buffers

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 5194 bytes --]

>     >     Perhaps, we should add a new user option with 3 possible values:
>     >     1. don't stop in the initial buffer
>     >     2. stop once in the initial buffer
>       3. stop in every buffer which contains the search string
> 	 (and always stop in the first buffer)
>
>     So there are three useful options (and let's try using the 3-rd as the
>     default).
>
> If you want to implement all three, please do.

I implemented a new user option isearch-buffers-pause with these
three values, with the default to pause in every buffer that contains
the search string.

Also I implemented a new minor mode isearch-buffers-minor-mode
that sets a group of variables necessary for this feature.
Turning off this minor mode deletes all created buffer-local bindings.
So any major mode that uses this feature can simply set the variable
isearch-buffers-next-buffer-function and call isearch-buffers-minor-mode.

The code implementing this feature has so many lines now that I think it
needs a separate file.  One possible name would be isearchb.el, but this
name is already occupied by another package.  So I think a good name will
be isearch-et.el (isearch everything :-) as I plan to add more isearch
extensions to this new file.

Below are two NEWS entries, a patch for the first package add-log.el
that uses this feature, a small patch for isearch.el, and a new file
isearch-et.el:

** The package isearch-et.el has been added.  It implements a new mode
`isearch-buffers-minor-mode' that allows isearch to search through
multiple buffers.  In this mode a new variable
`isearch-buffers-next-buffer-function' defines the function to call to get
the next buffer to search in the series of multiple buffers.

** isearch can now search through multiple ChangeLog files.
When running isearch in a ChangeLog file, if the search fails,
then another C-s tries searching the previous ChangeLog,
if there is one (e.g. go from ChangeLog to ChangeLog.12).

Index: lisp/add-log.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/add-log.el,v
retrieving revision 1.197
diff -c -r1.197 add-log.el
*** lisp/add-log.el	10 Oct 2007 18:52:44 -0000	1.197
--- lisp/add-log.el	20 Oct 2007 00:00:55 -0000
***************
*** 760,766 ****
         'change-log-resolve-conflict)
    (set (make-local-variable 'adaptive-fill-regexp) "\\s *")
    (set (make-local-variable 'font-lock-defaults)
!        '(change-log-font-lock-keywords t nil nil backward-paragraph)))
  
  ;; It might be nice to have a general feature to replace this.  The idea I
  ;; have is a variable giving a regexp matching text which should not be
--- 760,788 ----
         'change-log-resolve-conflict)
    (set (make-local-variable 'adaptive-fill-regexp) "\\s *")
    (set (make-local-variable 'font-lock-defaults)
!        '(change-log-font-lock-keywords t nil nil backward-paragraph))
!   (set (make-local-variable 'isearch-buffers-next-buffer-function)
!        'change-log-next-buffer)
!   (isearch-buffers-minor-mode))
! 
! (defun change-log-next-buffer (&optional buffer wrap)
!   "Return the next buffer in the series of ChangeLog file buffers.
! This function is used for multiple buffers isearch.
! A sequence of buffers is formed by ChangeLog files with decreasing
! numeric file name suffixes in the directory of the initial ChangeLog
! file were isearch was started."
!   (let* ((name (change-log-name))
! 	 (files (cons name (sort (file-expand-wildcards
! 				  (concat name "[-.][0-9]*"))
! 				 (lambda (a b)
! 				   (version< (substring b (length name))
! 					     (substring a (length name)))))))
! 	 (files (if isearch-forward files (reverse files))))
!     (find-file-noselect
!      (if wrap
! 	 (car files)
!        (cadr (member (file-name-nondirectory (buffer-file-name buffer))
! 		     files))))))
  
  ;; It might be nice to have a general feature to replace this.  The idea I
  ;; have is a variable giving a regexp matching text which should not be

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.303
diff -c -r1.303 isearch.el
*** lisp/isearch.el	29 Aug 2007 05:28:05 -0000	1.303
--- lisp/isearch.el	20 Oct 2007 00:02:31 -0000
***************
*** 2035,2042 ****
  			   (if isearch-forward (< pos2 pos1) (> pos2 pos1))))
  	      (setq pos1 pos2)
  	      (set-match-data match-data)))))
!     (if pos1
! 	(goto-char pos1))
      pos1))
  
  (defun isearch-search ()
--- 2045,2059 ----
  			   (if isearch-forward (< pos2 pos1) (> pos2 pos1))))
  	      (setq pos1 pos2)
  	      (set-match-data match-data)))))
!     (when pos1
!       ;; When using multiple buffers isearch, switch to the new buffer here,
!       ;; because `save-excursion' above doesn't allow doing it inside funcall.
!       (if (and (boundp 'isearch-buffers-next-buffer-function)
! 	       isearch-buffers-next-buffer-function
! 	       (boundp 'isearch-buffers-current-buffer)
! 	       (buffer-live-p isearch-buffers-current-buffer))
! 	  (switch-to-buffer isearch-buffers-current-buffer))
!       (goto-char pos1))
      pos1))
  
  (defun isearch-search ()


[-- Attachment #2: isearch-et.el --]
[-- Type: application/emacs-lisp, Size: 7445 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


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

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

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

Re: isearch multiple buffers

[Richard Stallman]

isearch-multi.el seems like a better name for the new file.

    Also I implemented a new minor mode isearch-buffers-minor-mode
    that sets a group of variables necessary for this feature.
    Turning off this minor mode deletes all created buffer-local bindings.
    So any major mode that uses this feature can simply set the variable
    isearch-buffers-next-buffer-function and call isearch-buffers-minor-mode.

To make this a minor mode is undesirable because we do not want users
to enable and disable it.  I think it should simply be a subroution
for that major modes can call.

    !       (if (and (boundp 'isearch-buffers-next-buffer-function)
    ! 	       isearch-buffers-next-buffer-function
    ! 	       (boundp 'isearch-buffers-current-buffer)

Why test boundp of these variables.  Isn't it better to have them
always always bound, and just test for non-nil?

Re: isearch multiple buffers

[Juri Linkov]

> isearch-multi.el seems like a better name for the new file.

This name is too long.  What about isearch-x.el?  It has two
meanings: "x" means "isearch extra extensions", and "x" means
"cross-file, cross-buffer search".

However, isearch-x.el causes name conflicts with international/isearch-x.el.
So alternative short names are isearchx.el or xisearch.el.

>     Also I implemented a new minor mode isearch-buffers-minor-mode
>     that sets a group of variables necessary for this feature.
>     Turning off this minor mode deletes all created buffer-local bindings.
>     So any major mode that uses this feature can simply set the variable
>     isearch-buffers-next-buffer-function and call isearch-buffers-minor-mode.
>
> To make this a minor mode is undesirable because we do not want users
> to enable and disable it.  I think it should simply be a subroution
> for that major modes can call.

It is likely that there are some users who won't like this feature.
I think we shouldn't make it hard to disable.

Also this minor mode could provide an indication in the mode line
(e.g. "X" or "X-Isearch" to mean cross-buffer search), so when the
search goes to another file, it will not surprise users.

>     !       (if (and (boundp 'isearch-buffers-next-buffer-function)
>     ! 	       isearch-buffers-next-buffer-function
>     ! 	       (boundp 'isearch-buffers-current-buffer)
>
> Why test boundp of these variables.  Isn't it better to have them
> always always bound, and just test for non-nil?

OK, I will add the ###autoload cookie to their defvar in the source file.

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

Re: isearch multiple buffers

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> isearch-multi.el seems like a better name for the new file.
>
> This name is too long.  What about isearch-x.el?  It has two
> meanings: "x" means "isearch extra extensions", and "x" means
> "cross-file, cross-buffer search".

"isearch-multi" really isn't that long. and it's a great deal more clear than
something generic like isearch-x...

-Miles

-- 
`Life is a boundless sea of bitterness'

Re: isearch multiple buffers

[Lennart Borgman (gmail)]

Miles Bader wrote:
> Juri Linkov <juri@jurta.org> writes:
>>> isearch-multi.el seems like a better name for the new file.
>> This name is too long.  What about isearch-x.el?  It has two
>> meanings: "x" means "isearch extra extensions", and "x" means
>> "cross-file, cross-buffer search".
> 
> "isearch-multi" really isn't that long. and it's a great deal more clear than
> something generic like isearch-x...
> 
> -Miles

The cryptic system "Do no lOng nameS" might perhaps still be around? Or 
is it no longer supported?

Re: isearch multiple buffers

[Stefan Monnier]

> The cryptic system "Do no lOng nameS" might perhaps still be around?

No problem there on principle either: long names simply need to have unique
prefixes to avoid collisions, so long names per se are not a problem


        Stefan

Re: isearch multiple buffers

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The cryptic system "Do no lOng nameS" might perhaps still be around?
>
> No problem there on principle either: long names simply need to have unique
> prefixes to avoid collisions, so long names per se are not a problem

Are we going to stop supporting msdos 8.3 filenames already?!?

I seem to recall some muttering of doing so after the 22 release, and
even that was my imagination, well, we damn well should!

[I can't believe, in 2007, we're still supporting such idiocy...]

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: isearch multiple buffers

[Richard Stallman]

    Are we going to stop supporting msdos 8.3 filenames already?!?

Eli, is there any reason to continue making sure our file names
are unique when truncated to 8.3 form?

(This is not an immediate issue for isearch-multi.el,
since it would truncate to isearch-.el and we have no
other file which would get confused with that.)

Re: isearch multiple buffers

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Are we going to stop supporting msdos 8.3 filenames already?!?
>
> Eli, is there any reason to continue making sure our file names
> are unique when truncated to 8.3 form?
>
> (This is not an immediate issue for isearch-multi.el,
> since it would truncate to isearch-.el and we have no
> other file which would get confused with that.)

isearch-x.el

-- 
David Kastrup

Re: isearch multiple buffers

[Richard Stallman]

    > (This is not an immediate issue for isearch-multi.el,
    > since it would truncate to isearch-.el and we have no
    > other file which would get confused with that.)

    isearch-x.el

I didn't notice that conflict, since that file is in a different
directory, but I think you are right that it is a conflict.

So if Eli says the 8.3 truncation issue still matters, I guess we
should rename isearch-multi.el to isearchmulti.el.

Re: isearch multiple buffers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 23 Oct 2007 13:53:37 -0400
> Cc: eliz@gnu.org, emacs-devel@gnu.org, lennart.borgman@gmail.com,
> 	monnier@iro.umontreal.ca, miles@gnu.org
> 
>     > (This is not an immediate issue for isearch-multi.el,
>     > since it would truncate to isearch-.el and we have no
>     > other file which would get confused with that.)
> 
>     isearch-x.el
> 
> I didn't notice that conflict, since that file is in a different
> directory, but I think you are right that it is a conflict.

If the files are in different directories, that's not a conflict.

I just ran doschk on the current CVS, and it didn't report any 8+3
clashes.

Re: isearch multiple buffers

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> If the files are in different directories, that's not a conflict.

But they will still hide each other on the load-path.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: isearch multiple buffers

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Tue, 23 Oct 2007 23:44:28 +0200
> Cc: emacs-devel@gnu.org, lennart.borgman@gmail.com, rms@gnu.org,
> 	monnier@iro.umontreal.ca, miles@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the files are in different directories, that's not a conflict.
> 
> But they will still hide each other on the load-path.

Yes, you are right.

Btw, why is isearch-x.el a separate file?  It has only a few short
functions, and seems to be needed for anyone who uses an input
method.  Why not add it to isearch.el?

Re: isearch multiple buffers

[Richard Stallman]

    Btw, why is isearch-x.el a separate file?  It has only a few short
    functions, and seems to be needed for anyone who uses an input
    method.  Why not add it to isearch.el?

Maybe that would be ok now.  In the past we went to much greater
lengths to try to reduce the minimal size of Emacs, but that is
much less important nowadays.

Re: isearch multiple buffers

[Richard Stallman]

    > I didn't notice that conflict, since that file is in a different
    > directory, but I think you are right that it is a conflict.

    If the files are in different directories, that's not a conflict.

It is not a conflict that prevents the two files from both existing.
But what happens when someone tries to load "isearch-x.el"?
Won't that find "isearch-multi.el" because they both truncate
to "isearch-.el"?

Re: isearch multiple buffers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, lennart.borgman@gmail.com,
> 	emacs-devel@gnu.org
> Date: Tue, 23 Oct 2007 03:12:37 -0400
> 
>     Are we going to stop supporting msdos 8.3 filenames already?!?
> 
> Eli, is there any reason to continue making sure our file names
> are unique when truncated to 8.3 form?

I didn't yet decide firmly whether Emacs 23 will support MS-DOS.  It
depends on whether I will have time to fix the breakage due to
multi-tty and the upcoming Unicode mergers.

So, for now, I'd appreciate if we would try to avoid 8+3 problems if
we can avoid that.  For the record, there are no such conflicts in the
current CVS trunk.

Re: isearch multiple buffers

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> Eli, is there any reason to continue making sure our file names
>> are unique when truncated to 8.3 form?
>
> I didn't yet decide firmly whether Emacs 23 will support MS-DOS.  It
> depends on whether I will have time to fix the breakage due to
> multi-tty and the upcoming Unicode mergers.

The decision to keep or drop support for msdos 8.3 support should be
made based on whether we want to support it, not on whether it's
_possible_ to support it.

-Miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: isearch multiple buffers

[Stefan Monnier]

>>> Eli, is there any reason to continue making sure our file names
>>> are unique when truncated to 8.3 form?
>> 
>> I didn't yet decide firmly whether Emacs 23 will support MS-DOS.  It
>> depends on whether I will have time to fix the breakage due to
>> multi-tty and the upcoming Unicode mergers.

> The decision to keep or drop support for msdos 8.3 support should be
> made based on whether we want to support it, not on whether it's
> _possible_ to support it.

I for one would first wait until at least 1 user complains that the trunk
doesn't compile/work any more under MSDOS.


        Stefan

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org,
> 	  lennart.borgman@gmail.com
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 23 Oct 2007 20:52:57 -0400
> 
> I for one would first wait until at least 1 user complains that the trunk
> doesn't compile/work any more under MSDOS.

I already did.  It doesn't compile anymore.

Re: isearch multiple buffers

[Stefan Monnier]

>> I for one would first wait until at least 1 user complains that the trunk
>> doesn't compile/work any more under MSDOS.
> I already did.  It doesn't compile anymore.

Sorry, but I don't count you as a user.
Obviously I can't prevent you from working on the msdos port, but if no
other user complains it's probably a good indication that it shojuld stay
very much at the bottom of the todo list.

This said, if we(you) decide to drop support for it, we'll still want to
keep the menu-display code in the hope that someone someday will port it to
unix ttys.


        Stefan

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: miles@gnu.org,  rms@gnu.org,  emacs-devel@gnu.org,
> 	  lennart.borgman@gmail.com
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 24 Oct 2007 01:51:48 -0400
> 
> it should stay very much at the bottom of the todo list.

It's already there, as should be obvious from the ChangeLog entries
that bear my name.

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: rms@gnu.org,  emacs-devel@gnu.org,  lennart.borgman@gmail.com,
> 	  monnier@iro.umontreal.ca
> From: Miles Bader <miles@gnu.org>
> Date: Wed, 24 Oct 2007 08:33:56 +0900
> 
> The decision to keep or drop support for msdos 8.3 support should be
> made based on whether we want to support it, not on whether it's
> _possible_ to support it.

Who are ``we'', exactly?  Are ``we'' volunteering to invest the
necessary effort to make the support happen?

And if I'm the only one to volunteer, why should ``we'' bother?

Re: isearch multiple buffers

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> The decision to keep or drop support for msdos 8.3 support should be
>> made based on whether we want to support it, not on whether it's
>> _possible_ to support it.
>
> Who are ``we'', exactly?  Are ``we'' volunteering to invest the
> necessary effort to make the support happen?
>
> And if I'm the only one to volunteer, why should ``we'' bother?

Er, I was arguing for _dropping_ support for msdos, even if continuing
it proves possible.

Of course if continuing support proves _not_ possible (or rather, not
practical), then obviously that's that... :-)

-Miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: lennart.borgman@gmail.com, rms@gnu.org, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> From: Miles Bader <miles.bader@necel.com>
> Date: Wed, 24 Oct 2007 13:51:33 +0900
> 
> Er, I was arguing for _dropping_ support for msdos, even if continuing
> it proves possible.

But no one is supporting it except myself, for years.  This support
costs the rest of maintainers exactly zero effort.  So why should
someone except myself be bothered about it?

Re: isearch multiple buffers

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> Er, I was arguing for _dropping_ support for msdos, even if continuing
>> it proves possible.
>
> But no one is supporting it except myself, for years.  This support
> costs the rest of maintainers exactly zero effort.  So why should
> someone except myself be bothered about it?

Because the 8.3 name restriction has a negative effect for _all_
developers.

-Miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
> Date: Thu, 25 Oct 2007 08:55:20 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> Er, I was arguing for _dropping_ support for msdos, even if continuing
> >> it proves possible.
> >
> > But no one is supporting it except myself, for years.  This support
> > costs the rest of maintainers exactly zero effort.  So why should
> > someone except myself be bothered about it?
> 
> Because the 8.3 name restriction has a negative effect for _all_
> developers.

What negative effects? can you show them in the archives?  AFAIR, this
is about the first such issue in years.

Re: isearch multiple buffers

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> Because the 8.3 name restriction has a negative effect for _all_
>> developers.
>
> What negative effects? can you show them in the archives?  AFAIR, this
> is about the first such issue in years.

It's a periodic event.  Someone adds a file, then someone else says "hey
rename that, it conflicts in 8.3-space with mumble-mumble."  Usually the
new name is uglier.  No I'm not going to spend the time searching for
archive references.

It's not the worst burden in the world, but it's stupid.  I don't _want_
to pick substandard names for new files unless there's actually a
benefit to doing so, and in that case the "benefit" seems pretty
elusive.

Does _anybody_ use msdos Emacs?  I'm sure there are 2 or 3 remaining
machines that run msdos, but it seems a pretty good bet that they're
being used for industrial control in a factory somewhere, not for
running an up-to-date versions of emacs.  Even the most conservative
users have moved on to windows or some other system by now.  Are we
_ever_ going to drop support for this silly obsolete relic?  Does
anybody else still support msdos?

In the end it's a cost-benefit analysis.  Sure the cost of supporting
msdos is fairly small -- but the benefits seem far smaller.

-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: isearch multiple buffers

[Juri Linkov]

> Does _anybody_ use msdos Emacs?

Not that I am aware of.  Even small portable devices don't use msdos
nowadays.  The usual way to run msdos is in emulators, but this is
only for fun and nostalgia, not for practical needs.

> Are we _ever_ going to drop support for this silly obsolete relic?
> Does anybody else still support msdos?

Even microsoft has dropped support for msdos long ago.

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

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Miles Bader <miles.bader@necel.com>
> Date: Thu, 25 Oct 2007 15:21:27 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> Because the 8.3 name restriction has a negative effect for _all_
> >> developers.
> >
> > What negative effects? can you show them in the archives?  AFAIR, this
> > is about the first such issue in years.
> 
> It's a periodic event.

Yes, with a period that lately looks like 5 years, maybe more.

> Does _anybody_ use msdos Emacs?

I don't know, maybe not.

> Even the most conservative
> users have moved on to windows or some other system by now.

The MSDOS port runs on Windows just fine.

> Are we _ever_ going to drop support for this silly obsolete relic?

I still don't understand why ``we'' (or should I say ``you''?) care.

> Does anybody else still support msdos?

Quite a few of GNU utilities do, see

  ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/

(do a "ls -ltr" to see when the latest ports were uploaded).

> In the end it's a cost-benefit analysis.  Sure the cost of supporting
> msdos is fairly small -- but the benefits seem far smaller.

When the cost is strictly zero, the benefits shouldn't matter, IMO.

Re: isearch multiple buffers

[Robert J. Chassell]

   > Because the 8.3 name restriction has a negative effect for _all_
   > developers.

   What negative effects? can you show them in the archives?

For example, the Info form of 

    emacs/doc/lispintro/emacs-lisp-intro.texi
is 
    emacs/info/eintr

When the file was installed in GNU Emacs, that was changed from a
longer Info file name.  I have never complained (so you will never see
it in the archives) because emacs-lisp-intro.info is 16.4 but have
always been irritated that Emacs still may not make all its file names
32 bytes long, only some of them.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: isearch multiple buffers

[Eli Zaretskii]

> Date: Thu, 25 Oct 2007 11:02:03 +0000 (UTC)
> From: "Robert J. Chassell" <bob@rattlesnake.com>
> 
>    > Because the 8.3 name restriction has a negative effect for _all_
>    > developers.
> 
>    What negative effects? can you show them in the archives?
> 
> For example, the Info form of 
> 
>     emacs/doc/lispintro/emacs-lisp-intro.texi
> is 
>     emacs/info/eintr

That was 6 years ago.

An issue that comes up with such frequency is for all practical
purposes non-existent.

> When the file was installed in GNU Emacs, that was changed from a
> longer Info file name.  I have never complained (so you will never see
> it in the archives) because emacs-lisp-intro.info is 16.4 but have
> always been irritated that Emacs still may not make all its file names
> 32 bytes long, only some of them.

eintr is modeled after elisp.

Re: isearch multiple buffers

[Robert J. Chassell]

   > For example, the Info form of 
   > 
   >     emacs/doc/lispintro/emacs-lisp-intro.texi
   > is 
   >     emacs/info/eintr

   That was 6 years ago.

   An issue that comes up with such frequency is for all practical
   purposes non-existent.

It did not just come up once six years ago, it has come up frequently
since then.  That is the cost.

However, you could not have learned from me.  As I said,

   > ... I have never complained (so you will never see it in the
   > archives) because emacs-lisp-intro.info is 16.4 but have always
   > been irritated ...

But, put another way, more than one person supports the format.  That
is what Miles is trying to get at.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: isearch multiple buffers

[Eli Zaretskii]

> Date: Fri, 26 Oct 2007 01:30:41 +0000 (UTC)
> From: "Robert J. Chassell" <bob@rattlesnake.com>
> 
>    > For example, the Info form of 
>    > 
>    >     emacs/doc/lispintro/emacs-lisp-intro.texi
>    > is 
>    >     emacs/info/eintr
> 
>    That was 6 years ago.
> 
>    An issue that comes up with such frequency is for all practical
>    purposes non-existent.
> 
> It did not just come up once six years ago, it has come up frequently
> since then.

Maybe my memory is failing me, because I don't remember that.  Can you
find those frequent discussions in the archives?

> But, put another way, more than one person supports the format.

Yeah, I wonder where all those people are when I need to fix a bug in
the MSDOS port.

Re: isearch multiple buffers

[Robert J. Chassell]

   ... Can you find those frequent discussions in the archives?

As I said, on Thu, 25 Oct 2007

    I have never complained (so you will never see it in the archives)
    because emacs-lisp-intro.info is 16.4 ...

That I have not put words in the archives does not mean I have been
happy.  Moreover, by doing nothing against it, I have provided Emacs
with support for 8.3.  The support has not helped you since it has
only been negative.

From my point of view, the whole issue is fairly minor.  It is not and
has not been a big deal, but it is not irrelevant either.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: isearch multiple buffers

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1053 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 25 Oct 2007 11:02:03 +0000 (UTC)
>> From: "Robert J. Chassell" <bob@rattlesnake.com>
>>
>>    > Because the 8.3 name restriction has a negative effect for _all_
>>    > developers.
>>
>>    What negative effects? can you show them in the archives?
>>
>> For example, the Info form of
>>
>>     emacs/doc/lispintro/emacs-lisp-intro.texi
>> is
>>     emacs/info/eintr
>
> That was 6 years ago.
>
> An issue that comes up with such frequency is for all practical
> purposes non-existent.

The issue will come up again fairly soon if I get Emacs Muse installed
into the Emacs source tree.  At that time, I will absolutely refuse to
cater to the 8.3 convention.  Muse can just be pegged as having no
support for MS-DOS.

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
            Sysadmin -- Hobbies: Lisp, GP2X, HCoop    | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

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

Re: isearch multiple buffers

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Miles Bader <miles@gnu.org>
  > > Date: Thu, 25 Oct 2007 08:55:20 +0900
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > >> Er, I was arguing for _dropping_ support for msdos, even if continuing
  > > >> it proves possible.
  > > >
  > > > But no one is supporting it except myself, for years.  This support
  > > > costs the rest of maintainers exactly zero effort.  So why should
  > > > someone except myself be bothered about it?
  > > 
  > > Because the 8.3 name restriction has a negative effect for _all_
  > > developers.
  > 
  > What negative effects? can you show them in the archives?  AFAIR, this
  > is about the first such issue in years.

Here are quite a few exmaples: go to http://search.gmane.org/ search
for 8.3 and use "gmane.emacs.devel" for "In group". It produces a good
amount of hits. 

Another situation where the DOS port had to be taken into account:
recently I wanted to clean up the code and get rid of the MULTI_KBOARD
#ifdefs. You asked me not to because the MSDOS port might need it. I
am 100% convinced that it won't be needed, but preferred to drop the
issue rather that try to convince you of this. 
Also, there are a LOT of DOS #ifdefs in the code that we could get rid
of, that should simplify future maintenance. 

So yes, the fact that the DOS code is present has an impact on
everyone that does work on emacs. As long as there are users for that
code this is fine, but there's no evidence that there are such users.

Re: isearch multiple buffers

[Juanma Barranquero]

On 10/26/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> So yes, the fact that the DOS code is present has an impact on
> everyone that does work on emacs. As long as there are users for that
> code this is fine, but there's no evidence that there are such users.

I have no opinion on this discussion, but with respect to the point
above, it is not inconceivable to think that ports for old
architectures could be still in use in less developed countries, where
upgrading to the new-and-shiny-processor-do-jour is often
impractical... That reason has been given many times to maintain the
support for Windows 95/98/Me, and does not seem too far-fetched to
extend that to MS-DOS.

             Juanma

Re: isearch multiple buffers

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 10/26/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>
>> So yes, the fact that the DOS code is present has an impact on
>> everyone that does work on emacs. As long as there are users for that
>> code this is fine, but there's no evidence that there are such users.
>
> I have no opinion on this discussion, but with respect to the point
> above, it is not inconceivable to think that ports for old
> architectures could be still in use in less developed countries, where
> upgrading to the new-and-shiny-processor-do-jour is often
> impractical... That reason has been given many times to maintain the
> support for Windows 95/98/Me, and does not seem too far-fetched to
> extend that to MS-DOS.

But how many of those people will be able to use a bleeding-edge
Emacs?  The memory requirements would appear prohibitive if you have a
platform for which nothing but MSDOS seems reasonable.

-- 
David Kastrup

Re: isearch multiple buffers

[Juanma Barranquero]

On 10/26/07, David Kastrup <dak@gnu.org> wrote:

> But how many of those people will be able to use a bleeding-edge
> Emacs?  The memory requirements would appear prohibitive if you have a
> platform for which nothing but MSDOS seems reasonable.

You're right, but I was assuming that the MS-DOS port of Emacs 22.1
could run in 640 KB machines. Isn't it so?

             Juanma

Re: isearch multiple buffers

[Stefan Monnier]

>> But how many of those people will be able to use a bleeding-edge
>> Emacs?  The memory requirements would appear prohibitive if you have a
>> platform for which nothing but MSDOS seems reasonable.

> You're right, but I was assuming that the MS-DOS port of Emacs 22.1
> could run in 640 KB machines. Isn't it so?

As long as a 640KB machine can load the 3MB `emacs' binary, that should be
fine ;-)


        Stefan

Re: isearch multiple buffers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 26 Oct 2007 14:42:04 -0400
> Cc: Dan Nicolaescu <dann@ics.uci.edu>, Miles Bader <miles@gnu.org>,
> 	Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > You're right, but I was assuming that the MS-DOS port of Emacs 22.1
> > could run in 640 KB machines. Isn't it so?
> 
> As long as a 640KB machine can load the 3MB `emacs' binary, that should be
> fine ;-)

With virtual memory, it can.  And the MSDOS port does use virtual
memory.

Re: isearch multiple buffers

[Eli Zaretskii]

> Date: Fri, 26 Oct 2007 17:42:41 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: "Dan Nicolaescu" <dann@ics.uci.edu>, "Eli Zaretskii" <eliz@gnu.org>, 
> 	"Miles Bader" <miles@gnu.org>, emacs-devel@gnu.org
> 
> On 10/26/07, David Kastrup <dak@gnu.org> wrote:
> 
> > But how many of those people will be able to use a bleeding-edge
> > Emacs?  The memory requirements would appear prohibitive if you have a
> > platform for which nothing but MSDOS seems reasonable.
> 
> You're right, but I was assuming that the MS-DOS port of Emacs 22.1
> could run in 640 KB machines. Isn't it so?

It can, but it will constantly swap because Emacs starts with 7MB of
memory footprint, and then grows larger as you work in it.

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: "Dan Nicolaescu" <dann@ics.uci.edu>, Eli Zaretskii <eliz@gnu.org>,
>         Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Fri, 26 Oct 2007 17:36:54 +0200
> 
> But how many of those people will be able to use a bleeding-edge
> Emacs?  The memory requirements would appear prohibitive if you have a
> platform for which nothing but MSDOS seems reasonable.

Maybe you think that the MSDOS port is a 16-bit, real-mode only
program that can only use the lower 1MB of the memory.  But in fact,
the MSDOS port is a 32-bit protected mode program that just uses DOS
system calls to do its job.  So it can use virtual memory and all the
physical memory up to 512MB that is present on modern machines.

So the traditional DOS memory limitations are not a problem here.

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Fri, 26 Oct 2007 08:16:26 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > > Because the 8.3 name restriction has a negative effect for _all_
>   > > developers.
>   > 
>   > What negative effects? can you show them in the archives?  AFAIR, this
>   > is about the first such issue in years.
> 
> Here are quite a few exmaples: go to http://search.gmane.org/ search
> for 8.3 and use "gmane.emacs.devel" for "In group". It produces a good
> amount of hits. 

All I see, in addition to this thread is the following:

  . An issue with foo-+.texi in June 2004

  . A couple of messages about ChangeLog-unicode in February 2005

  . A discussion back in August 2005 when MH-E was added to Emacs, and
    a related discussion in September that year about image files.

  . A comment by Kim Storm in June this year about renaming a single
    file.

  . A few other hits that have nothing to do with conflicts in file
    names due to 8+3 restrictions, such as the discussion in May 2004
    about the doc string of convert-standard-filename

So there are, like, 4-5 instances since 2004---more than I thought,
but still very much negligible.

> Another situation where the DOS port had to be taken into account:
> recently I wanted to clean up the code and get rid of the MULTI_KBOARD
> #ifdefs. You asked me not to because the MSDOS port might need it. I
> am 100% convinced that it won't be needed, but preferred to drop the
> issue rather that try to convince you of this. 

So you are saying that my stubbornness is also a problem related to
the MSDOS port?

> Also, there are a LOT of DOS #ifdefs in the code that we could get rid
> of, that should simplify future maintenance. 

You can say this about many other supported platforms.  Look at
sysdep.c, for example, or at process.c.

This thread was only about 8+3 file-name limitations.

Re: isearch multiple buffers

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Fri, 26 Oct 2007 08:16:26 -0700
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > >   > > Because the 8.3 name restriction has a negative effect for _all_
  > >   > > developers.
  > >   > 
  > >   > What negative effects? can you show them in the archives?  AFAIR, this
  > >   > is about the first such issue in years.
  > > 
  > > Here are quite a few exmaples: go to http://search.gmane.org/ search
  > > for 8.3 and use "gmane.emacs.devel" for "In group". It produces a good
  > > amount of hits. 
  > 
  > All I see, in addition to this thread is the following:
  > 
  >   . An issue with foo-+.texi in June 2004
  > 
  >   . A couple of messages about ChangeLog-unicode in February 2005
  > 
  >   . A discussion back in August 2005 when MH-E was added to Emacs, and
  >     a related discussion in September that year about image files.
  > 
  >   . A comment by Kim Storm in June this year about renaming a single
  >     file.
  > 
  >   . A few other hits that have nothing to do with conflicts in file
  >     names due to 8+3 restrictions, such as the discussion in May 2004
  >     about the doc string of convert-standard-filename
  > 
  > So there are, like, 4-5 instances since 2004---more than I thought,
  > but still very much negligible.

I wouldn't call it negligible, it is annoying. And that is just one
search, looking other keywords might find more stuff.  And again, the
feeling of a lot of people on this list is that this dealing with this
is unjustified, as the platform does not seem to be too much alive

  > > Another situation where the DOS port had to be taken into account:
  > > recently I wanted to clean up the code and get rid of the MULTI_KBOARD
  > > #ifdefs. You asked me not to because the MSDOS port might need it. I
  > > am 100% convinced that it won't be needed, but preferred to drop the
  > > issue rather that try to convince you of this. 
  > 
  > So you are saying that my stubbornness is also a problem related to
  > the MSDOS port?

I did not say, nor did I want to imply anything about "stubbornness",
I am sorry if that's what you read into this. I just felt that it
wasn't worth my time or yours to try to convince you about
this. (which is quite possible with the right technical arguments).

  > > Also, there are a LOT of DOS #ifdefs in the code that we could get rid
  > > of, that should simplify future maintenance. 
  > 
  > You can say this about many other supported platforms.  Look at
  > sysdep.c, for example, or at process.c.

Exactly, if there are many other systems that are dead, we should just
delete the corresponding cruft.

  > This thread was only about 8+3 file-name limitations.

I might have confused the thread, I thought the discussion was in
general about if it was about if keeping the MSDOS port altogether. 

Re: isearch multiple buffers

[Jason Rumney]

Dan Nicolaescu wrote:
> I wouldn't call it negligible, it is annoying.
And this thread so far has been about 10x as annoying as the 4-5
problems that have surfaced and been swiftly dealt with over the last
few years.

Re: isearch multiple buffers

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Dan Nicolaescu wrote:
>> I wouldn't call it negligible, it is annoying.
> And this thread so far has been about 10x as annoying as the 4-5
> problems that have surfaced and been swiftly dealt with over the last
> few years.

Scratching an itch until it bleeds may be stupid, but it still starts
with an itch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch multiple buffers

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Fri, 26 Oct 2007 12:41:38 -0700
> Cc: emacs-devel@gnu.org
> 
>   > So there are, like, 4-5 instances since 2004---more than I thought,
>   > but still very much negligible.
> 
> I wouldn't call it negligible, it is annoying.

I guess we have very different levels of annoyance, then.

Re: isearch multiple buffers

[Stefan Monnier]

Can we stop this madness, please?


        Stefan

Re: isearch multiple buffers

[Richard Stallman]

Let's post an announcement on info-gnu-emacs listing a few platforms
we are thinking of desupporting, and asking if anyone still cares
about them.

Re: isearch multiple buffers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> Date: Sat, 27 Oct 2007 09:57:52 -0400
> 
> Let's post an announcement on info-gnu-emacs listing a few platforms
> we are thinking of desupporting, and asking if anyone still cares
> about them.

The announcement should also go to help-gnu-emacs, IMO, as I don't
expect most users to read info-gnu-emacs.

Re: isearch multiple buffers

[Richard Stallman]

    > Let's post an announcement on info-gnu-emacs listing a few platforms
    > we are thinking of desupporting, and asking if anyone still cares
    > about them.

    The announcement should also go to help-gnu-emacs, IMO, as I don't
    expect most users to read info-gnu-emacs.

Good idea.

Re: isearch multiple buffers

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Let's post an announcement on info-gnu-emacs listing a few platforms
  > we are thinking of desupporting, and asking if anyone still cares
  > about them.

What would be the criteria for still keeping support?
One could be that 22.1 should be still functional on the platform.
If one user has a machine in the basement that gets turned on once a
year, would that qualify?

Here a start for a list of things for which we could drop support. It
is just a start...


X10  (window-system-version mentions it, is it still supported?)
MSDOS
Windows 16 (not sure if this is independent, or it is used in
conjunction with MSDOS).
Mac OS all versions before MACOSX (only MAC_OS8 seems to have a special define)

VMS ?? (at least find out if this port is functional, I seem to
       remember posts on the mailing list from people saying that
       they'd try it, but never any confirmation...)

Apollo SR10.x (unexapollo.c)
Convex (unexconvex.c and m/convex.c)
Xenix (unexenix.c and s/xenix.h)
Iris  (unexmips.c m/iris4d.h   m/irist.h    s/iris3-5.h  s/iris3-6.h)
Gould (m/gould*)
Siemens machines running Sinix (unexsni.c)
Harris CXUX (s/cxux*)
ESIX, a variant of v.5.3 for the 386. (s/esix*)
Interactive (ISC) Unix (s/isc*)
Sony News (s/newsos*)
RTU 3.0, ucb universe (s/rtu.h) -- defines NOMULTIPLEJOBS
UniSoft's UniPlus 5.2 (s/uniplus.h)
UMAX (s/umax.h)
AT&T UNIX PC model 7300 (m/7300.h)
Acorn
Alliant (m/alliant*)
Amdahl (m/amdahl*)
Altos 3068 Unix System V Release 2 (m/altos.h)
Apollo (m/apollo.h)
AT&T 3b (m/att3b.h)
Aviion (m/aviion*)
Celerity (m/celerity.h)
clipper (m/clipper.h)
convergent S series (m/cnvrgnt.h)
cydra (m/cydra5.h)
Motorola System V/88 machines (m/delta88k.h) -- gcc dropped support
                              for 88k a while ago
Bull DPX/2 range (m/dpx2.h)
Dual machines using unisoft port (m/dual.h)
Elxsi machine (running enix) (m/elxsi.h)
Fujitsu F301 machine (m/f301.h)
i860 (m/i860.h) gcc dropped support a while ago
ibm ps/2 aix386 (m/ibmps2-aix.h)
ISI 68000's (m/is*)
Masscomp 5000 series running RTU, ucb universe (m/masscomp.h)
Megatest 68000's (m/mega68.h)
Whitechapel Computer Works MG1 (ns16000 based) (m/mg1.h)
Harris Night Hawk Series 1200 and Series 3000 (m/nh3000.h m/nh4000.h)
ns16000 (m/ns16000.h)
National Semiconductor 32000, running Genix (m/ns32000.h)
TI Nu machines using system V (m/nu.h)
HLH Orion (m/orion.h m/orion105.h)
Paragon i860 (m/paragon.h)
PFU A-series (m/pfa50.h)
Plexus running System V.2 (m/plexus.h)
pyramid. (m/pyramid.h)
sh3el (m/sh3el.h)
Bull SPS-7 (m/sps7.h)
m/sr2k.h
Stride (m/stride.h)
Sun 1 (m/sun1.h)
Sun 2 (m/sun2.h)
SEQUENT SYMMETRY  m/symmetry.h
Tadpole 68k machines m/tad68k.h
tahoe m/tahoe.h
targon31 m/targon31.h
Tektronix* (m/tek4300.h m/tekxd88.h)
NCR Tower 32 running System V.2 (m/tower32.h)
NCR Tower 32 running System V.3 (m/tower32v3.h)
U-station (Nihon Unisys, SS5E; Sumitomo Denkoh, U-Station E30). (m/ustation.h)
Wicat (m/wicat.h)
Honeywell XPS100 running UNIX System V.2 (m/xps100.h)


(Some things might not even need a posting, like getting rid of X10)

Re: isearch multiple buffers

[Eli Zaretskii]

> Cc: eliz@gnu.org, emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sat, 27 Oct 2007 10:28:46 -0700
> 
> Windows 16 (not sure if this is independent, or it is used in
> conjunction with MSDOS).

There's no such thing as a Windows 16 port of Emacs.  There's only the
MSDOS port (which runs on all versions of Windows as well, including
Windows 3.x, that would qualify as "Windows 16").

Re: isearch multiple buffers

[Richard Stallman]

    What would be the criteria for still keeping support?

How much users want support for a platform is the question
I hope this will answer.

    One could be that 22.1 should be still functional on the platform.

We should not desupport a platform just because it has a bug.

    If one user has a machine in the basement that gets turned on once a
    year, would that qualify?

I don't think there should be any particular fixed threshold.  The
more users want it, the more work it's worth doing to support it.

Re: isearch multiple buffers

[Richard Stallman]

    X10  (window-system-version mentions it, is it still supported?)

I think all code specific to X10 was all deleted ages ago.
There are a few conditionals that test HAVE_X11, but they really
use it to test whether X is present at all.

There are still conditionals for X11R3 (testing HAVE_X11R4).  That
must be long obsolete.  We can delete them if that would save us any
trouble.

Your list of platforms to propose to delete seems like a good start.
Please collect others' suggestions, then post the final list in a few
days.

desupporting X10 and old X11 releases (was: Re: isearch multiple buffers)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     X10  (window-system-version mentions it, is it still supported?)
  > 
  > I think all code specific to X10 was all deleted ages ago.

There's still a bit of code in the s/* m/* files and Makefile.in that
deals with LIBX10_SYSTEM and LIBX10_MACHINE.
Hopefully most of it will disappear after we desupport some platforms.

But there's also oldXMenu/X10.h. Is that still relevant? 
Is oldXMenu still used?

  > There are a few conditionals that test HAVE_X11, but they really
  > use it to test whether X is present at all.
  > 
  > There are still conditionals for X11R3 (testing HAVE_X11R4).  That
  > must be long obsolete.  We can delete them if that would save us any
  > trouble.

It will allow us to get rid of some code in xterm.[ch] and xfns.c, so
it seems worth doing.

How about X11R4, is that still worth supporting? 

  > Your list of platforms to propose to delete seems like a good start.
  > Please collect others' suggestions, then post the final list in a few
  > days.

Sounds good.

Re: desupporting X10 and old X11 releases

[Jan Djärv]

Dan Nicolaescu skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>   >     X10  (window-system-version mentions it, is it still supported?)
>   > 
>   > I think all code specific to X10 was all deleted ages ago.
> 
> There's still a bit of code in the s/* m/* files and Makefile.in that
> deals with LIBX10_SYSTEM and LIBX10_MACHINE.
> Hopefully most of it will disappear after we desupport some platforms.
> 
> But there's also oldXMenu/X10.h. Is that still relevant? 
> Is oldXMenu still used?
> 

oldXMenu/X10.h just contains some data structures.  Maybe these where related 
to X10 at some point, but they no longer are, there are just structures used 
by the code.  It is bad name for that file though.

I don't know if oldXMenu is used (it is kind of strange looking :-), but it 
compiles and works.  But I suspect that those that can't use any X toolkit use 
Lucid.  I'd say we can get rid of it.


>   > There are a few conditionals that test HAVE_X11, but they really
>   > use it to test whether X is present at all.
>   > 
>   > There are still conditionals for X11R3 (testing HAVE_X11R4).  That
>   > must be long obsolete.  We can delete them if that would save us any
>   > trouble.
> 
> It will allow us to get rid of some code in xterm.[ch] and xfns.c, so
> it seems worth doing.
> 
> How about X11R4, is that still worth supporting? 
> 

As I said in another mail, I think we can assume R6 or newer, and remove all 
three of HAVE_X11R[456].

	Jan D.

Re: desupporting X10 and old X11 releases

[Eli Zaretskii]

> Date: Mon, 29 Oct 2007 08:30:09 +0100
> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
> Cc: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org
> 
> I don't know if oldXMenu is used (it is kind of strange looking :-), but it 
> compiles and works.  But I suspect that those that can't use any X toolkit use 
> Lucid.  I'd say we can get rid of it.

Sorry for my failing memory, but isn't oldXMenu used for
non-USE_X_TOOLKIT compilation of xmenu.c?  If so, I wouldn't recommend
deleting it, because that's currently the only way to build and test
that branch of xmenu.c (the other build which used to use it was the
MSDOS port, but it's broken on the trunk for the time being).  We
might need it again if and when someone writes the code to support
menus on a Unix text terminal.

Re: desupporting X10 and old X11 releases

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Mon, 29 Oct 2007 08:30:09 +0100
>> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
>> Cc: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org
>>
>> I don't know if oldXMenu is used (it is kind of strange looking :-), but it 
>> compiles and works.  But I suspect that those that can't use any X toolkit use 
>> Lucid.  I'd say we can get rid of it.
> 
> Sorry for my failing memory, but isn't oldXMenu used for
> non-USE_X_TOOLKIT compilation of xmenu.c? 

Yes.

> If so, I wouldn't recommend
> deleting it, because that's currently the only way to build and test
> that branch of xmenu.c (the other build which used to use it was the
> MSDOS port, but it's broken on the trunk for the time being).  We
> might need it again if and when someone writes the code to support
> menus on a Unix text terminal.

IMHO, possible future development is not a good reason to keep almost unused 
code.  After all, the code is in CVS if it is needed in the future.  Also, 
adding menu code is as easy in the toolkit code as in the non-toolkit code. 
The main difference is that the non-toolkit code does not use callbacks. 
Otherwise there is much duplication.

	Jan D.

Re: desupporting X10 and old X11 releases

[Richard Stallman]

Before we delete oldXMenu as an option, I want to ask users if anyone
still wants it.  Supporting it is not costing much effort, and it
is not a matter of a platform that may have disappeared.

Re: desupporting X10 and old X11 releases

[Ulrich Mueller]

>>>>> On Mon, 29 Oct 2007, Richard Stallman wrote:

> Before we delete oldXMenu as an option, I want to ask users if anyone
> still wants it.  Supporting it is not costing much effort, and it
> is not a matter of a platform that may have disappeared.

Here are some data from Gentoo (for both GNU/Linux and FreeBSD).
I have extracted the configuration information ("USE flags") from
GNU Emacs related bugs that were reported to us in 2006 and 2007.
(I didn't bother to correct for users reporting more than one bug,
so active users might have more than one "vote" in the table below.
It's not dominated by a small number of users though.)

The result is quite surprising (at least to me):

   Toolkit                  Gentoo USE flags      number
   -----------------------------------------------------
   gtk                      X gtk                     80
   athena / lucid           X -gtk Xaw3d               2
   motif / lesstif          X -gtk -Xaw3d motif        2
   no toolkit / oldXMenu    X -gtk -Xaw3d -motif      18
   no X                     -X                        15
   -----------------------------------------------------

The reason for the low numbers for "athena/lucid" and "motif/lesstif"
may be that the Gentoo ebuild always prefers "gtk" if the user
specifies more than one toolkit at the same time. (The raw numbers for
the USE flags are 21 times "X Xaw3d" and 40 times "X motif".)

However, the conclusion is that there seems to be a substantial number
of Emacs installations using either no X toolkit, or no X at all.

Ulrich

Re: desupporting X10 and old X11 releases

[Richard Stallman]

Thanks for collecting and analyzing the data.  I conclude that we
should not delete oldXMenu upport.

Re: desupporting X10 and old X11 releases (was: Re: isearch multiple buffers)

[Richard Stallman]

    There's still a bit of code in the s/* m/* files and Makefile.in that
    deals with LIBX10_SYSTEM and LIBX10_MACHINE.
    Hopefully most of it will disappear after we desupport some platforms.

We could delete all of those definitions now, and the X10 code in
src/Makefile.in, since there is no real X10 support in the C files.

    But there's also oldXMenu/X10.h. Is that still relevant? 

Yes -- it is used by oldXMenu with X11.

    Is oldXMenu still used?

Yes, though perhaps not much any more.

Re: desupporting X10 and old X11 releases (was: Re: isearch multiple buffers)

[Richard Stallman]

      > There are still conditionals for X11R3 (testing HAVE_X11R4).  That
      > must be long obsolete.  We can delete them if that would save us any
      > trouble.

    It will allow us to get rid of some code in xterm.[ch] and xfns.c, so
    it seems worth doing.

    How about X11R4, is that still worth supporting? 

I don't think so.  But let's ask about that along with the other
questions.

abandon K&R C ?(was: Re: isearch multiple buffers)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     X10  (window-system-version mentions it, is it still supported?)
  > 
  > I think all code specific to X10 was all deleted ages ago.
  > There are a few conditionals that test HAVE_X11, but they really
  > use it to test whether X is present at all.
  > 
  > There are still conditionals for X11R3 (testing HAVE_X11R4).  That
  > must be long obsolete.  We can delete them if that would save us any
  > trouble.

This also seems be a good opportunity abandon K&R C. Functions that
use the ISO C style are sprinkled all over the place, so it's doubtful
that emacs would build now with a K&R only compiler.
AFAIK binutils, gdb and gcc did this a few years ago with no
problems.
(We should probably wait for the unicode-2 branch to be merged first to
 avoid unnecessary merge conflicts).

Re: abandon K&R C ?(was: Re: isearch multiple buffers)

[Richard Stallman]

    This also seems be a good opportunity abandon K&R C.

I am not looking for an "opportunity" to do this.

Re: abandon K&R C ?(was: Re: isearch multiple buffers)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> Date: Mon, 29 Oct 2007 05:21:48 -0400
> 
>     This also seems be a good opportunity abandon K&R C.
> 
> I am not looking for an "opportunity" to do this.

Btw, we can have the cake and eat it, too, by using the P_ macro
(defined on lisp.h).

Re: abandon K&R C ?

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>>     This also seems be a good opportunity abandon K&R C.
>> 
>> I am not looking for an "opportunity" to do this.
>
> Btw, we can have the cake and eat it, too, by using the P_ macro
> (defined on lisp.h).

I think compiling Emacs using a K&R-only compiler has been impossible
for a long time anyway, as many Emacs functions have been written in
ANSI style with no regard for K&R-compatibility.  Nobody has complained.

Morever, it would probably take a fair amount of work to make Emacs
compile with a K&R compiler again.

If there are actually any K&R-only compilers left (are there?!), it's
likely they're so crufty/out-of-date/underfeatured that they'd never be
able to handle Emacs anyway.

It doesn't seem worth it to me to _rewrite_ existing K&R-style
definitions -- that would just cause a lot of headaches for merging --
but I think it would be good to explicitly state that it's OK to use
ANSI-style definitions for new functions or rewrites etc.

Using P_ also seems sort of pointless, as it only exists for the benefit
of K&R.  So I think it would also be good to state that it's unnecessary
to use P_ for new function declarations (in headers etc).

-Miles

-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: isearch multiple buffers

[Jan Djärv]

Richard Stallman skrev:
>     X10  (window-system-version mentions it, is it still supported?)
> 
> I think all code specific to X10 was all deleted ages ago.
> There are a few conditionals that test HAVE_X11, but they really
> use it to test whether X is present at all.
> 
> There are still conditionals for X11R3 (testing HAVE_X11R4).  That
> must be long obsolete.  We can delete them if that would save us any
> trouble.
> 

There are also a couple of HAVE_X11R5 and HAVE_X11R6.  I think we can get rid 
of all three.  The first R6 was released in 1994.

	Jan D.

Re: isearch multiple buffers

[Richard Stallman]

    There are also a couple of HAVE_X11R5 and HAVE_X11R6.  I think we can get rid 
    of all three.  The first R6 was released in 1994.

Let's get rid of HAVE_X11R5, but before we get rid of HAVE_X11R6,
let's ask if anyone still uses a system with X11r5.  Those conditionals
are few, so we won't gain much by deleting them.

remove support for Sun windows (was Re: isearch multiple buffers)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     There are also a couple of HAVE_X11R5 and HAVE_X11R6.  I think we can get rid 
  >     of all three.  The first R6 was released in 1994.
  > 
  > Let's get rid of HAVE_X11R5, but before we get rid of HAVE_X11R6,
  > let's ask if anyone still uses a system with X11r5.  Those conditionals
  > are few, so we won't gain much by deleting them.

How about removing support for Sun windows (sunfns.c + a few lisp
files)? 

Re: remove support for Sun windows (was Re: isearch multiple buffers)

[Richard Stallman]

    How about removing support for Sun windows (sunfns.c + a few lisp
    files)? 

Yes, let's.

Re: remove support for Sun windows (was Re: isearch multiple buffers)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     How about removing support for Sun windows (sunfns.c + a few lisp
  >     files)? 
  > 
  > Yes, let's.

Done.

Re: isearch multiple buffers

[Jan Djärv]

Richard Stallman skrev:
>     There are also a couple of HAVE_X11R5 and HAVE_X11R6.  I think we can get rid 
>     of all three.  The first R6 was released in 1994.
> 
> Let's get rid of HAVE_X11R5, but before we get rid of HAVE_X11R6,
> let's ask if anyone still uses a system with X11r5.  Those conditionals
> are few, so we won't gain much by deleting them.
> 

Done.

	Jan D.

List of platforms to delete (was: Re: isearch multiple buffers)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > There are still conditionals for X11R3 (testing HAVE_X11R4).  That
  > must be long obsolete.  We can delete them if that would save us any
  > trouble.
  > 
  > Your list of platforms to propose to delete seems like a good start.
  > Please collect others' suggestions, then post the final list in a few
  > days.

I didn't get other suggestions, I added a few more at the end.

So here is the list again, please post it to the right forums.



MSDOS
Mac OS all versions before MACOSX (only MAC_OS8 seems to have a special define)

VMS ?? (at least find out if this port is functional, I seem to
       remember posts on the mailing list from people saying that
       they'd try it, but never any confirmation...)

Apollo SR10.x (unexapollo.c)
Convex (unexconvex.c and m/convex.c)
Xenix (unexenix.c and s/xenix.h)
Iris  (unexmips.c m/iris4d.h   m/irist.h    s/iris3-5.h  s/iris3-6.h)
Gould (m/gould*)
Siemens machines running Sinix (unexsni.c)
Harris CXUX (s/cxux*)
ESIX, a variant of v.5.3 for the 386. (s/esix*)
Interactive (ISC) Unix (s/isc*)
Sony News (s/newsos*)
RTU 3.0, ucb universe (s/rtu.h) -- defines NOMULTIPLEJOBS
UniSoft's UniPlus 5.2 (s/uniplus.h)
UMAX (s/umax.h)
AT&T UNIX PC model 7300 (m/7300.h)
Acorn
Alliant (m/alliant*)
Amdahl (m/amdahl*)
Altos 3068 Unix System V Release 2 (m/altos.h)
Apollo (m/apollo.h)
AT&T 3b (m/att3b.h)
Aviion (m/aviion*)
Celerity (m/celerity.h)
clipper (m/clipper.h)
convergent S series (m/cnvrgnt.h)
cydra (m/cydra5.h)
Motorola System V/88 machines (m/delta88k.h) -- gcc dropped support
                              for 88k a while ago
Bull DPX/2 range (m/dpx2.h)
Dual machines using unisoft port (m/dual.h)
Elxsi machine (running enix) (m/elxsi.h)
Fujitsu F301 machine (m/f301.h)
i860 (m/i860.h) gcc dropped support a while ago
ibm ps/2 aix386 (m/ibmps2-aix.h)
ISI 68000's (m/is*)
Masscomp 5000 series running RTU, ucb universe (m/masscomp.h)
Megatest 68000's (m/mega68.h)
Whitechapel Computer Works MG1 (ns16000 based) (m/mg1.h)
Harris Night Hawk Series 1200 and Series 3000 (m/nh3000.h m/nh4000.h)
ns16000 (m/ns16000.h)
National Semiconductor 32000, running Genix (m/ns32000.h)
TI Nu machines using system V (m/nu.h)
HLH Orion (m/orion.h m/orion105.h)
Paragon i860 (m/paragon.h)
PFU A-series (m/pfa50.h)
Plexus running System V.2 (m/plexus.h)
pyramid. (m/pyramid.h)
sh3el (m/sh3el.h)
Bull SPS-7 (m/sps7.h)
m/sr2k.h
Stride (m/stride.h)
Sun 1 (m/sun1.h)
Sun 2 (m/sun2.h)
SEQUENT SYMMETRY  m/symmetry.h
Tadpole 68k machines m/tad68k.h
tahoe m/tahoe.h
targon31 m/targon31.h
Tektronix* (m/tek4300.h m/tekxd88.h)
NCR Tower 32 running System V.2 (m/tower32.h)
NCR Tower 32 running System V.3 (m/tower32v3.h)
U-station (Nihon Unisys, SS5E; Sumitomo Denkoh, U-Station E30). (m/ustation.h)
Wicat (m/wicat.h)
Honeywell XPS100 running UNIX System V.2 (m/xps100.h)


Data General's DG/UX  (s/dgux*)
Irix before version 6
osf1 (s/osf*)
SunOS4 (s/sunos*)
RISCiX (s/riscix*)
SCO 3.2v4 (s/sco4.h)
SCO 3.2v5 (s/sco5.h)
Sun's 386-based RoadRunner (m/sun386.h)
Sun3 machines (m/sun3*)
 Integrated Solutions 386 machine (m/is386.h)

Re: isearch multiple buffers

[martin rudalics]

> Because the 8.3 name restriction has a negative effect for _all_
> developers.

I think the 8.3 name restriction had the benefit that the names of most
Emacs' files have been kept succinct and yet meaningful over the time.
Names of buffers and files don't occupy much space in the modeline and
are readable for iconified frames.  I can easily display lists of files
and buffers in ten characters wide sidebars on the left of my editing
window.

Admittedly, thinking of a good filename fitting the restriction may take
some time.  However, I'm afraid that removing the restriction will soon
lead to more monstrosities like "idlw-complete-structtag.el".

Re: isearch multiple buffers

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
> I think the 8.3 name restriction had the benefit that the names of most
> Emacs' files have been kept succinct and yet meaningful over the time.

... except when they are made less meaningful due to the restrictions.
Short is good as a general guideline, but it's hardly synonymous with
clarity or succinctness!

If we want shortish, succinct, names, then clearly we can review new
names, and change them when they're too long.  This is no different than
what happens for the 8.3 restrictions, except that the criteria for
judging will be actually be _relevant_ ("does this name suck?") rather
than being based on bill gate's brain tumor 30 years ago.

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: isearch multiple buffers

[Juanma Barranquero]

On 10/25/07, Miles Bader <miles.bader@necel.com> wrote:

> being based on bill gate's brain tumor 30 years ago.

The 8.3 scheme predates MS-DOS. And it was quite reasonable at the time.

             Juanma

Re: isearch multiple buffers

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 10/25/07, Miles Bader <miles.bader@necel.com> wrote:
>
>> being based on bill gate's brain tumor 30 years ago.
>
> The 8.3 scheme predates MS-DOS.

Gary Kildall (?), CP/M.  Boxes with 64kB of address space and
typically about 100kB of disk space.

> And it was quite reasonable at the time.

Adopting it wasn't.  CP/M compatibility induced issues continue to
haunt Windows after all these years.

-- 
David Kastrup

Re: isearch multiple buffers

[Juanma Barranquero]

On 10/25/07, David Kastrup <dak@gnu.org> wrote:

> Gary Kildall (?), CP/M.

There were similar schemes in some mainframes and minis. I vaguely
remember something like that in RSX-11, on a PDP-11.

> Boxes with 64kB of address space and
> typically about 100kB of disk space.

Not *that* different of the initial IBM PCs.

> Adopting it wasn't.

I disagree.

> CP/M compatibility induced issues continue to
> haunt Windows after all these years.

True. Microsoft should've switched aggresively to the NT codebase
after Windows 3.11; there's no reasonable excuse for W95/98/Me :)

             Juanma

Re: isearch multiple buffers

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 10/25/07, David Kastrup <dak@gnu.org> wrote:
>
>> Gary Kildall (?), CP/M.
>
> There were similar schemes in some mainframes and minis. I vaguely
> remember something like that in RSX-11, on a PDP-11.
>
>> Boxes with 64kB of address space and
>> typically about 100kB of disk space.
>
> Not *that* different of the initial IBM PCs.

Address space, not actual available memory.

>> Adopting it wasn't.
>
> I disagree.

We have to agree to disagree.

-- 
David Kastrup

Re: isearch multiple buffers

[Juanma Barranquero]

On 10/25/07, David Kastrup <dak@gnu.org> wrote:

> Address space, not actual available memory.

I understand the difference.

             Juanma

Re: isearch multiple buffers

[Juri Linkov]

> There were similar schemes in some mainframes and minis. I vaguely
> remember something like that in RSX-11, on a PDP-11.

As I remember, there was 6.3 file name restriction in RSX-11 on a PDP-11
that is shorter than FAT file names.  Fortunately we haven't follow this
restriction unless we want to maintain compatibility with this platform :)

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

Re: isearch multiple buffers

[Juanma Barranquero]

On 10/25/07, Juri Linkov <juri@jurta.org> wrote:

> As I remember, there was 6.3 file name restriction in RSX-11 on a PDP-11
> that is shorter than FAT file names.

Chuck Moore has explanied that he named the language FORTH instead of
FOURTH because, in the system he was using at the time, filenames had
a maximum length of five characters.

> Fortunately we haven't follow this
> restriction unless we want to maintain compatibility with this platform :)

Fortunately. :)

             Juanma

8.3 filename restriction

[Kenichi Handa]

In article <47203C01.4070909@gmx.at>, martin rudalics <rudalics@gmx.at> writes:

> Admittedly, thinking of a good filename fitting the restriction may take
> some time.  However, I'm afraid that removing the restriction will soon
> lead to more monstrosities like "idlw-complete-structtag.el".

To my understanding, 8.3 name restriction actually means
that all filenames (in the same directory?) must be
distinguished by the first 8 (or 7? 6?)  characters.  So,
idlw-complete-structtag.el is ok unless there's another file
that starts with "idlw-complete".  Is it right?

And, I remember that there were another filename restriction
which limits the total length to 14 (or so) characters for
some other system.  Does anyone remember the detail?

---
Kenichi Handa
handa@m17n.org

Re: 8.3 filename restriction

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Oct 25, 2007 at 04:45:34PM +0900, Kenichi Handa wrote:
> In article <47203C01.4070909@gmx.at>, martin rudalics <rudalics@gmx.at> writes:
> 
> > Admittedly, thinking of a good filename fitting the restriction may take
> > some time.  However, I'm afraid that removing the restriction will soon
> > lead to more monstrosities like "idlw-complete-structtag.el".
> 
> To my understanding, 8.3 name restriction actually means
> that all filenames (in the same directory?) must be
> distinguished by the first 8 (or 7? 6?)  characters.  So,
> idlw-complete-structtag.el is ok unless there's another file
> that starts with "idlw-complete".  Is it right?

Well.. the traditional DOS file system hadn't room for more. Whether the
command line chopped off the name, I don't know.

The dot actually wasn't stored, the name had 8 characters plus three
chars for the ending.

Later Widows did incredible tricks to stitch together several directory
entries to make longer names possible.

> And, I remember that there were another filename restriction
> which limits the total length to 14 (or so) characters for
> some other system.  Does anyone remember the detail?

Good old classical UNIX. Ah, the times...

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHIHWoBcgs9XrR2kYRAsuQAJ9ly7L8e9HhpXXjhQ29WhQAqL1JKQCePfjA
u9ReO/Jg405fzSuel+isyvw=
=lAdb
-----END PGP SIGNATURE-----

Re: 8.3 filename restriction

[Eli Zaretskii]

> Date: Thu, 25 Oct 2007 10:53:29 +0000
> Cc: martin rudalics <rudalics@gmx.at>, eliz@gnu.org, emacs-devel@gnu.org,
> 	miles@gnu.org
> From: tomas@tuxteam.de
> 
> > To my understanding, 8.3 name restriction actually means
> > that all filenames (in the same directory?) must be
> > distinguished by the first 8 (or 7? 6?)  characters.  So,
> > idlw-complete-structtag.el is ok unless there's another file
> > that starts with "idlw-complete".  Is it right?
> 
> Well.. the traditional DOS file system hadn't room for more. Whether the
> command line chopped off the name, I don't know.

It's not the command line that chops the file names, it's the system
call itself.  Any DOS system call that accepts a file name first
canonicalizes it, and during that canonicalization the file name is
truncated to 8+3 limits.

Thus, if you later look for the chopped file name using the original
long name, it will be chopped again, and the file will be found.

Re: 8.3 filename restriction

[martin rudalics]

 > To my understanding, 8.3 name restriction actually means
 > that all filenames (in the same directory?) must be
 > distinguished by the first 8 (or 7? 6?)  characters.  So,
 > idlw-complete-structtag.el is ok unless there's another file
 > that starts with "idlw-complete".  Is it right?

"idlw-com" I believe.  It seems that Eli has a program to check the
8.3 validity of filenames.

Still "idlw-complete-structtag.el" is not ok with my understanding of a
readable file name.

 > And, I remember that there were another filename restriction
 > which limits the total length to 14 (or so) characters for
 > some other system.  Does anyone remember the detail?

The corresponding advice is still in the Elisp manual.

Re: 8.3 filename restriction

[Eli Zaretskii]

> Date: Thu, 25 Oct 2007 14:36:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC:  eliz@gnu.org,  emacs-devel@gnu.org,  miles@gnu.org
> 
> It seems that Eli has a program to check the 8.3 validity of
> filenames.

It's not my program, it's `doschk'.  You can find it on your favorite
GNU ftp server, in the `non-gnu/doschk' directory.

Re: 8.3 filename restriction

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Thu, 25 Oct 2007 16:45:34 +0900
> Cc: eliz@gnu.org, emacs-devel@gnu.org, miles@gnu.org
> 
> To my understanding, 8.3 name restriction actually means
> that all filenames (in the same directory?) must be
> distinguished by the first 8 (or 7? 6?)  characters.

8

> So, idlw-complete-structtag.el is ok unless there's another file
> that starts with "idlw-complete".  Is it right?

Yes, except that even another file that starts with a "idlw-complete"
would be okay, if its extension (the part after the period) is not
".el".

> And, I remember that there were another filename restriction
> which limits the total length to 14 (or so) characters for
> some other system.  Does anyone remember the detail?

That's SysV limitation; see `doschk', which will show both.

Re: 8.3 filename restriction

[Richard Stallman]

    And, I remember that there were another filename restriction
    which limits the total length to 14 (or so) characters for
    some other system.  Does anyone remember the detail?

Those systems are obsolete, and we do have some file names
that are longer than 14 chars.

Re: isearch multiple buffers

[Juri Linkov]

>>> isearch-multi.el seems like a better name for the new file.
>>
>> This name is too long.  What about isearch-x.el?  It has two
>> meanings: "x" means "isearch extra extensions", and "x" means
>> "cross-file, cross-buffer search".
>
> "isearch-multi" really isn't that long. and it's a great deal more clear than
> something generic like isearch-x...

"isearch-multi" has the same length as a file with the longest name in
the lisp directory "minibuf-eldef".  Since there were no problems with it,
I guess "isearch-multi" would be ok as well.

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

Re: isearch multiple buffers

[Juri Linkov]

>>>> isearch-multi.el seems like a better name for the new file.
>>>
>>> This name is too long.  What about isearch-x.el?  It has two
>>> meanings: "x" means "isearch extra extensions", and "x" means
>>> "cross-file, cross-buffer search".
>>
>> "isearch-multi" really isn't that long. and it's a great deal more clear than
>> something generic like isearch-x...
>
> "isearch-multi" has the same length as a file with the longest name in
> the lisp directory "minibuf-eldef".  Since there were no problems with it,
> I guess "isearch-multi" would be ok as well.

Installed under the name isearch-multi.el.

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

Re: isearch multiple buffers

[Richard Stallman]

    > isearch-multi.el seems like a better name for the new file.

    This name is too long.

We used to try to support the 14-char limit of some old Unix versions,
but those are all obsolete now.  We have other names which are longer
than that.

    However, isearch-x.el causes name conflicts with international/isearch-x.el.
    So alternative short names are isearchx.el or xisearch.el.

To reduce confusion, it is better to use a name which is more different
from the existing isearch-x.el.

I think isearch-multi.el is the best name to use.

Re: isearch multiple buffers

[Richard Stallman]

    > To make this a minor mode is undesirable because we do not want users
    > to enable and disable it.  I think it should simply be a subroution
    > for that major modes can call.

    It is likely that there are some users who won't like this feature.
    I think we shouldn't make it hard to disable.

You have already implemented an option to disable it, and select
a few different behaviors.  I think that is enough.

    Also this minor mode could provide an indication in the mode line
    (e.g. "X" or "X-Isearch" to mean cross-buffer search), so when the
    search goes to another file, it will not surprise users.

I do not quite follow.  Precisely when do you suggest displaying this
in the mode line?

(Moving to another buffer will show up in the mode line, of course.
So maybe that is plenty.)

Re: isearch multiple buffers

[Juri Linkov]

>     > To make this a minor mode is undesirable because we do not want users
>     > to enable and disable it.  I think it should simply be a subroution
>     > for that major modes can call.
>
>     It is likely that there are some users who won't like this feature.
>     I think we shouldn't make it hard to disable.
>
> You have already implemented an option to disable it, and select
> a few different behaviors.  I think that is enough.

There is no option to disable it.  There is only one option that specifies
where to pause the search.  So isearch-buffers-minor-mode seems like a good
option to disable it.

>     Also this minor mode could provide an indication in the mode line
>     (e.g. "X" or "X-Isearch" to mean cross-buffer search), so when the
>     search goes to another file, it will not surprise users.
>
> I do not quite follow.  Precisely when do you suggest displaying this
> in the mode line?
>
> (Moving to another buffer will show up in the mode line, of course.
> So maybe that is plenty.)

I think users should be aware of the active multi-buffer search, so moving
to another buffer will not be a surprise.  There are two places where this
indication can be added: in the mode line as a minor mode "lighter" string,
or/and as the prefix/suffix of the isearch message, e.g.:

I-search: search_string [Repeat for next buffer]
Multi-I-search: search_string [Repeat for next buffer]
X-I-search: search_string [Repeat for next buffer]
X-search: search_string [Repeat for next buffer]

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

RE: isearch multiple buffers

[Drew Adams]

> I think users should be aware of the active multi-buffer search, so moving
> to another buffer will not be a surprise.  There are two places where this
> indication can be added: in the mode line as a minor mode "lighter"
string,
> or/and as the prefix/suffix of the isearch message, e.g.:
>
> I-search: search_string [Repeat for next buffer]
> Multi-I-search: search_string [Repeat for next buffer]
> X-I-search: search_string [Repeat for next buffer]
> X-search: search_string [Repeat for next buffer]

Sorry if this is irrelevant (I haven't been following this thread) -

Looking briefly at the first message in the thread, I see
`isearch-buffers-next-buffer-function', which a user (or library) could
presumably define. And I see that that variable is set to
`change-log-isearch-next-buffer' for use with change logs - OK. I don't see
any other code that deals with defining the set of buffers to be searched.
(Again, I haven't followed closely, so I might have missed it.)

Is there no way for a user to interactively choose the buffers to search? If
so, how about at least letting a user search, say, all of the buffers marked
(with `>') in the Buffer List (C-x C-b), in the order they currently appear
in that list? That is, have the default value of
`isearch-buffers-next-buffer-function' be a function that provides this
behavior.

I think that if users could easily choose the buffers and the order (using
Buffer List and perhaps in other ways too), this would be more useful, and
users would be less surprised by the behavior.

Buffer List already offers one way to select buffers and order them. And if
this were available, it might also serve as an incentive to have one or more
buffer-menu commands that mark buffers according to a regexp - similar to
what `dired-mark-files-regexp' does.

buffer order [was: isearch multiple buffers]

[Drew Adams]

> From: Drew Adams Sent: Tuesday, October 23, 2007 5:33 PM
>
> how about at least letting a user search, say, all of the
> buffers marked (with `>') in the Buffer List (C-x C-b),
> in the order they currently appear in that list? That is, have
> the default value of `isearch-buffers-next-buffer-function'
> be a function that provides this behavior.
...
> Buffer List already offers one way to select buffers and order
> them. And if this were available, it might also serve as an
> incentive to have one or more buffer-menu commands that mark
> buffers according to a regexp - similar to
> what `dired-mark-files-regexp' does.

Some follow-up on this idea. I don't have time to work on this, but in case
someone else is interested -

You can now sort the Buffer List by any column, but you cannot define a
custom buffer order (there is currently no use for that). If you could, then
any function that operated on multiple buffers or upon the "next" or
"previous" buffer could take advantage of that order. Isearch is one
example.

For instance, if there were marked buffers in Buffer List, then
`next-buffer' would use the buffer order there, instead of the internal
buffer order: `next-buffer' would mean the next marked buffer after the
current buffer (which might or might not be marked). If no buffers were
marked, the behavior would be as it is now.

For this feature, users would need a way to define a custom order among the
marked buffers. There are various UI possibilities for this (drag-and-drop
etc.).  Here's one that's simple for the user.

1. Add a buffer-number (e.g. line number) column at the left (it could even
be part of the poorly named "CRM" column):

      Buffer      Size  Mode             File
 1. * *Messages*   232  Fundamental
 2 %  foobar     45391  Dired by name    /toto/foobar
 3>   tata.el    31416  Emacs Lisp       /toto/foobar/tata.el
 4    *scratch*    320  Lisp Interaction
 5 %  *Help*     10021  Help
 6>   titi.el     8754  Emacs Lisp       /toto/foobar/titi.el

2. Change the current bindings of keys `1' and `2' to something else, so
numbers can be used instead for reordering.

3.a. Bind keys so that typing a number followed by RET would set the number
of the buffer with the cursor to that input number. For example, typing `5
RET' would move the buffer with the cursor to line 5.

3.b. An alternative UI would be to let you edit the current buffer number
(e.g. change 5 to 2) for any number of lines, and then hit `g' to reorder
them all. That's the approach, for instance, of NetFlix when you reorder
your film queue. That can make it easier to move a group of buffers together
(less disorienting due to redisplay).

4. The order of the marked buffers in Buffer List would act as the current
buffer order; unmarked buffers would be ignored for operations that use
buffer order. In the example above, buffers tata.el and titi.el are marked,
so `next-buffer' and isearch would act on them in the order they appear
(tata.el, then titi.el).

I find such a UI easier than, say, dragging lines, especially when there are
lots of lines.

It would also be good to add some of the regexp and marking/unmarking
features that Dired has to Buffer List, the equivalent of
`dired-toggle-marks' and `dired-mark-files-regexp', for instance.

It would also be good to have commands to mark all buffers of a certain type
(e.g. by mode, time, size, file buffers). You could then, for instance, mark
all Emacs-Lisp buffers, then unmark a few of them that you don't want to
search, and so on.

WDOT?

Re: buffer order

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> It would also be good to add some of the regexp and marking/unmarking
> features that Dired has to Buffer List, the equivalent of
> `dired-toggle-marks' and `dired-mark-files-regexp', for instance.
>
> It would also be good to have commands to mark all buffers of a certain type
> (e.g. by mode, time, size, file buffers). You could then, for instance, mark
> all Emacs-Lisp buffers, then unmark a few of them that you don't want to
> search, and so on.

`ibuffer' already has that sort of thing (very well done UI too).

I dunno about buffer re-ordering; ibuffer has "b" (bury-buffer), which
is sometimes useful, but I can't really imagine using the elaborate
system you describe (I very rarely care about the exact ordering of
buffers).

-Miles

-- 
Fast, small, soon; pick any 2.

Re: isearch multiple buffers

[Juri Linkov]

> Is there no way for a user to interactively choose the buffers to search? If
> so, how about at least letting a user search, say, all of the buffers marked
> (with `>') in the Buffer List (C-x C-b), in the order they currently appear
> in that list? That is, have the default value of
> `isearch-buffers-next-buffer-function' be a function that provides this
> behavior.

Actually this suggests adding a new global mode isearch-buffers-mode.
When it is active and the global variable isearch-buffers-next-buffer-function
contains a function that return the next buffer from the set of marked
buffers from the buffer list, this could work.  But what to do when
isearch enters a ChangeLog buffer that has a buffer-local value
of isearch-buffers-next-buffer-function?  After leaving this buffer,
isearch will continue to search the next ChangeLog file, not the next
buffer from the buffer list.

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

RE: isearch multiple buffers

[Drew Adams]

> > Is there no way for a user to interactively choose the buffers
> > to search? If so, how about at least letting a user search,
> > say, all of the buffers marked (with `>') in the Buffer List
> > (C-x C-b), in the order they currently appear in that list?
> > That is, have the default value of
> > `isearch-buffers-next-buffer-function' be a function that
> > provides this behavior.
>
> Actually this suggests adding a new global mode isearch-buffers-mode.
> When it is active and the global variable
> isearch-buffers-next-buffer-function
> contains a function that return the next buffer from the set of marked
> buffers from the buffer list, this could work.  But what to do when
> isearch enters a ChangeLog buffer that has a buffer-local value
> of isearch-buffers-next-buffer-function?  After leaving this buffer,
> isearch will continue to search the next ChangeLog file, not the next
> buffer from the buffer list.

I probably don't understand you, but I don't see why another minor mode
would be needed or what the problem would be.

In my thinking, if buffers are marked in Buffer List, then they are always
used. To use another sequence of buffers, such as in a change log mode,
either the user or the mode code would need to unmark the Buffer List
buffers first. If it is the change-log code that does that, then it could
restore the marked buffers when it exits.

Alternatively, the mode could just bind isearch-buffers-next-buffer-function
for its own use. When it exits, the global binding would take effect. By
default, that would mean the marked buffers.

Or are you speaking of isearch crossing between buffers that have different
values of the function? In that case, the thing to do would be to work from
a snapshot: the function value when isearch started. IOW, not let isearch
use the current definition of the function, but the definition that was
current when it started searching.

Again, I'm probably missing your point. Please try again.

Re: isearch multiple buffers

[Richard Stallman]

    > You have already implemented an option to disable it, and select
    > a few different behaviors.  I think that is enough.

    There is no option to disable it.  There is only one option that specifies
    where to pause the search.

Let's rename that variable to isearch-multi-buffers,
and make nil mean don't search other buffers.
The value t could mean don't pause,
and the value `pause' could mean "All buffers".

I think this is more convenient than having two separate options.

      There are two places where this
    indication can be added: in the mode line as a minor mode "lighter" string,
    or/and as the prefix/suffix of the isearch message, e.g.:

Yes, but my question is WHEN to display this.  All the time
when the feature is enabled?  Only while searching?

    I-search: search_string [Repeat for next buffer]

"[Repeat for next buffer]" seems rather long; often it will not fit
in the line, and making the minibuffer grow a line would be a pain.

Re: isearch multiple buffers

[Juri Linkov]

>     There is no option to disable it.  There is only one option that
>     specifies where to pause the search.
>
> Let's rename that variable to isearch-multi-buffers,
> and make nil mean don't search other buffers.
> The value t could mean don't pause,
> and the value `pause' could mean "All buffers".

Sorry, this is not possible, because when this feature is active
it depends on other 4 variables:

  isearch-mode-hook
  isearch-search-fun-function
  isearch-wrap-function
  isearch-push-state-function

and isearch-buffers-minor-mode command sets these variables to values
that make this feature work.

>       There are two places where this
>     indication can be added: in the mode line as a minor mode "lighter" string,
>     or/and as the prefix/suffix of the isearch message, e.g.:
>
> Yes, but my question is WHEN to display this.  All the time
> when the feature is enabled?  Only while searching?

I think to display it only while searching, together with the string
"Isearch" in the mode line which is displayed only while searching.

>     I-search: search_string [Repeat for next buffer]
>
> "[Repeat for next buffer]" seems rather long; often it will not fit
> in the line, and making the minibuffer grow a line would be a pain.

I have no better idea now.

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

Re: isearch multiple buffers

[Richard Stallman]

    > Let's rename that variable to isearch-multi-buffers,
    > and make nil mean don't search other buffers.
    > The value t could mean don't pause,
    > and the value `pause' could mean "All buffers".

    Sorry, this is not possible,

Of course it is possible.

				 because when this feature is active
    it depends on other 4 variables:

      isearch-mode-hook
      isearch-search-fun-function
      isearch-wrap-function
      isearch-push-state-function

Sure, but that is not an obstacle.

    and isearch-buffers-minor-mode command sets these variables to values
    that make this feature work.

In my proposal, a different function (not a minor mode) sets these
variables.  isearch-multi-buffers will control how to use them.

Do you see it now?

Re: isearch multiple buffers

[Juri Linkov]

>     and isearch-buffers-minor-mode command sets these variables to values
>     that make this feature work.
>
> In my proposal, a different function (not a minor mode) sets these
> variables.  isearch-multi-buffers will control how to use them.

I'll try to find a general solution that will work also for searching
from the buffer list that Drew asked for.

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

RE: isearch multiple buffers

[Drew Adams]

> >     and isearch-buffers-minor-mode command sets these variables
> >     to values that make this feature work.
> >
> > In my proposal, a different function (not a minor mode) sets these
> > variables.  isearch-multi-buffers will control how to use them.
>
> I'll try to find a general solution that will work also for searching
> from the buffer list that Drew asked for.

Great - thanks. It need not follow what I said or even use the Buffer List.
The idea is to have some (interactive) way for a user to select the buffers
to be searched.

Re: isearch multiple buffers

[Juri Linkov]

>> I'll try to find a general solution that will work also for searching
>> from the buffer list that Drew asked for.
>
> Great - thanks. It need not follow what I said or even use the Buffer List.
> The idea is to have some (interactive) way for a user to select the buffers
> to be searched.

Selecting the buffers to be searched is not a problem.  I think the
*Buffer List* is a good interface to select them.  The question is
how to start multi-buffer isearch.  Imagine that you've marked a list
of buffers in the *Buffer List*.  How to start multi-buffer isearch now?
Should C-s start multi-buffer isearch in marked files, or should C-s
still allow searching for the string in the *Buffer List* (this is useful
for searching buffer names in the *Buffer List*).

This question is not limited to searching buffers from the *Buffer List*.
To search in multiple files one good user interface would be marking
a list of files in the dired buffer and starting multi-file isearch in
marked files - "Incremental Grep"!

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

Re: isearch multiple buffers

[Lennart Borgman (gmail)]

Juri Linkov wrote:
> Selecting the buffers to be searched is not a problem.  I think the
> *Buffer List* is a good interface to select them.  The question is
> how to start multi-buffer isearch.  Imagine that you've marked a list
> of buffers in the *Buffer List*.  How to start multi-buffer isearch now?
> Should C-s start multi-buffer isearch in marked files, or should C-s
> still allow searching for the string in the *Buffer List* (this is useful
> for searching buffer names in the *Buffer List*).

I believe most users would be surprised if C-s started multi-buffer 
isearch for the marked files. But it is still a good "mnemonic". Maybe 
ask the user if he/she wants to search the marked files?

RE: isearch multiple buffers

[Drew Adams]

> > Selecting the buffers to be searched is not a problem.  I think the
> > *Buffer List* is a good interface to select them.  The question is
> > how to start multi-buffer isearch.  Imagine that you've marked a list
> > of buffers in the *Buffer List*.  How to start multi-buffer isearch now?
> > Should C-s start multi-buffer isearch in marked files, or should C-s
> > still allow searching for the string in the *Buffer List* (this
> > is useful for searching buffer names in the *Buffer List*).
>
> I believe most users would be surprised if C-s started multi-buffer
> isearch for the marked files.

Until they learn about it. It's not exactly dangerous, but it could be
surprising the first time, if you haven't heard about it first.

> But it is still a good "mnemonic". Maybe
> ask the user if he/she wants to search the marked files?

I'm against that.

Asking the user for confirmation should be a last resort, reserved for
something that makes changes or has drastic consequences. It should not be
used just because we introduce a new feature that might surprise a user who
is not yet aware of it. If we did that each time, we would by now have
confirmation questions all over the place.

Re: isearch multiple buffers

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> Selecting the buffers to be searched is not a problem.  I think the
>>> *Buffer List* is a good interface to select them.  The question is
>>> how to start multi-buffer isearch.  Imagine that you've marked a list
>>> of buffers in the *Buffer List*.  How to start multi-buffer isearch now?
>>> Should C-s start multi-buffer isearch in marked files, or should C-s
>>> still allow searching for the string in the *Buffer List* (this
>>> is useful for searching buffer names in the *Buffer List*).
>> I believe most users would be surprised if C-s started multi-buffer
>> isearch for the marked files.
> 
> Until they learn about it. It's not exactly dangerous, but it could be
> surprising the first time, if you haven't heard about it first.

They would have to learn also what to use instead of C-s in that 
particular buffer.

>> But it is still a good "mnemonic". Maybe
>> ask the user if he/she wants to search the marked files?
> 
> I'm against that.
> 
> Asking the user for confirmation should be a last resort, reserved for
> something that makes changes or has drastic consequences. It should not be
> used just because we introduce a new feature that might surprise a user who
> is not yet aware of it. If we did that each time, we would by now have
> confirmation questions all over the place.
> 
> 

RE: isearch multiple buffers

[Drew Adams]

> >>> Selecting the buffers to be searched is not a problem.  I think the
> >>> *Buffer List* is a good interface to select them.  The question is
> >>> how to start multi-buffer isearch.  Imagine that you've marked a list
> >>> of buffers in the *Buffer List*.  How to start multi-buffer
> >>> isearch now? Should C-s start multi-buffer isearch in marked files,
> >>> or should C-s still allow searching for the string in the *Buffer
> >>> List* (this is useful for searching buffer names in the *Buffer
List*).
> >>
> >> I believe most users would be surprised if C-s started multi-buffer
> >> isearch for the marked files.
> >
> > Until they learn about it. It's not exactly dangerous, but it could be
> > surprising the first time, if you haven't heard about it first.
>
> They would have to learn also what to use instead of C-s in that
> particular buffer.

Not if, as I suggested, C-s in Buffer List did not search multiple files.

And not if, as I suggested as an alternative, they could toggle the buffer
marks off and then search, and the Buffer List help (`C-h m') explained
that.

In either of these cases, C-s in Buffer List would still search the buffer.

Re: isearch multiple buffers

[Juri Linkov]

>> >> I believe most users would be surprised if C-s started multi-buffer
>> >> isearch for the marked files.
>> >
>> > Until they learn about it. It's not exactly dangerous, but it could be
>> > surprising the first time, if you haven't heard about it first.
>>
>> They would have to learn also what to use instead of C-s in that
>> particular buffer.
>
> Not if, as I suggested, C-s in Buffer List did not search multiple files.
>
> And not if, as I suggested as an alternative, they could toggle the buffer
> marks off and then search, and the Buffer List help (`C-h m') explained
> that.
>
> In either of these cases, C-s in Buffer List would still search the buffer.

Maybe, starting multi-buffer isearch should depend on the point position
in the *Buffer List*, e.g. when point is on a mark in beginning of the line,
then start multi-buffer isearch, otherwise use normal isearch in the same buffer.

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

RE: isearch multiple buffers

[Drew Adams]

> Maybe, starting multi-buffer isearch should depend on the point
> position in the *Buffer List*, e.g. when point is on a mark in
> beginning of the line, then start multi-buffer isearch,
> otherwise use normal isearch in the same buffer.

I don't like that idea at all. Too complicated.

IMO, the position of the cursor should only matter to isearch in a buffer it
is searching. And it should not have any other significance except as the
search starting point

Let's keep it simple:

* Marked buffers means search those buffers. Always.
* Provide a buffer-menu command to toggle the marks on and off.

The only time you want to search the Buffer List itself is when you are in
that buffer. And if you are there, then you can hit the toggle key to turn
off the marks. That's one extra keystroke before you search the Buffer List
(and another keystroke to toggle the marks back on, if you want them on).

Searching the Buffer List will be a lot less common than searching multiple
buffers. Let's not complicate things for that infrequent (corner) use case -
two keystrokes is a fair price to pay.

Re: isearch multiple buffers

[Juri Linkov]

> The only time you want to search the Buffer List itself is when you are in
> that buffer. And if you are there, then you can hit the toggle key to turn
> off the marks. That's one extra keystroke before you search the Buffer List
> (and another keystroke to toggle the marks back on, if you want them on).
>
> Searching the Buffer List will be a lot less common than searching multiple
> buffers. Let's not complicate things for that infrequent (corner) use case -
> two keystrokes is a fair price to pay.

Not infrequent when C-s is used to find the name of the next buffer to mark.
Toggling marks after every search for the next name and marking it
would be a big hassle.

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

Re: isearch multiple buffers

[Richard Stallman]

    Maybe, starting multi-buffer isearch should depend on the point position
    in the *Buffer List*, e.g. when point is on a mark in beginning of the line,
    then start multi-buffer isearch, otherwise use normal isearch in the same buffer.

That would cause horrible confusion for people that do not know about
it.  Definitely not!

Re: isearch multiple buffers

[Juri Linkov]

>     Maybe, starting multi-buffer isearch should depend on the point position
>     in the *Buffer List*, e.g. when point is on a mark in beginning of the line,
>     then start multi-buffer isearch, otherwise use normal isearch in the same buffer.
>
> That would cause horrible confusion for people that do not know about
> it.  Definitely not!

Does this mean that you reject also an idea of using column positions to
restrict isearch to different fields in Dired.  I remember there was an
idea that when point is on e.g. file name column in Dired then search only
in file names, when point is on the time column then search only time strings.

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

Re: isearch multiple buffers

[Richard Stallman]

    Does this mean that you reject also an idea of using column positions to
    restrict isearch to different fields in Dired.

I think that would be very confusing for people not expecting it.  I
would not mind having it as an optional mode, but I don't like the
idea of making it the default.

Re: isearch multiple buffers

[Richard Stallman]

I don't like the idea of making C-s in a buffer list buffer (ordinary
or ibuffer) search into other buffers just because they are marked.

RE: isearch multiple buffers

[Drew Adams]

> I don't like the idea of making C-s in a buffer list buffer (ordinary
> or ibuffer) search into other buffers just because they are marked.

How about the suggestion that:

* C-s acts normally in Buffer List and Dired.

* Outside those buffers, C-s searches the buffers and file
  buffers that are marked in Buffer List and Dired

Isearch should provide some feedback, as already discussed, when it does a
multi-search, so that users are aware of what's happening.

The possible point of confusion will be for users who are unaware of the
connection between marking and isearch. The isearch doc would explain that,
but there is still room for confusion.

If that is thought to be too confusing, since users already have the habit
of marking buffers and files for other reasons, then perhaps a dedicated
mark could be used. Only users aware of this feature could then invoke it.

Re: isearch multiple buffers

[Juri Linkov]

>> I don't like the idea of making C-s in a buffer list buffer (ordinary
>> or ibuffer) search into other buffers just because they are marked.
>
> How about the suggestion that:
>
> * C-s acts normally in Buffer List and Dired.
>
> * Outside those buffers, C-s searches the buffers and file
>   buffers that are marked in Buffer List and Dired
>
> Isearch should provide some feedback, as already discussed, when it does a
> multi-search, so that users are aware of what's happening.
>
> The possible point of confusion will be for users who are unaware of the
> connection between marking and isearch. The isearch doc would explain that,
> but there is still room for confusion.
>
> If that is thought to be too confusing, since users already have the habit
> of marking buffers and files for other reasons,

Yes, this would be too confusing.

> then perhaps a dedicated mark could be used. Only users aware of this
> feature could then invoke it.

Using a dedicated mark requires creating a new keybinding and a new mark
to be able to mark with a dedicated mark.  Wouldn't it be simple just have
a dedicated key to start isearch on normal marks?

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

RE: isearch multiple buffers

[Drew Adams]

> Using a dedicated mark requires creating a new keybinding and a new mark
> to be able to mark with a dedicated mark.  Wouldn't it be simple just have
> a dedicated key to start isearch on normal marks?

OK by me.

Another choice point: If there are marks in both Dired and Buffer List,
should the same key search all of them? Likewise, for marks in multiple
Dired buffers.

I think so, but there might be a reason to treat Dired marks and Buffer List
marks separately (?).

And if marks in multiple buffers are treated together (same key), and we
provide for a way to order the marks in a given buffer, what is the overall
order among the marks in the various Dired buffers and Buffer List?

Re: isearch multiple buffers

[Luc Teirlinck]

   > Using a dedicated mark requires creating a new keybinding and a new mark
   > to be able to mark with a dedicated mark.  Wouldn't it be simple just have
   > a dedicated key to start isearch on normal marks?

   OK by me.

I have not followed this thread.  Just to make sure: I guess you all
know about the "A" command in Dired (although it uses regexps instead
of simple strings, it can easily be used for simple strings, of
course).

Sincerely,

Luc.

Re: isearch multiple buffers

[Juri Linkov]

>    > Using a dedicated mark requires creating a new keybinding and a new
>    > mark to be able to mark with a dedicated mark.  Wouldn't it be
>    > simple just have a dedicated key to start isearch on normal marks?
>
>    OK by me.
>
> I have not followed this thread.  Just to make sure: I guess you all
> know about the "A" command in Dired (although it uses regexps instead
> of simple strings, it can easily be used for simple strings, of
> course).

Yes, I agree that starting isearch from Dired should be like using "A".
But I think we shouldn't change the old behavior of "A" (search through
marked files using `M-,').  We should create a new key that will be
available in other modes as well.

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

RE: isearch multiple buffers

[Drew Adams]

> >> I'll try to find a general solution that will work also for searching
> >> from the buffer list that Drew asked for.
> >
> > Great - thanks. It need not follow what I said or even use the
> > Buffer List. The idea is to have some (interactive) way for a user
> > to select the buffers to be searched.
>
> Selecting the buffers to be searched is not a problem.

It is one problem. If you have implemented that, then it is one less to
address. ;-)

A second problem is letting users somehow order those marked buffers - for
searching and perhaps for other operations. When multiple buffers are
searched, users can sometimes care about the search order.

I mentioned some possibilities for this, but this question could probably
use additional thought and comment. Buffer List already lets you sort by
particular columns, but that's only a crude ordering wrt the marked buffers.

BTW, Buffer List still doesn't let you sort columns in both directions. I do
this in my library buff-menu+.el, but this sorting wasn't accepted for
Emacs. I think it's important to be able to reverse a sort order -
especially if we provide for sorting marked buffers. So if we implement a
way to let users order their marked buffers, we should also provide a key
binding for a command to reverse that order.

> I think the *Buffer List* is a good interface to select them.

I do too.

> The question is
> how to start multi-buffer isearch.  Imagine that you've marked a list
> of buffers in the *Buffer List*.  How to start multi-buffer isearch now?
> Should C-s start multi-buffer isearch in marked files, or should C-s
> still allow searching for the string in the *Buffer List* (this is useful
> for searching buffer names in the *Buffer List*).
>
> This question is not limited to searching buffers from the *Buffer List*.
> To search in multiple files one good user interface would be marking
> a list of files in the dired buffer and starting multi-file isearch in
> marked files - "Incremental Grep"!

Yes - More generally, I think that lots of Dired functionality could
usefully be ported to Buffer List. I mentioned some of this in a previous
post in this thread. In particular, from the moment that commands outside
Buffer List can take advantage of its marked files, the various mark
manipulations available in Dired become good candidates for Buffer List.

Good point about Buffer List searching - another question to deal with. I
don't have a good answer ready; it hadn't occurred to me.

One simple answer would be that to search within the Buffer List buffer you
would just remove all marks first. But if you have many buffers marked, you
might want to remove the marks only temporarily, during searching.

So a simple solution would be to provide a way in Buffer List to toggle the
`>' marks on and off (not the same as toggling marked-vs-unmarked, which
would also be useful). Then, to be able to search within the buffer, you
could temporarily turn off the marks, then turn them all on again with one
keystroke when you're done searching Buffer List. Likewise for Dired. That
might also be useful for other purposes.

Another possibility is to simply say that C-s within the Buffer List does
not do multi-buffer search - it simply searches within the Buffer List. To
search the marked buffers, you would then invoke `C-s' from outside the
Buffer List. That would be simpler and perhaps less confusing. Likewise for
Dired and file searching - `C-s' within Dired would not do multi-file
search; you would need to invoke `C-s' outside Dired for that.

The choice between these two approaches (among others perhaps) might depend
on how often we think users would want to search multiple buffers from
within Buffer List. If seldom, then the second is better; if often, then
perhaps the first is better.

Offhand, I'd say the second is sufficient: invoking `C-s' from within Buffer
List or Dired ignores the marked buffers/files - it doesn't do multi-buffer
search. But I like the idea of being able to toggle a set of marks on and
off. in fact, I'd like that to be available for all kinds of marks (choosing
the type of mark to toggle, perhaps, as we do for `dired-change-marks').

Re: isearch multiple buffers

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Yes - More generally, I think that lots of Dired functionality could
> usefully be ported to Buffer List. I mentioned some of this in a previous
> post in this thread.

"ibuffer" is already part of Emacs.

It's basically a much more featureful version of "list-buffers", and has
lots of marking/selecting/filtering commands.

-Miles
-- 
The key to happiness
 is having dreams.	[from a fortune cookie]

RE: isearch multiple buffers

[Drew Adams]

> > Yes - More generally, I think that lots of Dired functionality could
> > usefully be ported to Buffer List. I mentioned some of this in
> > a previous post in this thread.
>
> "ibuffer" is already part of Emacs.

I know that. So is Buffer List.

And Buffer List is covered in the Emacs manual - ibuffer is not even
mentioned, AFAICT.

> It's basically a much more featureful version of "list-buffers", and has
> lots of marking/selecting/filtering commands.

I still "think that lots of Dired functionality could usefully be ported to
Buffer List."  You need not agree. ;-)

When it's decided that Buffer List should be removed from Emacs because
ibuffer fills the bill, then maybe everything should focus on ibuffer.

That said, I don't see why ibuffer might not also be made to interface with
isearch.

Re: isearch multiple buffers

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> I still "think that lots of Dired functionality could usefully be ported to
> Buffer List."  You need not agree. ;-)

So why do you think that effort should be spent duplicating what ibuffer
has already done?

It's not like ibuffer is a different sort of interface from
list-buffers, it's essentially the same thing + lots of features.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

RE: isearch multiple buffers

[Drew Adams]

> > I still "think that lots of Dired functionality could usefully
> > be ported to Buffer List."  You need not agree. ;-)
>
> So why do you think that effort should be spent duplicating what ibuffer
> has already done?

I didn't say that effort should be spent duplicating what ibuffer already
has.

> It's not like ibuffer is a different sort of interface from
> list-buffers, it's essentially the same thing + lots of features.

I'm not against ibuffer.

I am for improving Buffer List, and for integrating it with isearch.

If someone wants to integrate Buffer List and ibuffer thoroughly, so that
everything in Buffer List is also in ibuffer, I'm not against that. In that
case, ibuffer would truly be just a superset of features, not also a
different UI. Today, it is not just a collection of additional features -
the UI is not the same, even if it looks similar.

The relation between Buffer List and ibuffer is not, for example, like that
between dired.el and dired-x.el. When you load dired-x.el, all you get is
more, not different. And Dired-X is also documented (in its own manual, and
mentioned in the Emacs manual).

If Buffer List and ibuffer were integrated, with no loss of Buffer List
features, then as long as the Buffer-List subset would continue to exist on
its own as the default behavior, I would still be in favor of integrating
isearch with that subset. Likewise, I would still be in favor of adding some
Dired features to that subset.

If the two are instead to remain separate, then I'm in favor of adding these
features to at least Buffer List, both if possible. If ibuffer were truly
built upon Buffer List, then there would be no extra effort in doing that
for both. If there is a choice of where to start to add isearch for multiple
marked buffers, I vote for Buffer List.

I am not in favor of integrating isearch only with ibuffer, which isn't even
mentioned in the manual. As I said, however, if ibuffer replaces Buffer List
altogether someday, that will be a different story.

As I also said, I'm not going to work on this anyway, so what I prefer is
probably not too important, beyond the possibility of influencing others.

Re: isearch multiple buffers

[Juri Linkov]

> Offhand, I'd say the second is sufficient: invoking `C-s' from within Buffer
> List or Dired ignores the marked buffers/files - it doesn't do multi-buffer
> search. But I like the idea of being able to toggle a set of marks on and
> off. in fact, I'd like that to be available for all kinds of marks (choosing
> the type of mark to toggle, perhaps, as we do for `dired-change-marks').

Another useful type of isearch in Buffer List or Dired is the search
restricted to the file name column.  This type of isearch should search
text only in file names.  But the same obstacle prevents installing this
useful feature: there is no clear way of starting this type of isearch.

This suggests adding a new prefix key for starting different isearch types.
I think a good mnemonic prefix key would be `M-s'.  So we could have the
following keybindings:

`M-s *' - start multi-buffer isearch in Buffer List
          or multi-file isearch in Dired;

`M-s |' - start isearch restricted to file names or buffer names

`M-s w' - start word search instead of using the ugly hack of
          typing C-w as the first keystroke in the minibuffer
          for editing the search string.

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

RE: isearch multiple buffers

[Drew Adams]

> Another useful type of isearch in Buffer List or Dired is the search
> restricted to the file name column.  This type of isearch should search
> text only in file names.  But the same obstacle prevents installing this
> useful feature: there is no clear way of starting this type of isearch.
>
> This suggests adding a new prefix key for starting different
> isearch types. I think a good mnemonic prefix key would be `M-s'.
> So we could have the following keybindings:
>
> `M-s *' - start multi-buffer isearch in Buffer List
>           or multi-file isearch in Dired;
>
> `M-s |' - start isearch restricted to file names or buffer names
>
> `M-s w' - start word search instead of using the ugly hack of
>           typing C-w as the first keystroke in the minibuffer
>           for editing the search string.

It's true that searching in Dired is not a corner case, unlike searching in
Buffer List.

That convinces me that the other alternative I suggested is better: C-s in
Dired or Buffer List should just ignore the marks. If you want a
multi-(file-)buffer search, then leave Dired or Buffer List before you hit
C-s. That's easy enough (C-x o). And the feedback is immediate, if you
forget, and a quick `C-g' leaves you where you started.

Why would adding special key bindings in Dired and Buffer List be better
than this?

The question of a key binding to search only file names in Dired has come up
before. We discussed generalizing that to the other Dired "fields", if they
ever get defined. I mentioned that I just hide everything except the file
names (one keystroke) before searching. It's true, however, that sometimes
you want to see the other info (e.g. date) at the same time.

A separate key binding is not a bad idea, I guess. I don't see that it needs
to have a dedicated prefix key, however. How about just `M-s'? Or `M-f' (for
file-name)? Or `F'? Or `f' (redundant binding)? Or `C-i' (for isearch), that
is, TAB (only half kidding)? Or `M-i'?

And I don't see that a key for file-name searching has any relation to
multiple-buffer isearch.

Likewise, the inconvenience of entering incremental word search is not
related to multi-buffer isearch. You once advocated an isearch binding for
that, and I agreed. In my own code, I use `C-s M-w', which is simple and
mnemonic. I think RMS opposed it because he wants `M-w' to end the search
and copy the region. If not that key, then another?

This question (incremental word search) comes up again and again - it came
up again yesterday on help-gnu-emacs. We've at least documented the
mysterious `C-s M-e C-w ... C-s' incantation now. I agree with you that it's
time we gave this a proper (simple) binding.

Re: isearch multiple buffers

[Juri Linkov]

> Likewise, the inconvenience of entering incremental word search is not
> related to multi-buffer isearch. You once advocated an isearch binding for
> that, and I agreed. In my own code, I use `C-s M-w', which is simple and
> mnemonic. I think RMS opposed it because he wants `M-w' to end the search
> and copy the region. If not that key, then another?

A key that doesn't cause conflicts with keys useful for exiting a search
is `C-s M-s w' or `C-s M-s M-w'.

> This question (incremental word search) comes up again and again - it came
> up again yesterday on help-gnu-emacs. We've at least documented the
> mysterious `C-s M-e C-w ... C-s' incantation now. I agree with you that it's
> time we gave this a proper (simple) binding.

A year ago I proposed the following isearch keybindings:

    (define-key isearch-mode-map "\M-sw" 'isearch-toggle-word)
    (define-key isearch-mode-map "\M-s\C-y" 'isearch-yank-kill)
    (define-key isearch-mode-map "\M-se" 'isearch-edit-string)
    (define-key isearch-mode-map "\M-sr" 'isearch-toggle-regexp)
    (define-key isearch-mode-map "\M-sc" 'isearch-toggle-case-fold)

and Richard replied:

    Using M-s as a prefix within Isearch is ok, because it isn't used much
    with other meanings.  So it would be ok for many such commands.
    However, it would not be ok as a replacement for M-y, because a two-char
    sequence would be too inconvenient for that job.  So we should not expect
    to move ALL special isearch commands onto the M-s prefix.  But we could
    move most of them.

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

Re: isearch multiple buffers

[Richard Stallman]

Perhaps the best way to specify a set of buffers to search as a unit
is with a fileset.

RE: isearch multiple buffers

[Drew Adams]

> Perhaps the best way to specify a set of buffers to search as a unit
> is with a fileset.

For those of us unfamiliar with that, could someone please summarize what
that is and how it would work in this context?

Re: isearch multiple buffers

[Juri Linkov]

>> Perhaps the best way to specify a set of buffers to search as a unit
>> is with a fileset.
>
> For those of us unfamiliar with that, could someone please summarize what
> that is and how it would work in this context?

See (info "(emacs)Filesets").

We definitely could implement isearch through filesets too, but it seems
defining a fileset just to search though some buffers is not the simplest
way to do this.

Since you suggested to start isearch from the *Buffer List*, you could
compare this method with starting isearch on filesets.

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

RE: isearch multiple buffers

[Drew Adams]

> >> Perhaps the best way to specify a set of buffers to search as a unit
> >> is with a fileset.
> >
> > For those of us unfamiliar with that, could someone please
> > summarize what that is and how it would work in this context?
>
> See (info "(emacs)Filesets").

I see. Thanks.

> We definitely could implement isearch through filesets too, but it seems
> defining a fileset just to search though some buffers is not the simplest
> way to do this.
>
> Since you suggested to start isearch from the *Buffer List*, you could
> compare this method with starting isearch on filesets.

From a cursory look, I'd say that Buffer List should be used. This is about
searching buffers, not necessarily file buffers.

However, there is a fileset command (`filesets-open') to visit all of the
files in a fileset. And if (some or) all are open, then another (new)
fileset command, say `filesets-mark-buffers', could mark the corresponding
buffers. That way, the interface to isearch would still be Buffer List, but
there would be an easy way to search all files in a fileset.

Users should not be obliged to define a fileset in order to search multiple
buffers, but if they happen to have a fileset defined, then the same
mechanism can be used to let them mark and search the buffers of its files.

How should command `filesets-mark-buffers' react if only some of a fileset's
files are open (visited)? A strict behavior would have it do nothing,
requiring you to first open them all. A lax behavior would simply mark all
existing buffers that correspond to files in the fileset, whether or not
they are all open.

I don't know if the lax behavior would be useful or confusing (or both). My
guess is that it could be useful: You can open all files in a fileset if you
want to, or you can (manually) open only some of them. Even in the latter
case, you could then mark all of those that are open, in one fell swoop. One
possibility is to let the user choose strict or lax behavior, via an option.

BTW, even in the case of searching multiple file buffers, the doc language
should speak of it that way, and not in terms of searching "files".
Searching a set of files does not imply visiting them. The language of
isearch should speak of searching buffers, not files, whether or not
filesets are involved.

Re: isearch multiple buffers

[Richard Stallman]

    > Perhaps the best way to specify a set of buffers to search as a unit
    > is with a fileset.

    For those of us unfamiliar with that, could someone please summarize what
    that is and how it would work in this context?

If the buffers to search are file-visiting buffers, you could make a
fileset in the ways described in the Filesets node of the Emacs
Manual, and specify treating it as a buffer search group.  Then, if
you do an isearch in one of the files in that fileset, it would
search them all.

Re: isearch multiple buffers

[Richard Stallman]

    > Yes, but my question is WHEN to display this.  All the time
    > when the feature is enabled?  Only while searching?

    I think to display it only while searching, together with the string
    "Isearch" in the mode line which is displayed only while searching.

If the added string will appear while searching, all of the time that
you spend in a search, that is ok as long as the string is short!

Re: isearch multiple buffers

[Richard Stallman]

    > I don't think that is the right UI for this feature.  I think the
    > search should fail when it can't find another occurrence in the
    > current buffer.  Then if you type C-s again it should go to the next
    > buffer which has an occurrence, and search there.

    The patch I proposed implements exactly the same behavior as
    you described.

In that case, it needs more comments in the code
so that people can see this is what it does.

    > The documentation of `isearch-buffers-next-buffer-function' should
    > clearly state what it means to search multiple buffers.

    (defvar isearch-buffers-next-buffer-function nil
      "Function to call to get the next buffer to search.

    When this variable is set to a function that returns a buffer, then
    after typing another C-s or C-r at a failing search, the search goes
    to the next buffer in the series and continues searching for the next
    occurrence.  The first argument of this function is the current buffer
    where the search is currently searching.  It defines the base buffer
    relative to which this function should find the next buffer.  When the
    isearch direction is backward (when isearch-forward is nil), this
    function should return the previous buffer to search. If the second
    argument of this function WRAP is non-nil, then it should return
    the first buffer in the series; and for the backward search, it
    should return the last buffer in the series.")

That is clear.  Good.

    (defvar isearch-buffers-current-buffer nil
      "The buffer where the search is currently searching.
    The value is nil when the search still is in the initial buffer.")

That is clear too.

Please write up the NEWS text, wait 4 days for other comments and
suggestions, then install it.

Re: isearch multiple buffers

[Juri Linkov]

Using isearch on multiple buffers is a feature I'd like to finish.
The current design prevents implementing global isearch operations
on a list of given files because isearch-buffers-minor-mode is a
minor mode and even after creating a global mode it will conflict
with buffers where isearch-buffers-minor-mode is enabled.

So I completely redesigned this feature, and the resulting patch is
below.  It provides now a clean and convenient interface for activating
Isearch on a set of files or buffers.  The only configurable variable
that defines what to search is `multi-isearch-next-buffer-function'.
In some modes like changelog-mode it is set to a buffer-local value, and
in global isearch on a list of files it is let-bound before starting
Isearch.  Its value it saved to an internal variable to avoid harmful
effects when Isearch arrives to a buffer with the different value of
this variable.  This never happens with a new patch since it operates
with the initial value of `multi-isearch-next-buffer-function'.

There are four new top commands:

    multi-isearch-forward-buffers
    multi-isearch-forward-buffers-regexp
    multi-isearch-forward-files
    multi-isearch-forward-files-regexp

whose single input argument accepts a list of files/buffers to search.
They then switch to the first file/buffer from this list and start
Isearch in it.

The first packages to use this feature are dired and buff-menu.
In Dired a new key `M-s A' (mnemonic for the existing `A') uses
Isearch to search marked Dired files.  In the Buffer List (C-x C-b)
\M-smb and \M-smr start string/regexp Isearch with all of the buffers
marked with `>' in the order they appear in that list.

This change also simplifies changelog-mode since now there is no need
to enable a minor mode.

It also adds the Isearch indication "multi" in the echo area when
multi-search is active.

And finally the package name prefix was changed from `isearch-buffers-'
to the better prefix `multi-isearch-' (by analogy with `multi-occur',
`multi-replace' etc) and the file name was renamed from `isearch-multi.el'
to `misearch.el' to avoid dos file name clashes with `isearch-x.el'.
So the whole file misearch.el is attaches below.

Index: lisp/dired.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired.el,v
retrieving revision 1.402
diff -c -r1.402 dired.el
*** lisp/dired.el	19 Jul 2008 23:55:41 -0000	1.402
--- lisp/dired.el	20 Jul 2008 00:31:27 -0000
***************
*** 1196,1201 ****
--- 1197,1203 ----
      (define-key map "~" 'dired-flag-backup-files)
      (define-key map "&" 'dired-flag-garbage-files)
      ;; Upper case keys (except !) for operating on the marked files
+     (define-key map "\M-sA" 'dired-do-isearch-regexp)
      (define-key map "A" 'dired-do-search)
      (define-key map "C" 'dired-do-copy)
      (define-key map "B" 'dired-do-byte-compile)

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.170
diff -c -r1.170 dired-aux.el
*** lisp/dired-aux.el	6 May 2008 07:57:30 -0000	1.170
--- lisp/dired-aux.el	20 Jul 2008 00:32:42 -0000
***************
*** 2276,2281 ****
--- 2276,2295 ----
  ;; Functions for searching in tags style among marked files.
  
  ;;;###autoload
+ (defun dired-do-isearch ()
+   "Search for a string through all marked files using Isearch."
+   (interactive)
+   (multi-isearch-forward-files
+    (dired-get-marked-files nil nil 'dired-nondirectory-p)))
+ 
+ ;;;###autoload
+ (defun dired-do-isearch-regexp ()
+   "Search for a regexp through all marked files using Isearch."
+   (interactive)
+   (multi-isearch-forward-files-regexp
+    (dired-get-marked-files nil nil 'dired-nondirectory-p)))
+ 
+ ;;;###autoload
  (defun dired-do-search (regexp)
    "Search through all marked files for a match for REGEXP.
  Stops when a match is found.

Index: lisp/buff-menu.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/buff-menu.el,v
retrieving revision 1.114
diff -c -r1.114 buff-menu.el
*** lisp/buff-menu.el	25 Jun 2008 15:13:03 -0000	1.114
--- lisp/buff-menu.el	20 Jul 2008 00:29:01 -0000
***************
*** 154,159 ****
--- 154,181 ----
      map)
    "Local keymap for `Buffer-menu-mode' buffers.")
  
+ (define-key Buffer-menu-mode-map "\M-smb" 'Buffer-menu-isearch-buffers)
+ (define-key Buffer-menu-mode-map "\M-smr" 'Buffer-menu-isearch-buffers-regexp)
+ 
+ (defun Buffer-menu-marked-buffers ()
+   "Return a list of buffers marked with the \\<Buffer-menu-mode-map>\\[Buffer-menu-mark] command."
+   (interactive)
+   (let (buffers)
+     (Buffer-menu-beginning)
+     (while (re-search-forward "^>" nil t)
+       (setq buffers (cons (Buffer-menu-buffer t) buffers)))
+     (nreverse buffers)))
+ 
+ (defun Buffer-menu-isearch-buffers ()
+   "Search for a string through all marked buffers using Isearch."
+   (interactive)
+   (multi-isearch-forward-buffers (Buffer-menu-marked-buffers)))
+ 
+ (defun Buffer-menu-isearch-buffers-regexp ()
+   "Search for a regexp through all marked buffers using Isearch."
+   (interactive)
+   (multi-isearch-forward-buffers-regexp (Buffer-menu-marked-buffers)))
+ 
  ;; Buffer Menu mode is suitable only for specially formatted data.
  (put 'Buffer-menu-mode 'mode-class 'special)
  
Index: lisp/add-log.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/add-log.el,v
retrieving revision 1.214
diff -c -r1.214 add-log.el
*** lisp/add-log.el	14 Jul 2008 08:15:30 -0000	1.214
--- lisp/add-log.el	20 Jul 2008 00:32:02 -0000
***************
*** 994,1006 ****
    (set (make-local-variable 'adaptive-fill-regexp) "\\s *")
    (set (make-local-variable 'font-lock-defaults)
         '(change-log-font-lock-keywords t nil nil backward-paragraph))
!   (set (make-local-variable 'isearch-buffers-next-buffer-function)
         'change-log-next-buffer)
    (set (make-local-variable 'beginning-of-defun-function) 
         'change-log-beginning-of-defun)
    (set (make-local-variable 'end-of-defun-function) 
!        'change-log-end-of-defun)
!   (isearch-buffers-minor-mode))
  
  (defun change-log-next-buffer (&optional buffer wrap)
    "Return the next buffer in the series of ChangeLog file buffers.
--- 994,1005 ----
    (set (make-local-variable 'adaptive-fill-regexp) "\\s *")
    (set (make-local-variable 'font-lock-defaults)
         '(change-log-font-lock-keywords t nil nil backward-paragraph))
!   (set (make-local-variable 'multi-isearch-next-buffer-function)
         'change-log-next-buffer)
    (set (make-local-variable 'beginning-of-defun-function) 
         'change-log-beginning-of-defun)
    (set (make-local-variable 'end-of-defun-function) 
!        'change-log-end-of-defun))
  
  (defun change-log-next-buffer (&optional buffer wrap)
    "Return the next buffer in the series of ChangeLog file buffers.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.322
diff -c -r1.322 isearch.el
*** lisp/isearch.el	25 Jun 2008 20:21:36 -0000	1.322
--- lisp/isearch.el	20 Jul 2008 00:33:35 -0000
***************
*** 2111,2116 ****
--- 2111,2117 ----
  		   (if isearch-wrapped "wrapped ")
  		   (if isearch-word "word " "")
  		   (if isearch-regexp "regexp " "")
+ 		   (if multi-isearch-next-buffer-current-function "multi " "")
  		   (if nonincremental "search" "I-search")
  		   (if isearch-forward "" " backward")
  		   (if current-input-method
***************
*** 2179,2187 ****
      (when pos1
        ;; When using multiple buffers isearch, switch to the new buffer here,
        ;; because `save-excursion' above doesn't allow doing it inside funcall.
!       (if (and isearch-buffers-next-buffer-function
! 	       (buffer-live-p isearch-buffers-current-buffer))
! 	  (switch-to-buffer isearch-buffers-current-buffer))
        (goto-char pos1))
      pos1))
  
--- 2180,2188 ----
      (when pos1
        ;; When using multiple buffers isearch, switch to the new buffer here,
        ;; because `save-excursion' above doesn't allow doing it inside funcall.
!       (if (and multi-isearch-next-buffer-current-function
! 	       (buffer-live-p multi-isearch-current-buffer))
! 	  (switch-to-buffer multi-isearch-current-buffer))
        (goto-char pos1))
      pos1))
  
;;; misearch.el --- isearch extensions for multi-buffer search

;; Copyright (C) 2007, 2008  Free Software Foundation, Inc.

;; Author: Juri Linkov <juri@jurta.org>
;; Keywords: matching

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This file adds more dimensions to the search space.  It implements
;; various features that extend isearch.  One of them is an ability to
;; search through multiple buffers.

;;; Code:

;;; Search multiple buffers

;;;###autoload (add-hook 'isearch-mode-hook 'multi-isearch-setup)

(defgroup multi-isearch nil
  "Using isearch to search through multiple buffers."
  :version "23.1"
  :group 'isearch)

(defcustom multi-isearch-search t
  "Non-nil enables searching multiple related buffers, in certain modes."
  :type 'boolean
  :version "23.1"
  :group 'multi-isearch)

(defcustom multi-isearch-pause t
  "A choice defining where to pause the search.
If the value is nil, don't pause before going to the next buffer.
If the value is `initial', pause only after a failing search in the
initial buffer.
If t, pause in all buffers that contain the search string."
  :type '(choice
	  (const :tag "Don't pause" nil)
	  (const :tag "Only in initial buffer" initial)
	  (const :tag "All buffers" t))
  :version "23.1"
  :group 'multi-isearch)

;;;###autoload
(defvar multi-isearch-next-buffer-function nil
  "Function to call to get the next buffer to search.

When this variable is set to a function that returns a buffer, then
after typing another \\[isearch-forward] or \\[isearch-backward] \
at a failing search, the search goes
to the next buffer in the series and continues searching for the
next occurrence.

The first argument of this function is the current buffer where the
search is currently searching.  It defines the base buffer relative to
which this function should find the next buffer.  When the isearch
direction is backward (when `isearch-forward' is nil), this function
should return the previous buffer to search.  If the second argument of
this function WRAP is non-nil, then it should return the first buffer
in the series; and for the backward search, it should return the last
buffer in the series.")

;;;###autoload
(defvar multi-isearch-next-buffer-current-function nil
  "The currently active function to get the next buffer to search.
Initialized from `multi-isearch-next-buffer-function' when
Isearch starts.")

;;;###autoload
(defvar multi-isearch-current-buffer nil
  "The buffer where the search is currently searching.
The value is nil when the search still is in the initial buffer.")

(defvar multi-isearch-orig-search-fun nil)
(defvar multi-isearch-orig-wrap nil)
(defvar multi-isearch-orig-push-state nil)

\f
;;;###autoload
(defun multi-isearch-setup ()
  "Set up isearch to search multiple buffers.
Intended to be added to `isearch-mode-hook'."
  (when (and multi-isearch-search
	     multi-isearch-next-buffer-function)
    (setq multi-isearch-current-buffer nil
	  multi-isearch-next-buffer-current-function
	  multi-isearch-next-buffer-function
	  multi-isearch-orig-search-fun
	  (default-value 'isearch-search-fun-function)
	  multi-isearch-orig-wrap
	  (default-value 'isearch-wrap-function)
	  multi-isearch-orig-push-state
	  (default-value 'isearch-push-state-function))
    (setq-default isearch-search-fun-function 'multi-isearch-search-fun
		  isearch-wrap-function       'multi-isearch-wrap
		  isearch-push-state-function 'multi-isearch-push-state)
    (add-hook 'isearch-mode-end-hook  'multi-isearch-end)))

(defun multi-isearch-end ()
  "Clean up the multi-buffer search after terminating isearch."
  (setq multi-isearch-current-buffer nil
	multi-isearch-next-buffer-current-function nil)
  (setq-default isearch-search-fun-function multi-isearch-orig-search-fun
		isearch-wrap-function       multi-isearch-orig-wrap
		isearch-push-state-function multi-isearch-orig-push-state)
  (remove-hook 'isearch-mode-end-hook  'multi-isearch-end))

(defun multi-isearch-search-fun ()
  "Return the proper search function, for isearch in multiple buffers."
  (lambda (string bound noerror)
    (let ((search-fun
	   ;; Use standard functions to search within one buffer
	   (cond
	    (isearch-word
	     (if isearch-forward 'word-search-forward 'word-search-backward))
	    (isearch-regexp
	     (if isearch-forward 're-search-forward 're-search-backward))
	    (t
	     (if isearch-forward 'search-forward 'search-backward))))
	  found buffer)
      (or
       ;; 1. First try searching in the initial buffer
       (let ((res (funcall search-fun string bound noerror)))
	 ;; Reset wrapping for all-buffers pause after successful search
	 (if (and res (eq multi-isearch-pause t))
	     (setq multi-isearch-current-buffer nil))
	 res)
       ;; 2. If the above search fails, start visiting next/prev buffers
       ;; successively, and search the string in them.  Do this only
       ;; when bound is nil (i.e. not while lazy-highlighting search
       ;; strings in the current buffer).
       (when (and (not bound) multi-isearch-search)
	 ;; If no-pause or there was one attempt to leave the current buffer
	 (if (or (null multi-isearch-pause)
		 (and multi-isearch-pause multi-isearch-current-buffer))
	     (condition-case nil
		 (progn
		   (while (not found)
		     ;; Find the next buffer to search
		     (setq buffer (funcall multi-isearch-next-buffer-current-function
					   buffer))
		     (with-current-buffer buffer
		       (goto-char (if isearch-forward (point-min) (point-max)))
		       (setq isearch-barrier (point) isearch-opoint (point))
		       ;; After visiting the next/prev buffer search the
		       ;; string in it again, until the function in
		       ;; multi-isearch-next-buffer-current-function raises
		       ;; an error at the beginning/end of the buffer sequence.
		       (setq found (funcall search-fun string bound noerror))))
		   ;; Set buffer for isearch-search-string to switch
		   (if buffer (setq multi-isearch-current-buffer buffer))
		   ;; Return point of the new search result
		   found)
	       ;; Return nil when multi-isearch-next-buffer-current-function fails
	       (error nil))
	   (signal 'search-failed (list string "Repeat for next buffer"))))))))

(defun multi-isearch-wrap ()
  "Wrap the multiple buffers search when search is failed.
Switch buffer to the first buffer for a forward search,
or to the last buffer for a backward search.
Set `multi-isearch-current-buffer' to the current buffer to display
the isearch suffix message [initial buffer] only when isearch leaves
the initial buffer."
  (if (or (null multi-isearch-pause)
	  (and multi-isearch-pause multi-isearch-current-buffer))
      (progn
	(switch-to-buffer
	 (setq multi-isearch-current-buffer
	       (funcall multi-isearch-next-buffer-current-function
			(current-buffer) t)))
	(goto-char (if isearch-forward (point-min) (point-max))))
    (setq multi-isearch-current-buffer (current-buffer))
    (setq isearch-wrapped nil)))

(defun multi-isearch-push-state ()
  "Save a function restoring the state of multiple buffers search.
Save the current buffer to the additional state parameter in the
search status stack."
  `(lambda (cmd)
     (multi-isearch-pop-state cmd ,(current-buffer))))

(defun multi-isearch-pop-state (cmd buffer)
  "Restore the multiple buffers search state.
Switch to the buffer restored from the search status stack."
  (unless (equal buffer (current-buffer))
    (switch-to-buffer (setq multi-isearch-current-buffer buffer))))

\f
;;; Global multi-buffer search invocations

(defvar multi-isearch-buffer-list nil)

(defun multi-isearch-next-buffer-from-list (&optional buffer wrap)
  "Return the next buffer in the series of ChangeLog file buffers.
This function is used for multiple buffers isearch.
A sequence of buffers is formed by ChangeLog files with decreasing
numeric file name suffixes in the directory of the initial ChangeLog
file were isearch was started."
  (let ((buffers (if isearch-forward
		     multi-isearch-buffer-list
		   (reverse multi-isearch-buffer-list))))
    (if wrap
	(car buffers)
      (cadr (member (or buffer (current-buffer)) buffers)))))

;;;###autoload
(defun multi-isearch-forward-buffers (buffers)
  "Start multi-buffer Isearch on a list of BUFFERS."
  (let ((multi-isearch-next-buffer-function
	 'multi-isearch-next-buffer-from-list)
	(multi-isearch-buffer-list buffers))
    (switch-to-buffer (car buffers))
    (goto-char (if isearch-forward (point-min) (point-max)))
    (isearch-forward)))

;;;###autoload
(defun multi-isearch-forward-buffers-regexp (buffers)
  "Start multi-buffer regexp Isearch on a list of BUFFERS."
  (let ((multi-isearch-next-buffer-function
	 'multi-isearch-next-buffer-from-list)
	(multi-isearch-buffer-list buffers))
    (switch-to-buffer (car buffers))
    (goto-char (if isearch-forward (point-min) (point-max)))
    (isearch-forward-regexp)))

\f
;;; Global multi-file search invocations

(defvar multi-isearch-file-list nil)

(defun multi-isearch-next-file-buffer-from-list (&optional buffer wrap)
  "Return the next buffer in the series of ChangeLog file buffers.
This function is used for multiple buffers isearch.
A sequence of buffers is formed by ChangeLog files with decreasing
numeric file name suffixes in the directory of the initial ChangeLog
file were isearch was started."
  (let ((files (if isearch-forward
		   multi-isearch-file-list
		 (reverse multi-isearch-file-list))))
    (find-file-noselect
     (if wrap
	 (car files)
       (cadr (member (buffer-file-name buffer) files))))))

;;;###autoload
(defun multi-isearch-forward-files (files)
  "Start multi-buffer Isearch on a list of FILES."
  (let ((multi-isearch-next-buffer-function
	 'multi-isearch-next-file-buffer-from-list)
	(multi-isearch-file-list files))
    (find-file (car files))
    (goto-char (if isearch-forward (point-min) (point-max)))
    (isearch-forward)))

;;;###autoload
(defun multi-isearch-forward-files-regexp (files)
  "Start multi-buffer regexp Isearch on a list of FILES."
  (let ((multi-isearch-next-buffer-function
	 'multi-isearch-next-file-buffer-from-list)
	(multi-isearch-file-list files))
    (find-file (car files))
    (goto-char (if isearch-forward (point-min) (point-max)))
    (isearch-forward-regexp)))

\f
(provide 'multi-isearch)

;; arch-tag: a6d38ffa-4d14-4e39-8ac6-46af9d6a6773
;;; misearch.el ends here

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

Re: isearch multiple buffers

[Miles Bader]

It would be nice to have this in ibuffer too...
-miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: isearch multiple buffers

[Juri Linkov]

> It would be nice to have this in ibuffer too...

Done in the patch below where I also renamed too long function
name `multi-isearch-forward-buffers' to `multi-isearch-buffers'
(and `multi-isearch-forward-files' to `multi-isearch-files').

As for key bindings, I don't know what does `A' in Dired stand for,
but it seems it has mnemonics for _a_ll files/buffers.  By analogy,
I've added two key bindings to ibuffer with the key `a' inside:

    M-s a C-s      ibuffer-do-isearch
    M-s a M-C-s    ibuffer-do-isearch-regexp

`C-s' and `M-C-s' at the end of the key sequence are very convenient.
They cause the feeling that these commands were run by typing standard
Isearch keys `C-s' and `M-C-s', and the user can immediately type the same
`C-s' again to repeat the search with the last search string and so on.

Index: lisp/ibuf-ext.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/ibuf-ext.el,v
retrieving revision 1.71
diff -c -r1.71 ibuf-ext.el
*** lisp/ibuf-ext.el	27 Jun 2008 10:34:50 -0000	1.71
--- lisp/ibuf-ext.el	20 Jul 2008 19:33:48 -0000
***************
*** 408,413 ****
--- 408,431 ----
     :modifier-p :maybe)
    (revert-buffer t t))
  
+ ;;;###autoload (autoload 'ibuffer-do-isearch "ibuf-ext")
+ (define-ibuffer-op ibuffer-do-isearch ()
+   "Perform a `isearch-forward' in marked buffers."
+   (:interactive ()
+    :opstring "searched in"
+    :complex t
+    :modifier-p :maybe)
+   (multi-isearch-buffers (ibuffer-get-marked-buffers)))
+ 
+ ;;;###autoload (autoload 'ibuffer-do-isearch-regexp "ibuf-ext")
+ (define-ibuffer-op ibuffer-do-isearch-regexp ()
+   "Perform a `isearch-forward-regexp' in marked buffers."
+   (:interactive ()
+    :opstring "searched regexp in"
+    :complex t
+    :modifier-p :maybe)
+   (multi-isearch-buffers-regexp (ibuffer-get-marked-buffers)))
+ 
  ;;;###autoload (autoload 'ibuffer-do-replace-regexp "ibuf-ext")
  (define-ibuffer-op replace-regexp (from-str to-str)
    "Perform a `replace-regexp' in marked buffers."

Index: lisp/ibuffer.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/ibuffer.el,v
retrieving revision 1.107
diff -c -r1.107 ibuffer.el
*** lisp/ibuffer.el	2 Jul 2008 13:28:01 -0000	1.107
--- lisp/ibuffer.el	20 Jul 2008 19:33:05 -0000
***************
*** 410,415 ****
--- 410,417 ----
      (define-key map (kbd "=") 'ibuffer-diff-with-file)
      (define-key map (kbd "j") 'ibuffer-jump-to-buffer)
      (define-key map (kbd "M-g") 'ibuffer-jump-to-buffer)
+     (define-key map (kbd "M-s a C-s") 'ibuffer-do-isearch)
+     (define-key map (kbd "M-s a M-C-s") 'ibuffer-do-isearch-regexp)
      (define-key map (kbd "DEL") 'ibuffer-unmark-backward)
      (define-key map (kbd "M-DEL") 'ibuffer-unmark-all)
      (define-key map (kbd "* *") 'ibuffer-unmark-all)
***************
*** 2376,2381 ****
--- 2378,2385 ----
    '\\[ibuffer-do-revert]' - Revert the marked buffers.
    '\\[ibuffer-do-toggle-read-only]' - Toggle read-only state of marked buffers.
    '\\[ibuffer-do-delete]' - Kill the marked buffers.
+   '\\[ibuffer-do-isearch]' - Do incremental search in the marked buffers.
+   '\\[ibuffer-do-isearch-regexp]' - Isearch for regexp in the marked buffers.
    '\\[ibuffer-do-replace-regexp]' - Replace by regexp in each of the marked
            buffers.
    '\\[ibuffer-do-query-replace]' - Query replace in each of the marked buffers.

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

Re: isearch multiple buffers

[Richard M Stallman]

    whose single input argument accepts a list of files/buffers to search.
    They then switch to the first file/buffer from this list and start
    Isearch in it.

It sounds good.  But I would like to point out that you are developing
yet another way of specifying a set of buffers and then acting on
those buffers.  In this case, the only kind of action is to search
them, at least so far.  Maybe others could be added.

There are other features of this general sort.  One of them is
filesets.  It was meant to provide a general solution for this kind of
thing, but it does not seem to have caught on much.  Perhaps it is not
smoothly enough integrated with the rest of Emacs.

Since you're starting on a new one, I wonder if you could turn this
into a convenient interface for doing various operations on the same
set of buffers.  If we succeed in doing this, once and for all, it will
be a major stap forward.

Re: isearch multiple buffers

[Juri Linkov]

>     whose single input argument accepts a list of files/buffers to search.
>     They then switch to the first file/buffer from this list and start
>     Isearch in it.
>
> It sounds good.  But I would like to point out that you are developing
> yet another way of specifying a set of buffers and then acting on
> those buffers.  In this case, the only kind of action is to search
> them, at least so far.  Maybe others could be added.

Many Emacs packages already have different ways of specifying a set
of buffers.  For instance, buff-menu.el and ibuffer.el use the key `m'
to mark a set of buffers, and other keys (like `x', `v') to operate
on a set of marked buffers.  I just added a new operation to the
existing packages that specify a set of buffers.

> There are other features of this general sort.  One of them is
> filesets.  It was meant to provide a general solution for this kind of
> thing, but it does not seem to have caught on much.  Perhaps it is not
> smoothly enough integrated with the rest of Emacs.

filesets.el is a promising package with presently poor user interface.
It displays a list of selected buffers only in the menu (not available
when the menu is turned off) or in a Customize buffer that displays one
customizable variable as a set of files.  I think a better way to display
filesets would be UI like provided by buffer-list, i.e. a special buffer
that displays a set of files and allows easily doing operations on them.

> Since you're starting on a new one, I wonder if you could turn this
> into a convenient interface for doing various operations on the same
> set of buffers.  If we succeed in doing this, once and for all, it will
> be a major step forward.

On the www site of the filesets project I've found a file filesets2.el
that contains features missing in the Emacs version of filesets.el.
These features provide integration with dired and ibuffer: there are
special commands to add a buffer from the ibuffer's buffer list to
a fileset, and to add dired marked buffers to a fileset.  I wonder
why the author didn't include them to Emacs.

Anyway, in the patch below I added Isearch operation on the filesets to
filesets.el.  And also fixed the existing multi-file query-replace
operation to use new keys to skip the current file and to do automatic
replacements in all remaining files (a feature implemented recently
in a separate patch).  It requires only adding `multi-query-replace-map'
and using the standard function to read query-replace arguments
`query-replace-read-args'.

Index: lisp/filesets.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/filesets.el,v
retrieving revision 1.39
diff -c -w -b -r1.39 filesets.el
*** lisp/filesets.el	27 Jun 2008 07:34:46 -0000	1.39
--- lisp/filesets.el	20 Jul 2008 19:35:03 -0000
***************
*** 565,576 ****
    :group 'filesets)
  
  (defcustom filesets-commands
!   `(("Query Replace"
!      query-replace
       (filesets-cmd-query-replace-getargs))
      ("Query Replace (regexp)"
!      query-replace-regexp
!      (filesets-cmd-query-replace-getargs))
      ("Grep <<selection>>"
       "grep"
       ("-n " filesets-get-quoted-selection " " "<<file-name>>"))
--- 565,582 ----
    :group 'filesets)
  
  (defcustom filesets-commands
!   `(("Isearch"
!      multi-isearch-files
!      (filesets-cmd-isearch-getargs))
!     ("Isearch (regexp)"
!      multi-isearch-files-regexp
!      (filesets-cmd-isearch-getargs))
!     ("Query Replace"
!      perform-replace
       (filesets-cmd-query-replace-getargs))
      ("Query Replace (regexp)"
!      perform-replace
!      (filesets-cmd-query-replace-regexp-getargs))
      ("Grep <<selection>>"
       "grep"
       ("-n " filesets-get-quoted-selection " " "<<file-name>>"))
***************
*** 1623,1628 ****
--- 1629,1636 ----
  	(when files
  	  (let ((fn   (filesets-cmd-get-fn cmd-name))
  		(args (filesets-cmd-get-args cmd-name)))
+ 	    (if (memq fn '(multi-isearch-files multi-isearch-files-regexp))
+ 		(apply fn args)
  	      (dolist (this files nil)
  		(save-excursion
  		  (save-restriction
***************
*** 1654,1660 ****
  						   (filesets-run-cmd--repl-fn
  						    this
  						    'list)))))))
! 			    (apply fn args))))))))))))))))
  
  (defun filesets-get-cmd-menu ()
    "Create filesets command menu."
--- 1662,1668 ----
  						     (filesets-run-cmd--repl-fn
  						      this
  						      'list)))))))
! 			      (apply fn args)))))))))))))))))
  
  (defun filesets-get-cmd-menu ()
    "Create filesets command menu."
***************
*** 1668,1683 ****
  ;;; sample commands
  (defun filesets-cmd-query-replace-getargs ()
    "Get arguments for `query-replace' and `query-replace-regexp'."
!   (let* ((from-string (read-string "Filesets query replace: "
! 				   ""
! 				   'query-replace-history))
! 	 (to-string  (read-string
! 		      (format "Filesets query replace %s with: " from-string)
! 		      ""
! 		      'query-replace-history))
! 	 (delimited  (y-or-n-p
! 		      "Filesets query replace: respect word boundaries? ")))
!     (list from-string to-string delimited)))
  
  (defun filesets-cmd-shell-command-getargs ()
    "Get arguments for `filesets-cmd-shell-command'."
--- 1676,1694 ----
  ;;; sample commands
  (defun filesets-cmd-query-replace-getargs ()
    "Get arguments for `query-replace' and `query-replace-regexp'."
!   (let ((common (query-replace-read-args "Filesets query replace" nil t)))
!     (list (nth 0 common) (nth 1 common) t nil (nth 2 common) nil
! 	  multi-query-replace-map)))
! 
! (defun filesets-cmd-query-replace-regexp-getargs ()
!   "Get arguments for `query-replace' and `query-replace-regexp'."
!   (let ((common (query-replace-read-args "Filesets query replace" t t)))
!     (list (nth 0 common) (nth 1 common) t t (nth 2 common) nil
! 	  multi-query-replace-map)))
! 
! (defun filesets-cmd-isearch-getargs ()
!   "Get arguments for `multi-isearch-files' and `multi-isearch-files-regexp'."
!   (list files))
  
  (defun filesets-cmd-shell-command-getargs ()
    "Get arguments for `filesets-cmd-shell-command'."

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

Re: isearch multiple buffers

[Richard M Stallman]

    Many Emacs packages already have different ways of specifying a set
    of buffers.  For instance, buff-menu.el and ibuffer.el use the key `m'
    to mark a set of buffers, and other keys (like `x', `v') to operate
    on a set of marked buffers.

This is making the existing problem worse!  We have so many different
ways of specifying a set of buffers, and each way corresponds to
different things you with the set.

The idea of filesets was to try to unify this -- to have various ways
of specifying a set, and indepedently, various things you can do with
a set.  The idea was to have something like the region: there are many
ways to set it, and many ways to use it.

Re: isearch multiple buffers

[Juri Linkov]

>     Many Emacs packages already have different ways of specifying a set
>     of buffers.  For instance, buff-menu.el and ibuffer.el use the key `m'
>     to mark a set of buffers, and other keys (like `x', `v') to operate
>     on a set of marked buffers.
>
> This is making the existing problem worse!  We have so many different
> ways of specifying a set of buffers, and each way corresponds to
> different things you with the set.
>
> The idea of filesets was to try to unify this -- to have various ways
> of specifying a set, and indepedently, various things you can do with
> a set.  The idea was to have something like the region: there are many
> ways to set it, and many ways to use it.

Filesets are more heavy-weight entities that have names and persist
across Emacs sessions.  OTOH, a set of marked buffers in the buffer list
is more quick to use and is transient that vanishes with killing the
buffer list.

I think we should not require from users using only persistent filesets.
We should provide both tightly integrated, with the buffer list
having commands to turn a transient set of marked buffers into a fileset
and vice versa.

Moreover, I think that all project-like packages (like recently discussed
packages that group a set of files into a project) should use filesets.

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

Re: isearch multiple buffers

[Thomas Link]

Hi,

Somebody put me on the cc list. I currently don't use emacs and (to my 
knowledge) I'm not??? the present maintainer of filesets but I'd like to 
comment on a few statements.

> filesets.el is a promising package with presently poor user interface.
> It displays a list of selected buffers only in the menu (not available
> when the menu is turned off) or in a Customize buffer that displays one
> customizable variable as a set of files.
AFAIK emacs provides a way to access menus from the command line. Also, 
filesets commands can be used without using the menu. IIRC you also have 
command line completion for the most important commands. On many (all?) 
platforms/GUI toolkits, the menu can be torn off. The menu will then 
remain open after having selected an item. Menus are quite versatile. 
Back then, it thus looked like a good idea to me to use menus.

> I think a better way to display
> filesets would be UI like provided by buffer-list, i.e. a special buffer
> that displays a set of files and allows easily doing operations on them.
>   
Today, I'd actually prefer this (or a similar) approach. The filesets 
data becomes quite big after a while and the data is kept in memory all 
the time. It thus seems preferable to display the information in an 
emacs buffer that can be unloaded when not in use. Actually, today I'd 
rather save the information as plain text file and implement the 
functionality as a "filesets mode". This would also provide for a way to 
easily split the filesets data into subsets. Emacs folding/outline mode 
could be used as rather low-diet ui.

Another option would be to integrate it with sidebar, which solves a not 
all too different problem. I have never used sidebar on the terminal though.

I assume though that most (new) users would prefer menus because most 
other applications they use work this way -- unless they have already 
reached the point where they use emacs for everything :-) .

> On the www site of the filesets project I've found a file filesets2.el
> that contains features missing in the Emacs version of filesets.el.
> These features provide integration with dired and ibuffer: there are
> special commands to add a buffer from the ibuffer's buffer list to
> a fileset, and to add dired marked buffers to a fileset.  I wonder
> why the author didn't include them to Emacs.
>   
Back then I used xemacs most of the time (mostly because compilation was 
slightly easier on cygwin/windows). xemacs has cl loaded by default, and 
I considered it preferable to use its functions. I don't think this 
version has been thoroughly tested with emacs.

Regards,
Thomas.

Re: isearch multiple buffers

[Juri Linkov]

> Somebody put me on the cc list. I currently don't use emacs and (to my
> knowledge) I'm not??? the present maintainer of filesets but I'd like to
> comment on a few statements.

Yes, according to the current file header you are not the present maintainer,
but I've put you on cc because I discovered that you have a new version
of filesets.el with more features that Emacs still lacks.

>> On the www site of the filesets project I've found a file filesets2.el
>> that contains features missing in the Emacs version of filesets.el.
>> These features provide integration with dired and ibuffer: there are
>> special commands to add a buffer from the ibuffer's buffer list to
>> a fileset, and to add dired marked buffers to a fileset.  I wonder
>> why the author didn't include them to Emacs.
>>
> Back then I used xemacs most of the time (mostly because compilation was
> slightly easier on cygwin/windows). xemacs has cl loaded by default, and
> I considered it preferable to use its functions. I don't think this
> version has been thoroughly tested with emacs.

Do you have any plans or ideas about updating filesets.el in Emacs
with a newer version you have?

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

Re: isearch multiple buffers

[Thomas Link]

>> Back then I used xemacs most of the time (mostly because compilation was
>> slightly easier on cygwin/windows). xemacs has cl loaded by default, and
>> I considered it preferable to use its functions. I don't think this
>> version has been thoroughly tested with emacs.
>>     
>
> Do you have any plans or ideas about updating filesets.el in Emacs
> with a newer version you have?
>   
Not in the near future (not because I'm against updating it but because 
I'm currently not able to test my current version). Feel free to rip out 
what you like. The last time I was contacted because of filesets I sent 
him my lastest version. If you're interested I can send you whatever I 
have. I'd assume though that it's the same version as on the website.