Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

Juri wrote:
> 'git ls-files' seems very fast, and moreover it outputs only relative
> paths, not absolute.

[ Nitpick: the GNU convention says these are "file names" rather than
  "paths".  ]

> On TAB completion with too long absolute paths
> the list of completions is quite unreadable.

That's why I was suggesting to start by stripping the common prefix.

> Also is it possible to complete only on file names, not paths?

With the `substring` completion style, yes.

> I think they should mirror everything that makes sense to use in the
> multifile project: project-occur, project-grep, ...

occur operates on buffers, not files, so I don't think mirroring it into
multifile- or project- makes much sense.  The corresponding command for
files is `grep`, so `project-grep` might make sense.

Dmitry wrote:
> Stefan, I think Juri is (maybe unknowingly) hinting that the package's name
> is a bit unfortunate.

I'm not particularly proud of that name.  All I wanted was the
multifile-query-replace feature, and "multifile" just was the least bad
name I could come up with.

That's also why I chose the name `project-query-replace` over
`multifile-query-replace` or anything like that: the fact that it uses
multifile.el is an internal detail, IMO.

Juri wrote:
> Either prefix multifile- or project- is fine, but not both at the same time.
> Or better just shorten to multi-.  We already have multi-isearch (not
> supporting project yet).

I chose "project-" so it actually says to which files it is supposed to
apply, compared to "multi-" or "multifile-" which just says that it
applies to several files but without clarifying which are those.

Dmitry wrote:
> OK, let me put it another way: "multifile" is just a package that implements
> a particular UI. It is in no way synonymous with "project". Maybe a better
> name for it would be something like bufferloop (suggestions welcome).

multifile loops over several *files* rather than buffers, so I'm fine with
"fileloop" or "iteratefiles", but "bufferloop" doesn't seem right.


        Stefan