From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Can project.el or projectile.el help? How about completion? Date: Mon, 1 Nov 2021 16:48:20 +0300 Message-ID: <6a3bcb26-dde5-39d4-0514-7d155be646f3@yandex.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20380"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 To: John Yates , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 01 14:50:23 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 1mhXhf-0005Cq-8X for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 14:50:23 +0100 Original-Received: from localhost ([::1]:46020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhXhe-0000aH-4A for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 09:50:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhXfm-00071Q-PD for emacs-devel@gnu.org; Mon, 01 Nov 2021 09:48:26 -0400 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:37724) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhXfk-0005IX-ER for emacs-devel@gnu.org; Mon, 01 Nov 2021 09:48:26 -0400 Original-Received: by mail-lj1-x22b.google.com with SMTP id y8so916446ljm.4 for ; Mon, 01 Nov 2021 06:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bSodvoXee63+PZ1ksshpaAOBsq0/iUp3/B14d5g1nrI=; b=GXvHfJTF3pCuO94OCcSTLhdlVo8aNV90u/6k4HyFKE8WCiL/wDIepIYAjH+WlujfwW zgbvUvO/+RD2OVITGnSlMQRquPPjbb1t7ZUeV7hbwnrftIq+FwUey0EM3AXqaGNOQsoZ tvk9f+h2k+WV2jh5AIndMcgqKDssVATt0HXKlgNmTbTxKZK+U7XROwnkPO/UiFhnOc4E wcxwwe7mUZQ2dunQ1CGn4JhiSKpWyMzC9Me0epIRFZztVK7UY5hzvqPnEQY+2XVYH4j7 x18MwytGp9jsyS3ZwhBRLnW/CSPLY4SEfMA98qqCXEzGkXUS9BBRw8groKM/9FlZgXvS V+LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bSodvoXee63+PZ1ksshpaAOBsq0/iUp3/B14d5g1nrI=; b=aSAUOUjdas/IFlDMiOCsc2CSI93AUdaSH7iaH8pfep0qDDY8uxpS9aM4yNDpkGttmd OeBScGjSsppGoVVvFd4Z2GLpLtnrmQuDfvfcn9GcuaYAA9xIipeZqi97TgTdDnvHB/XA xHRQS1J34mFPnQcjIt1RHZVLcTEauXWxgp9r96KwRejmYgf0+ayfyj7qOCIwZ4WvGagp 6boTjInZh4PiKTRdOCIxABwUc6peqlrSoOuK61Xx4bkSjBmbuXhSZapRMXDVgwsD3PTo JR+54KGVyTlHpiVDBFlwD4SYM0L6WiaRNq3bP8JuYQHSzygYHCthObJeAtLNJMThWNX3 6l2g== X-Gm-Message-State: AOAM5302V/T4+kyyQsiIk8NafO5wvvisGYbPke+qZaiPFBdEoKd5m16t 6O3sBWs4KLAMGG8xkBOXVfgeO/6iFzY= X-Google-Smtp-Source: ABdhPJxALdYgZS4sBuQa7ZSMXcQGArzi58opLU+zL8VLaqCe355SjoUlwLvoNNt3OmlhuEak8XeEFw== X-Received: by 2002:a05:651c:1583:: with SMTP id h3mr30810405ljq.98.1635774502249; Mon, 01 Nov 2021 06:48:22 -0700 (PDT) Original-Received: from [192.168.0.103] ([5.18.158.28]) by smtp.googlemail.com with ESMTPSA id a15sm1413698lfj.65.2021.11.01.06.48.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Nov 2021 06:48:21 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::22b; envelope-from=raaahh@gmail.com; helo=mail-lj1-x22b.google.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-1.14, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:278382 Archived-At: Hi! On 31.10.2021 21:48, 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. First of all, project-find-files by default uses 'substring' completion. Which can allow you to type unique parts of the relative file name, separated by slashes, press TAB, and then see the name completed. Completion frameworks like Ivy/Helm/Consult can also affect/augment the completion experience. > 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? project.el also comes with defcustom called project-read-file-name-function. It allows you to write your own wrapper which could convert all files names into "disambiguating strings", for ease of completion, before the completion prompt is displayed. > 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. Since project-read-file-name-function creates the completion table object, you could sort the strings inside it as well, using the algorithm of your choice. As long as the table defines `display-sort-function', the completion UIs should not re-sort the list alphabetically.