On Thu, 9 Jan 2020 at 15:14, Pierre Neidhardt <m...@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
