From: Marcus Harnisch <mh-gmane@online.de>
To: help-gnu-emacs@gnu.org
Subject: Re: Navigating an enormous code base
Date: Thu, 28 Apr 2022 08:42:55 +0200 [thread overview]
Message-ID: <t4dd1g$tb7$1@ciao.gmane.io> (raw)
In-Reply-To: <CAJnXXojh46vFqw6=rxH0ds15Yc0yrzRxkfdapQkJzB1in7dM2w@mail.gmail.com>
On 28/04/2022 00.59, John Yates wrote:
> Start with feeding a completion interface:
>
> * Do you index on demand? If no, then when? And how do you
> keep the index upto date?
As far as my work pattern with Global/ggtags is concerned, I create a
full index rarely. Usually only when the repository can be expected to
have changed significantly (pull, merge with upstream, etc).
Global can do single-file updates, which I think ggtags executes in
‘after-save-hook’ or something, so your own changes will be tracked.
Creating the database with the sqlite3 backend is supposed to perform
much better with these partial updates.
Since I spend most of my time in my little niche this is sufficient for
my purposes and even if there have been small updates outside, the
location I will be taken to is close enough most of the time (and a
little reminder for creating a full index).
> * Indexing the entire workspace will result in an intractably
> large index. So how do you partition it?
I don't bother and don't partition the project (comprising of 10k files,
and 50+ nested subprojects)
The total size of the DBs is about 60MB (files: 2, tags: 20, references:
38).
> * Is the user restricted to querying a single partition of the
> index? If yes, then that feels painfully restrictive. If no,
> how does that user indicate which partition indices to combine?
> How is combining accomplished?
See above.
> * How are duplicate filenames handled?
By storing path names.
Why don't you give it a whirl and see whether this suits you?
next prev parent reply other threads:[~2022-04-28 6:42 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
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 [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='t4dd1g$tb7$1@ciao.gmane.io' \
--to=mh-gmane@online.de \
--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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).