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

[Juri Linkov]

>> '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".  ]

Sorry, I remembered the convention regarding file names and paths,
but I forgot how to name the base file name part as opposed to its
directory part.  Now I consulted in the Glossary it's called
File-Name Component.

>> 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 meant something more like switch-to-buffer, but that completes on
project file names (project-switch-to-buffer makes sense as well to
complete on already visited project buffers).

So a new command project-switch-to-file could complete on non-directory
file name components from the project.  And on duplicate file names
it could add a unique suffix '<sub/dir>' like is used to make buffer names
unique.  Then completions will show project file names in alphabetical order.

>> 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.

project-occur could operate only on visited project files
(but I doubt if this is useful).  project-rgrep is much more needed
to operate like rgrep, but without asking for file names and root directory.

>> 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.

"hulahoop" :)

Actually I think the existing names are already good enough: "multifile"
for the package that supports multifile operations, and "project"
for UI that operates on project files.