all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: John Yates <john@yates-sheets.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Help Gnu Emacs mailing list <help-gnu-emacs@gnu.org>
Subject: Re: Navigating an enormous code base
Date: Tue, 26 Apr 2022 08:53:48 -0400	[thread overview]
Message-ID: <CAJnXXohC-syD9L8qDgAvN0=hkaOyqSnLPS=uamGq5aNNSNrvUw@mail.gmail.com> (raw)
In-Reply-To: <83bkwom7i1.fsf@gnu.org>

On Tue, Apr 26, 2022 at 7:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> In what language(s) is this written?

Primarily C++.  But there are Makefiles, bash scripts, ad hoc text
files, xml, json, etc.

> Can you tell more about what you mean by "how I find files"?  Like
> show an example or two of use cases where you need to 'find files"?

Within the current project I want to open a specific
suite_registraction.cpp in one of multiple unittest/
or pkgtest/ directories.

In some project, could be the current project, could be a sibling
project, I want to open a specific file.

My goal is not so much navigating by symbols (I have lsp for
that). Rather it is more of a UI question. I want to use a modern
completion interface to open files by name. Supporting completion
requires that the space of possible file names be indexed and
supplied to the completion function.

As mentioned in my first post, an issue is how should the
completion UI present files with duplicate names.

Another issue is what should be the scope of file name (paths)
fed to the completion UI. Here I can imagine the following
possibilities:
* The current project
* An explicitly specified sibling project
* Within the current workspace, all projects in which I have made
  changes (perhap via after-save-hook)
* One of various pre-specified canned sets of projects

I could imagine splitting this UI into:
* Find in current project
* Find within a menu of wider contexts

> And what built-in tools did you try to solve those problems?

I have not tried any built-in tools yet.  I do have a private
wsf.el (WorkSpace Files) package that indexes as much of a
workspace as I am ever likely visit:

    https://github.com/jsyjr/wsf/blob/main/wsf.el

It is single threaded and rather slow (10 minutes to index a
workspace on a local SSD).  Currently I use ivy to browse the
index and open files.  Loading and caching the index in memory
takes 5 or 10 seconds.  (There can only be one workspace active
at any time.)  Once loaded, ivy interactivity is not great.

I am now using the whole vertico / marginalia / corfu / etc stuff
and want to ditch using ivy with my wsf.  Ideally I would like to
ditch wsf as well.  Hence this posting.



  reply	other threads:[~2022-04-26 12:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26  2:31 Navigating an enormous code base John Yates
2022-04-26  6:06 ` Daniel Fleischer
2022-04-26 11:03 ` Eli Zaretskii
2022-04-26 12:53   ` John Yates [this message]
2022-04-26 14:06     ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-04-26 12:49 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-14  3:47   ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-12-14 17:55     ` Emanuel Berg
2022-04-27  7:59 ` Marcus Harnisch
2022-04-27  8:36   ` mrf
2022-04-27 16:35     ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-04-27 22:59       ` John Yates
2022-04-28  0:46         ` Emanuel Berg
2022-04-28  6:42         ` Marcus Harnisch
2022-04-28  7:39           ` Leo Liu
2022-04-28  8:38             ` Marcus Harnisch
2022-04-28 10:45               ` Leo Liu
2022-04-28 14:34               ` John Yates
2022-04-28 14:45                 ` Marcus Harnisch
2022-04-28 14:30           ` John Yates
2022-04-28 14:40             ` Marcus Harnisch
2022-04-28 14:50           ` John Yates
2022-04-28 16:10             ` Óscar Fuentes
2022-04-28 16:15             ` Marcus Harnisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJnXXohC-syD9L8qDgAvN0=hkaOyqSnLPS=uamGq5aNNSNrvUw@mail.gmail.com' \
    --to=john@yates-sheets.org \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.