From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Package file indexing Date: Thu, 9 Jan 2020 15:36:56 +0100 Message-ID: References: <20190314204941.GA21065@jasmine.lan> <87mulx9kuv.fsf@nckx> <87zhpx846u.fsf@ambrevar.xyz> <87bm21y2s2.fsf_-_@gnu.org> <87imw7cpe7.fsf@bababa.i-did-not-set--mail-host-address--so-tickle-me> <87pnqdhkpf.fsf@gnu.org> <87imlt3hr2.fsf@ambrevar.xyz> <462f35f7596f7318d2b34cc300a7e27a69d2072c.camel@riseup.net> <87pnfs9437.fsf@ambrevar.xyz> <875zhk90pa.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:59768) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipYvu-0004DY-9r for guix-devel@gnu.org; Thu, 09 Jan 2020 09:37:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipYvs-00081Z-SO for guix-devel@gnu.org; Thu, 09 Jan 2020 09:37:10 -0500 Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]:44379) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ipYvs-0007ys-KE for guix-devel@gnu.org; Thu, 09 Jan 2020 09:37:08 -0500 Received: by mail-qv1-xf36.google.com with SMTP id n8so3010304qvg.11 for ; Thu, 09 Jan 2020 06:37:08 -0800 (PST) In-Reply-To: <875zhk90pa.fsf@ambrevar.xyz> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix-devel On Thu, 9 Jan 2020 at 15:14, Pierre Neidhardt 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