zimoun <zimon.toutoune@gmail.com> writes:

> Hi Pierre,
>
> On Thu, 9 Jan 2020 at 14:01, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>>
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>> >> To avoid confusion, I think this should be an option/subcommand of
>> >> search. Something like -path and -name in find(1).
>> >
>> > 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.

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

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

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

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.

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

What do you think?

-- 
Pierre Neidhardt
https://ambrevar.xyz/