From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Exploring a code base? Date: Sat, 07 Nov 2020 16:47:46 +0200 Message-ID: <837dqx6x65.fsf@gnu.org> References: <57dcdf06-3bf4-4281-88d9-0e9c46adc757@yandex.ru> <83d00p6zj1.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5813"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 07 15:48:29 2020 Return-path: Envelope-to: geh-help-gnu-emacs@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 1kbPW0-0001P5-9D for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 07 Nov 2020 15:48:28 +0100 Original-Received: from localhost ([::1]:33882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbPVz-0001bO-AB for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 07 Nov 2020 09:48:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kbPVK-0001Zk-4z for help-gnu-emacs@gnu.org; Sat, 07 Nov 2020 09:47:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59501) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbPVJ-0002A1-Rj for help-gnu-emacs@gnu.org; Sat, 07 Nov 2020 09:47:45 -0500 Original-Received: from [176.228.60.248] (port=1565 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kbPVI-000506-Cy for help-gnu-emacs@gnu.org; Sat, 07 Nov 2020 09:47:45 -0500 In-Reply-To: (message from Gregory Heytings on Sat, 07 Nov 2020 14:33:25 +0000) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:125091 Archived-At: > Date: Sat, 07 Nov 2020 14:33:25 +0000 > From: Gregory Heytings > cc: help-gnu-emacs@gnu.org > > > Basically, I'm asking why having a flat list of all the users of a data > > type, and reading the code of all of them, is not enough for this kind > > of job? What am I missing? > > IIUC, Yuri, Stefan and Dmitry all described the same problem, each with > their own words I've read the entire thread, thank you. > using M-. and M-? works fine for simple tasks (say, > change the name of a given function or struct field in a codebase, or see > where a given type is used), but when you are tackling a more complex task > you often have to put searches on a kind of "stack", on which you can save > your current search state, and from which you can resume your current > search at a later stage. Say, you are making changes to the occurrences of > "foo", and at some point during that work you see that you need to change > something around the occurrences of "bar", and at some point during that > work you see that you need to change the occurrences of "baz", and so > forth. When that happens, it means you should change the search criteria. For example, if you looked for a variable, but found that more than one variable is involved, you need to search for the data type (if all the variables use the same data type), or search for several identifiers instead of just one. the tools mentioned all support such multiple searches, so I still don't think I understand the problem. I used this technique in some pretty complex projects (as in: about 1 million code lines of sophisticated C++), and it scaled well. As for discovering that a problem includes more places and symbols than one originally envisioned: one can maintain a flat list of functions/modules/whatever to look into, and add to that as more stuff is being found. You can do it in Org or even in a simple text buffer. If there's really a need to maintain some structure, one can use Org's level headings to that end. Bottom line: I still don't see the problem, and my question above still stands.