From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bozhidar Batsov" Newsgroups: gmane.emacs.devel Subject: Re: Can project.el or projectile.el help? How about completion? Date: Mon, 01 Nov 2021 14:20:41 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=73e62515d1854781b72d042dda6973a5 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28794"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e To: "Emacs Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 01 13:22:09 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mhWKC-00077y-PN for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 13:22:07 +0100 Original-Received: from localhost ([::1]:49774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhWKA-0002kP-Si for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 08:22:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhWJJ-0001sp-KL for emacs-devel@gnu.org; Mon, 01 Nov 2021 08:21:09 -0400 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:36907) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhWJE-0000tz-KB for emacs-devel@gnu.org; Mon, 01 Nov 2021 08:21:09 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D6F9A3200F72 for ; Mon, 1 Nov 2021 08:21:01 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Mon, 01 Nov 2021 08:21:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=ZhMUh/sAnuwCbakqEuN9DriWAD9aAFY NYU5BeGKg+FM=; b=lBl2NTAsLUEkWX4Bm9e3oD9HFxmmMmsCjqv/yvLtwNZDNL3 TLIIVj3YU+1vdXRhQaHZbVPDtc1Uzm6MZ5QA+vQ3VkX3QbilV6FG9y8iN+fwD5DA Bg3nC2K2JhbSiZ2bk4Xyfm/y3YrGdpnYtY+7zfJSiiOGBty43xJW70qrD1exXO6t +7Xa/gEP/dX/en7pLMJnzzZSscDXXQfd4s1Hfc0Wl/OhMBG0WeBiN1+0B0SxhZP7 i9UJV0JxSOI/hrfNAsgreEABf7uUz7ug76BD+gIh0JlRANOdcKhPRxX/nU7y+AuF u6NHpUx8lxMxZ9sW6qupXtUKCQPb7cKF29gfLkQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZhMUh/ sAnuwCbakqEuN9DriWAD9aAFYNYU5BeGKg+FM=; b=UkJ78JHkinY9o+h48aqnuX O/fUfgtJpsGDHFAUMbTuDjppaRI1+VfmpSv84/9TXBHKTtDjf1tN9MDjwgoHC/Zj nVnAL4u0ZGKjGCb0XfzYpaINc09DJTuDAgO5ut+14LUjbPD+RMmySXqe1lD7Ohjz M5Llrppi6lOT4hkfNPbPfDBvjD1Jz98JZhBfTQho+POC5CJ0ffnX+mjOh+P5wO7f hoLiHNC8UqffwDdUqPEB+ydCMS60BEWrhpgE24v7IXjSIezLL32+gkp+1dff2k3e VTtVtujwrbUpxdU+Lkt5noibeO1ZSkBESpmcjNNjiNw0/SjYUHNWFarqwW7IrVWQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdehvddgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeuohii hhhiuggrrhcuuegrthhsohhvfdcuoegsohiihhhiuggrrhessggrthhsohhvrdguvghvqe enucggtffrrghtthgvrhhnpeefffdvheevhfeukeeuleekhfeltdetffduheevffelgffg gfdvvdeivefgieffjeenucffohhmrghinhepvghlrdhsohenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohiihhhiuggrrhessggrthhsohhv rdguvghv X-ME-Proxy: Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2CB15AC0E8C; Mon, 1 Nov 2021 08:21:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: Received-SPF: pass client-ip=64.147.123.20; envelope-from=bozhidar@batsov.dev; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278371 Archived-At: --73e62515d1854781b72d042dda6973a5 Content-Type: text/plain Projectile's author here. Some examples of the nature of the problem would be useful, as I don't quite understand if we're talking about exactly the same files appearing at different places of the repo or it's files with the name that are actually different. Projectile returns the project files relative to the project root, so it's pretty easy to tell apart files in the second case, but I'm assuming your problem is probably the first case. I'm not aware of any existing sort order based on the distance from the current folder, although I can imagine this shouldn't very hard to implement. At any rate - projectile's quite flexible when it comes both to indexing strategies and to sorting orders, so it will definitely be possible to use something custom there, if the built-in options don't work well for you. On Sun, Oct 31, 2021, at 8:48 PM, John Yates wrote: > I work on a large corporate mono-repo in which numerous > filenames occur repeatedly. Further, various directories > above such duplicates also have duplicated names. > > Currently I use a self-built emacs tool to index this space: > * Build a map from a unique filename to a set of > repo-relative directory paths to files with that name > * Compute a disambiguation string for completing reads > for unique filenames this string is empty; otherwise: > * Repeatedly strip identical leading directories > * Repeatedly strip identical trailing directories > > I would like to replace this tool with something like > project.el or projectile.el. So the first question is does > either package do anything intelligent when filenames > are duplicated? If so, what? > > Then, is there any completion package that can present > the candidates in an order reflecting their distance from > the current buffer's working directory? My thought is to > sort identically named candidates by their repo-relative > paths. A focused, incrementally widening presentation > of candidates would show initially those in or below the > current working directory. Each time instructed to widen > the presentation it would advance up the parent directory > chain, showing candidates in or below that directory. > > /john > > --73e62515d1854781b72d042dda6973a5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Projectile's au= thor here.

Some examples of the nature of = the problem would be useful, as I don't quite understand if we're talkin= g about exactly the same files appearing at different places of the repo= or it's files with the name that are actually different.
=
Projectile returns the project files relative to the proj= ect root, so it's pretty easy to tell apart files in the second case, bu= t I'm assuming your problem is probably the first case. I'm not aware of= any existing sort order based on the distance from the current folder, = although I can imagine this shouldn't very hard to implement.
=

At any rate - projectile's quite flexible when it co= mes both to indexing strategies and to sorting orders, so it will defini= tely be possible to use something custom there, if the built-in options = don't work well for you.

On Sun, Oct 31, 2= 021, at 8:48 PM, John Yates wrote:
I work on a large corporate mono-repo in which n= umerous
filenames occur repeatedly.  Further, various= directories
above such duplicates also have duplicated na= mes.

Currently I use a self-built emacs too= l to index this space:
* Build a map from a unique filenam= e to a set of
  repo-relative directory paths to file= s with that name
* Compute a disambiguation string for com= pleting reads
  for unique filenames this string is e= mpty; otherwise:
  * Repeatedly strip identical leadi= ng directories
  * Repeatedly strip identical trailin= g directories

I would like to replace this = tool with something like
project.el or projectile.el. = ; So the first question is does
either package do anything= intelligent when filenames
are duplicated?  If so, w= hat?

Then, is there any completion package = that can present
the candidates in an order reflecting the= ir distance from
the current buffer's working directory?&n= bsp; My thought is to
sort identically named candidates by= their repo-relative
paths.  A focused, incrementally= widening presentation
of candidates would show initially = those in or below the
current working directory.  Eac= h time instructed to widen
the presentation it would advan= ce up the parent directory
chain, showing candidates in or= below that directory.

/john
=


--73e62515d1854781b72d042dda6973a5--