From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: Package file indexing Date: Thu, 09 Jan 2020 15:14:09 +0100 Message-ID: <875zhk90pa.fsf@ambrevar.xyz> 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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35650) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipYZv-0006W8-QC for guix-devel@gnu.org; Thu, 09 Jan 2020 09:14:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipYZu-0003Fb-2X for guix-devel@gnu.org; Thu, 09 Jan 2020 09:14:27 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:49817) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ipYZt-00035Z-MI for guix-devel@gnu.org; Thu, 09 Jan 2020 09:14:25 -0500 In-Reply-To: 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: zimoun Cc: Guix-devel --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable zimoun writes: > Hi Pierre, > > On Thu, 9 Jan 2020 at 14:01, Pierre Neidhardt wrote: >> >> zimoun 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 co= nfusion. >> >> 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! :) =2D-8<---------------cut here---------------start------------->8--- guix search /file: =2D-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: =2D Display list of all packages. =2D Run "agda" search against names. =2D Narrow down. =2D Run "mode" search against names. =2D Narrow down to the complement. =2D Run a general search against "foo bar". =2D Print the result. =2D 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? =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl4XNTEACgkQm9z0l6S7 zH/jdAf/aFcgujuC4knCCq64PDg6wnNV0NIWSEmmu4FXOyATDsK7OT8AVEoB4W/t 9qopdDnII8aUA7HvLiznUJ4L9D+EywMIzLwHaWKOAcJTLgqOywDB5ocHXwC5XGlo TXBQ9F9LkVFppH9pUH6WuusXExrP/MQCFeY6BR3URB0LFGNP8CVW+neF2xdt1QzQ atsNYUnyuyxKZY5JM8CX0B/WfVhF65YC3+MqFuyAHgmjLoI8r8m0gcWhjfV5/+I1 6Lyl/0rNxdw46Ebd7Uoz0/77w32ulzHRp3Se5HrJmAiMaapVKj86JWomceBgDznJ EoekvTFBUZaBqcE0f5SxFXhGGvp4BA== =4Vpm -----END PGP SIGNATURE----- --=-=-=--