[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4727: 23.1; `multi-isearch-(files|buffers)(-regexp)'

From: Juri Linkov
Subject: bug#4727: 23.1; `multi-isearch-(files|buffers)(-regexp)'
Date: Fri, 16 Oct 2009 00:28:46 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu)

> 1. The doc strings of `multi-isearch-files(-regexp)' need to say that
> each of the FILES elements must be an absolute file name. I was trying
> to make it work with relative names, and I wasted a lot of time
> debugging. It was only when the debugger finally got to comparing
> `buffer-file-name' with the FILES element that I saw the problem.
> 2. Why not let these functions accept either absolute or relative file
> names?  If relative, they should be interpreted relative to
> `default-directory'.

Using relative file names will make these functions unreliable and
non-deterministic.  For instance, when you create a list of file names
in subdirectories relative to the current directory '("./dir1/file1"
"./dir2/file2") and multi-isearch visits file1 in the first subdir dir1,
then going to the next file "./dir2/file2" relative to the base dir
will fail in dir1.

However, we could convert relative file names to internal absolute
file names before starting multi-file Isearch.  So you will be able
to specify file names relative to the default directory where
multi-file Isearch was started.

> 3. Similarly, for `multi-isearch-buffers(-regexp)':
> a. The doc strings need to say explicitly that the BUFFERS must be
> live buffers, not their names.
> b. Why should the BUFFERS need to be buffers - why not also allow
> buffer names?
> The code is unnecessarily restrictive/brittle.

Similarly, we could convert buffer names to internal live buffers
before starting multi-buffer Isearch.

Juri Linkov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]