Re: Package file indexing

[zimoun <zimon.toutoune@gmail.com>]

On Thu, 9 Jan 2020 at 15:14, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> >> > I agree that explicit keywords, e.g., "file:" and "package:", avoid confusion.
> >>
> >> I disagree.  What about matching a path which contains "file:" or
> >> "package:"?  Then you end up with confusing commands.
> >
> > About "file:", no issue:
> >     guix search file:file:
>
> It might not be ambiguous for the machine, but it is to the human
> reader! :)
>
> --8<---------------cut here---------------start------------->8---
>   guix search /file:
> --8<---------------cut here---------------end--------------->8---
>
> is more readable in my opinion.

I disagree. Ah cheese and wine taste... ;-)

As I said, I am suggesting to have the both syntax.


> >> Simon, regarding your examples:
> >>
> >> >  - guix search bin/gmsh gimp
> >> >  - guix search file:ieee*.sty bin/gmsh latex
> >> >  - guix search file:bin/gmsh
> >>
> >> why mixing both the "file:" prefix and the "/"?
> >
> > Yes, I am suggesting to mix both.
> >
> > I would like to have all this syntax:
> >
> >>  - guix search file:gmsh.h gimp
> >>  - guix search bin/gmsh gimp
> >>  - guix search file:ieee*.sty bin/gmsh latex
> >>  - guix search file:bin/gmsh
> >>  - guix search package:gimp
>
> But for which benefit?  It seems that this single example
>
> >>  - guix search bin/gmsh gimp
>
> covers all your needs.

No.

For example:

> >>  - guix search file:gmsh.h gimp

I am looking for the file gmsh.h and I do not know nothing more.

> >>  - guix search bin/gmsh gimp

I need to know the name of the file and the path.

> >>  - guix search file:ieee*.sty bin/gmsh latex

I know nothing about the path of the file ieee*.sty and it does not
belong to the package gmsh.


Whatever!

To summary, I think:

 - the syntax '/' is cool to turn on the "file-search" feature
 - I find more meaningful the syntax "file:" to turn on "file-search"
 - I find more meaningful to have "file:foo.h package:bar" than "/.foo.h bar"



> > Now, if we speak about the "search" command-line syntax, today the way
> > is to write a regexp and then to filter with 'recsel'. It is UNIX
> > philosophy to compose via pipes but the drawback is: one *has to*
> > first (read the Guix manual [1] to) know the existence of 'recsel' and
> > second read the documentation of 'recutils' for complex filtering. So,
> > long time ago, I was thinking to add more syntax [2]. Today, the
> > syntax is:
> >
> >    guix search "" | recsel -C -e 'name ~ "agda"  && !(name ~ "mode")'
> > -p synopsis
> >
> > and I find more welcoming something avoiding the pipe, e.g.,
> >
> >   guix search 'name ~ "agda" && !(name ~ "mode") -p synopsis'
>
> This is still rather arcanic (understand: too hard to be useful to the
> general user) in my opinion.  Every time I use a program that has some
> search semantic, I need to look up the manual because I forgot the
> syntax and other intricacies.  So I end up not doing it often.

I agree...

> For advanced search, we could provide "explorable" features with a
> graphical user interface (which I plan to work on later) or Emacs (a big
> like `guix-packages-by-name', but more general).  Those interface would
> allow the user to chain searches by narrowing down lists.  What you
> print in the end is irrelevant since you can have an interactive
> presentation (unlike the shell).

...but at some point you need some semantic for filtering, at least for regexp.

Graphical presentation does not change the issue.

> Example:
>
> - Display list of all packages.
> - Run "agda" search against names.
> - Narrow down.
> - Run "mode" search against names.
> - Narrow down to the complement.
> - Run a general search against "foo bar".
> - Print the result.
> - Display synopsis only of the result.

Well you did kind of some semantic. ;-)

(You have right that it is more easy to remember how to do when it is
graphical and step by step. :-))


> For the general case, a "do what I mean" search field that works like
> Internet search engines is a better approach in my opinion.

I agree.

On my side, as I explained elsewhere I would like to try to improve
the 'relevance' function by applying well-known NLP stuff. :-)


Cheers,
simon