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

classic Classic list List threaded Threaded
95 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
Hi Stefan,

I've only noticed this change recently, hence this late email.

On 22.09.2018 18:46, Stefan Monnier wrote:

> +(cl-defgeneric project-files (project &optional dirs)
> +  "Return a list of files in directories DIRS in PROJECT.
> +DIRS is a list of absolute directories; it should be some
> +subset of the project roots and external roots."
> +  ;; This default implementation only works if project-file-completion-table
> +  ;; returns a "flat" completion table.

That sounds like a fair concern, never thought about it. Do we want to
have both as generic functions, though? People will have to take care to
keep them in sync.

> +  ;; FIXME: Maybe we should do the reverse: implement the default
> +  ;; `project-file-completion-table' on top of `project-files'.

Originally I figured that having the completion table be a basic part of
the propocol gives some benefits:

* If there's a background process that filters files faster than Emacs,
then it could actually provide faster file completion.
* Completion table is a "lazy" value, which can be handy.

Not sure if item 1 is ever going to materialize, and it would only help
in certain cases. But since file listing can be slow sometimes, should
we consider having some other kind of return value, for performance?

Say, a stream of some kind. It could be handy for multifile-based
commands, since they only show one file at a time. Ideally, though, the
stream should be easily composable with external tools like Grep.

Ideas?

> +  (all-completions
> +   "" (project-file-completion-table
> +       project (or dirs (project-roots project)))))
> +
>   (defgroup project-vc nil
>     "Project implementation using the VC package."
>     :version "25.1"
> @@ -389,12 +401,17 @@ recognized."
>     ;; removing it when it has no matches.  Neither seems natural
>     ;; enough.  Removal is confusing; early expansion makes the prompt
>     ;; too long.
> -  (let* ((new-prompt (if default
> +  (let* (;; (initial-input
> +         ;;  (let ((common-prefix (try-completion "" collection)))
> +         ;;    (if (> (length common-prefix) 0)
> +         ;;        (file-name-directory common-prefix))))

Interesting suggestion if we only want to use this function in
project-find-file. I see the same effect, though, if I just press TAB.

Or I can right away type a unique file name, press TAB and see it
completed to the full file name. I wonder what other people think; I
still haven't managed to get off Ido, personally.

> +;;;###autoload
> +(defun project-search (regexp)

> +;;;###autoload
> +(defun project-query-replace (from to)

I'm not a fan of these names. I know they kind of mirror what we already
have in the dired- namespace, but can't we do better? Maybe rename
dired-do-search and dired-do-query-replace-regexp later as well.

I think it's going to be hard for a user to differentiate between
project-find-regexp and project-search. And that they might also have a
guess that the latter "searches" for a project among the opened ones.

Should we move both commands to the multifile package and name them, for
instance, multifile-project-find-regexp (or multifile-project-search)
and multifile-project-query-replace-regexp?

Originally we thought that this kind of UI preference would be enacted
using xref-show-xrefs-function, but apparently that's not so easy to do.

Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
>> +(cl-defgeneric project-files (project &optional dirs)
>> +  "Return a list of files in directories DIRS in PROJECT.
>> +DIRS is a list of absolute directories; it should be some
>> +subset of the project roots and external roots."
>> +  ;; This default implementation only works if project-file-completion-table
>> +  ;; returns a "flat" completion table.
>
> That sounds like a fair concern, never thought about it. Do we want to have
> both as generic functions, though? People will have to take care to keep
> them in sync.

Not sure what you mean by "keep them in sync".

> Not sure if item 1 is ever going to materialize, and it would only help in
> certain cases. But since file listing can be slow sometimes, should we
> consider having some other kind of return value, for performance?
> Say, a stream of some kind. It could be handy for multifile-based commands,
> since they only show one file at a time. Ideally, though, the stream should
> be easily composable with external tools like Grep.
>
> Ideas?

We could define it to return a *sequence*, so it can either return
a list, or a stream, or an array, ..

>> -  (let* ((new-prompt (if default
>> +  (let* (;; (initial-input
>> +         ;;  (let ((common-prefix (try-completion "" collection)))
>> +         ;;    (if (> (length common-prefix) 0)
>> +         ;;        (file-name-directory common-prefix))))
>
> Interesting suggestion if we only want to use this function in
> project-find-file. I see the same effect, though, if I just press TAB.

Having to type TAB makes the interface quite different from just
`find-file`.

> Or I can right away type a unique file name, press TAB and see it completed
> to the full file name. I wonder what other people think; I still haven't
> managed to get off Ido, personally.

Indeed, that's why that code is commented out: inserting the common
prefix is a bad idea for substring completion.

I think TRT is to take the above common-prefix-directory, add it to the
prompt, and remove it from each completion candidate: this will keep
substring completion working correctly (and working even better since
it won't uselessly find matches in the common prefix) and will also
clarify where the search takes place.

>> +;;;###autoload
>> +(defun project-search (regexp)
>> +;;;###autoload
>> +(defun project-query-replace (from to)
>
> I'm not a fan of these names. I know they kind of mirror what we already
> have in the dired- namespace, but can't we do better?

If you have better ideas, by all means change them.

> I think it's going to be hard for a user to differentiate between
> project-find-regexp and project-search. And that they might also have
> a guess that the latter "searches" for a project among the opened ones.

Not only I'm not wedded to those names, but of those two commands the
one that I use is project-query-replace.  I only added the other one
"for completeness".

> Should we move both commands to the multifile package and name them, for
> instance, multifile-project-find-regexp (or multifile-project-search) and
> multifile-project-query-replace-regexp?

No opinion on that either.

> Originally we thought that this kind of UI preference would be enacted using
> xref-show-xrefs-function, but apparently that's not so easy to do.

I don't know what such an approach would look like.


        Stefan


Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 26.12.2018 22:13, Stefan Monnier wrote:

>> That sounds like a fair concern, never thought about it. Do we want to have
>> both as generic functions, though? People will have to take care to keep
>> them in sync.
>
> Not sure what you mean by "keep them in sync".

Making sure to implement them in a compatible fashion. My point is, it's
probably better to leave just one if the other can (almost?) always be
efficiently implemented in terms of it.

> We could define it to return a *sequence*, so it can either return > a list, or a stream, or an array, ..

OK, so we can turn it into a completion table simply by calling (seq-map
#'identity files). Though there might be a better choice.

I wonder if we could efficiently implement project-find-regexp on top of
a sequence like that, i.e. pipe to Grep with little overhead.

And I'm thinking about this because there can be faster ways to list all
files in the project than 'find' (e.g. 'git ls-files'). But
xref-collect-matches should know nothing about 'git ls-files'.

And by streams you mean stream.el in ELPA, right? It mentions "IO
streams" but has no examples of that. Guess it's still something to R&D.

> I think TRT is to take the above common-prefix-directory, add it to the
> prompt, and remove it from each completion candidate: this will keep
> substring completion working correctly (and working even better since
> it won't uselessly find matches in the common prefix) and will also
> clarify where the search takes place.

Makes sense. Should work as long as '/' is in
completion-pcm-word-delimiters.

But this approach also needs the completion table to be flat, right?

> Not only I'm not wedded to those names, but of those two commands the
> one that I use is project-query-replace.

This one also needs a docstring update (note to self or whoever).

>> Should we move both commands to the multifile package and name them, for
>> instance, multifile-project-find-regexp (or multifile-project-search) and
>> multifile-project-query-replace-regexp?
>
> No opinion on that either.

OK, so unless somebody objects I'd like to move them to
lisp/multifile.el and rename to multifile-project-find-regexp and
multifile-project-query-replace-regexp.

>> Originally we thought that this kind of UI preference would be enacted using
>> xref-show-xrefs-function, but apparently that's not so easy to do.
>
> I don't know what such an approach would look like.

Hmm, maybe it's not easily compatible with multifile, since this
function is passed a list of hits already. Not a list of files.

Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
>> Not sure what you mean by "keep them in sync".
> Making sure to implement them in a compatible fashion.  My point is, it's
> probably better to leave just one if the other can (almost?) always be
> efficiently implemented in terms of it.

Right.  But I'm not sure which one should be the "canonical" one.
Currently, the "canonical" one is the completion-table, and the
files-list is defined based on it (while it's current definition only
handles flat completion, that could be improved).

> I wonder if we could efficiently implement project-find-regexp on top of
> a sequence like that, i.e. pipe to Grep with little overhead.

I can't see any reason why not.

> And by streams you mean stream.el in ELPA, right?

Indeed.  Also known as lazy lists.

>> I think TRT is to take the above common-prefix-directory, add it to the
>> prompt, and remove it from each completion candidate: this will keep
>> substring completion working correctly (and working even better since
>> it won't uselessly find matches in the common prefix) and will also
>> clarify where the search takes place.
>
> Makes sense. Should work as long as '/' is in
> completion-pcm-word-delimiters.
>
> But this approach also needs the completion table to be flat, right?

Not necessarily: we could accumulate the prefix as long as it's the
sole completion.


        Stefan

Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Dmitry Gutov
> And I'm thinking about this because there can be faster ways to list all
> files in the project than 'find' (e.g. 'git ls-files'). But
> xref-collect-matches should know nothing about 'git ls-files'.

'git ls-files' seems very fast, and moreover it outputs only relative
paths, not absolute.   On TAB completion with too long absolute paths
the list of completions is quite unreadable.

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

> OK, so unless somebody objects I'd like to move them to lisp/multifile.el
> and rename to multifile-project-find-regexp and
> multifile-project-query-replace-regexp.

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

Since there is query-replace-regexp, multifile-project-query-replace-regexp
makes sense.

But I don't know to what existing command corresponds 'project-search'?
I tried it on the Emacs source tree, but it failed with:

Debugger entered--Lisp error: (compression-error "Opening input file" "error uncompressing empty.zz.gz" "emacs/test/manual/etags/a-src/empty.zz.gz")

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 27.12.2018 22:33, Juri Linkov wrote:

> 'git ls-files' seems very fast, and moreover it outputs only relative
> paths, not absolute.   On TAB completion with too long absolute paths
> the list of completions is quite unreadable.

That's a question of presentation, not data. And Stefan gave some
pertinent suggestions in this thread.

Actually, if we didn't manage to have 'find' and 'git ls-files' output
in the same format as each other, that would be a problem.

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

You can input a file name and press RET. If the name is unique, it will
be completed fully. Isn't this the best possible scenario?

>> OK, so unless somebody objects I'd like to move them to lisp/multifile.el
>> and rename to multifile-project-find-regexp and
>> multifile-project-query-replace-regexp.
>
> I think they should mirror everything that makes sense to use in the
> multifile project: project-occur, project-grep, ...

"multifile project"

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

Every project is multifile (with very rare exceptions). It's not about that.

Or maybe I don't understand the suggestion.

I'm find with adding project-occur, whatever it might do. As for
project-grep, we have project-find-regexp already. I think it's a better
name.

> But I don't know to what existing command corresponds 'project-search'?
> I tried it on the Emacs source tree, but it failed with:

It's analogous to tags-search. Which is also an unfortunate name, IMO.

> Debugger entered--Lisp error: (compression-error "Opening input file" "error uncompressing empty.zz.gz" "emacs/test/manual/etags/a-src/empty.zz.gz")

Does M-x project-find-regexp work in the same situation?

Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> Also is it possible to complete only on file names, not paths?
>
> You can input a file name and press RET. If the name is unique, it will be
> completed fully. Isn't this the best possible scenario?

Rather it completes on path components too, not only on file names.
Makes more difficult to match part of the file name when the same substring
occurs in the path.

>>> OK, so unless somebody objects I'd like to move them to lisp/multifile.el
>>> and rename to multifile-project-find-regexp and
>>> multifile-project-query-replace-regexp.
>>
>> I think they should mirror everything that makes sense to use in the
>> multifile project: project-occur, project-grep, ...
>
> "multifile project"
>
> Stefan, I think Juri is (maybe unknowingly) hinting that the package's name
> is a bit unfortunate.
>
> Every project is multifile (with very rare exceptions). It's not about that.

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

> Does M-x project-find-regexp work in the same situation?

I see that M-x project-find-regexp is like occur, so a better name would be
M-x project-occur.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Stefan Monnier
On 27.12.2018 16:39, Stefan Monnier wrote:

> Right.  But I'm not sure which one should be the "canonical" one.
> Currently, the "canonical" one is the completion-table, and the
> files-list is defined based on it (while it's current definition only
> handles flat completion, that could be improved).

A flat list is a simpler structure, so we'd choose it by default. Less
margin of error for implementors.

What are the main benefits of making the completion table overridable?

The potential of an external process doing the matching for us (and
doing it faster on nonempty inputs)?

Returning completion table metadata?

>> I wonder if we could efficiently implement project-find-regexp on top of
>> a sequence like that, i.e. pipe to Grep with little overhead.
>
> I can't see any reason why not.

I gave it a try, to reimplement project-find-regexp based on
project-files is a straightforward way, pushed to branch
scratch/project-files-pipe-grep.

Unfortunately, I couldn't exactly reach the performance of the find+grep
version. Try:

(benchmark 10 '(project-find-regexp "xyz1"))
=> 5.60s
(benchmark 10 '(project-files-pipe-grep "xyz1"))
=> 6.31s or 6.10s, depending on the version

Any suggestions?

This is without streams, but I'm now more skeptical about their possible
performance benefits in this scenario.

>> But this approach also needs the completion table to be flat, right?
>
> Not necessarily: we could accumulate the prefix as long as it's the
> sole completion.
I think I see what you mean.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Juri Linkov-2
On 28.12.2018 1:45, Juri Linkov wrote:

> Rather it completes on path components too, not only on file names.
> Makes more difficult to match part of the file name when the same substring
> occurs in the path.

But base file names can also have duplicates, right?

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

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

>> Does M-x project-find-regexp work in the same situation?
>
> I see that M-x project-find-regexp is like occur, so a better name would be
> M-x project-occur.

I can see where you're coming from, but we've already discussed that it
has different behavior from Occur. And it uses different data sources.

I agree that some unification might be in order, but naming things the
same won't cut it.

Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Juri Linkov-2
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


Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Stefan Monnier
On 27.12.2018 16:39, Stefan Monnier wrote:

>>> I think TRT is to take the above common-prefix-directory, add it to the
>>> prompt, and remove it from each completion candidate: this will keep
>>> substring completion working correctly (and working even better since
>>> it won't uselessly find matches in the common prefix) and will also
>>> clarify where the search takes place.

Now done in master.

But I think it illustrates a common completion pitfall we have:

1. M-x project-find-file (while inside Emacs sources)
2. Type 'GNU', then TAB, then TAB again.
3. It completes to 'GNUmakefile' and insists it is 'Sole completion'.
Even though e.g. etc/GNUS-USERS exists.

> Not necessarily: we could accumulate the prefix as long as it's the
> sole completion.

I've decided against writing a wrapper that pipes the whole collection
through 'substring' every time it is called. So for now it also requires
a flat collection.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Stefan Monnier
On 28.12.2018 20:07, Stefan Monnier wrote:
> 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.

It is an intentional choice as well, however.

At least, like dired-do-find-regexp-and-replace demonstrates, the xref
UI can also be used for search and replace.

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

"fileloop" sounds good. Other similar options I had are iterfile and
filiter.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Dmitry Gutov
On 29.12.2018 3:27, Dmitry Gutov wrote:

> But I think it illustrates a common completion pitfall we have:
>
> 1. M-x project-find-file (while inside Emacs sources)
> 2. Type 'GNU', then TAB, then TAB again.
> 3. It completes to 'GNUmakefile' and insists it is 'Sole completion'.
> Even though e.g. etc/GNUS-USERS exists.

Should be fixed now.

Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> But I think it illustrates a common completion pitfall we have:
>>
>> 1. M-x project-find-file (while inside Emacs sources)
>> 2. Type 'GNU', then TAB, then TAB again.
>> 3. It completes to 'GNUmakefile' and insists it is 'Sole
>> completion'. Even though e.g. etc/GNUS-USERS exists.
>
> Should be fixed now.

Thanks, now completion is much better.  I noticed another problem
with partial-completion - it doesn't support wildcards in the file name:

1. M-x project-find-file RET
2. Type 'm*file', then TAB, to find lisp/multifile.el
3. It completes only to the files where directory matches 'm'
   and file name matches 'file'.

Also it seems impossible to separate words by the space character,
e.g. 'm file'.

Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Stefan Monnier
>> '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.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Juri Linkov-2
On 30.12.2018 0:54, Juri Linkov wrote:

> Thanks, now completion is much better.  I noticed another problem
> with partial-completion - it doesn't support wildcards in the file name:
>
> 1. M-x project-find-file RET
> 2. Type 'm*file', then TAB, to find lisp/multifile.el
Seems like this would require some extra support from the completion
table. Patches welcome.

> 3. It completes only to the files where directory matches 'm'
>     and file name matches 'file'.
>
> Also it seems impossible to separate words by the space character,
> e.g. 'm file'.

I'm not sure how that input should be interpreted. Does find-file
support it?

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Juri Linkov-2
On 30.12.2018 1:02, Juri Linkov wrote:

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

You can already type 'sub/dir' and press TAB to see it completed.
Especially if it's unique.

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

We already have project-find-regexp. Why bother?

> "hulahoop" :)

I don't mind.

> Actually I think the existing names are already good enough: "multifile"
> for the package that supports multifile operations,

It's not the only package that "supports multifile operations". xref
does it as well (and arguably better), and also occur and grep, as some
examples.

> and "project"
> for UI that operates on project files.

project is not a UI, it uses one of the other packages for UIs.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Dmitry Gutov
On 28.12.2018 6:45, Dmitry Gutov wrote:

> I gave it a try, to reimplement project-find-regexp based on
> project-files is a straightforward way, pushed to branch
> scratch/project-files-pipe-grep.
>
> Unfortunately, I couldn't exactly reach the performance of the find+grep
> version. Try:
>
> (benchmark 10 '(project-find-regexp "xyz1"))
> => 5.60s
> (benchmark 10 '(project-files-pipe-grep "xyz1"))
> => 6.31s or 6.10s, depending on the version
>
> Any suggestions?

Anybody?

IMO, having this work without performance regression (or as little as
possible) is a prerequisite to using 'git ls-files' in the vc project
backend.

Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Dmitry Gutov <[hidden email]>
> Date: Mon, 31 Dec 2018 14:42:52 +0300
> Cc: Juri Linkov <[hidden email]>, [hidden email]
>
> On 28.12.2018 6:45, Dmitry Gutov wrote:
> > Any suggestions?
>
> Anybody?

Based on my experience, you expected responses too soon, especially
given we are in holiday season.  Suggest to wait for at least one more
week.

(Not that I necessarily see a reason for worries given the relatively
small difference in timing.)

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Juri Linkov-2
> 2. Type 'm*file', then TAB, to find lisp/multifile.el
> 3. It completes only to the files where directory matches 'm'
>    and file name matches 'file'.

I think `m*file` will match anything that *starts* with `m` and with `file`
somewhere afterwards.  So it won't match `lisp/multifile.el` because
that starts with `l` rather than with `m`.
OTOH, I think `*m*file` should match `lisp/multifile.el`.


        Stefan


12345