Project Search and Replace

[countvajhula]

A user asked on Discord whether there was a way to do project-wide renaming of bindings, and racket-xp-rename was suggested. But this only works on individual modules, and there's no notion of a "project" in Racket Mode or DrRacket.

Some Emacs packages do provide a definition of a "project." For example, for projectile, a project's files are derived as every file contained in the current Git repo's index. There may be other ways to get a project file listing that we could provide to Racket Mode.

I took a crack at using Projectile to list the project files, and then traverse those and apply racket-xp-rename. With a few modifications, I was able to get something to work:

Racket project search and replace [edit: fixed link]

But it does have at least one bug, where the defining module is itself renamed, in a require specification, to the new-id. That is, (require "path/to/source.rkt") becomes (require my-new-renamed-identifier)!

This approach does feel hacky to me, to begin with, but regardless of the specific approach, I thought it would be useful to create an issue to collect feedback and further ideas, as at least one other person reported that they resort to basic regex based replacement to do this project-wide, thus missing out on bindings-based replacement in racket-xp-rename which seems very useful.

[greghendershott]

Following a chain of import references is non-trivial, even when languages fully expand into the documented, transparent grammar of #%provide and #%require.

I invested non-trivial time in this: https://github.com/greghendershott/pdb

About two years ago, I thought I was getting close, at least for "traditional" langs like racket. 🎉

But then I ran into the new "portal" expanded syntax added for rhombus. 😕

I don't see how to proceed and I've given up on this.

[greghendershott]

Meanwhile I just use deadgrep, the Emacs package interface for ripgrep.

It "just works" for projects with root files like .git, and could be configured for others like .info.

I do need to review choices manually.

But it's not the same thing as a high-confidence replace-all command.

I really do understand the appeal and utility of the real thing -- despite the low ROI, I really worked hard to make that happen. Unfortunately it seems Racket moved in the direction of making that even harder, maybe outright impossible, to accomplish. Maybe someday that will change; if so, maybe someday I'll no longer feel totally burned out, and willing to roll that rock up that hill again. 😄

[countvajhula]

Ah, makes sense. My hack doesn't attempt to solve these problems at all, so identifiers with a common name but different binding would surely not be differentiated in the replacement.

I'm sorry to hear you got burnt out when you last worked on these things, it must have been very discouraging to run up against a wall at the seeming end of your long labors. Your valiant efforts are not in vain, as they are appreciated by many! I brought this up in today's Qi meeting in case anyone might have any leads, but everyone could only express solidarity with your struggles on these challenging issues 😄

re: Rhombus, I have no idea if the "opaqueness" you mention is by design or just by virtue of the language still being in development and there hasn't been much attention paid to tools yet (I get the impression it's more this!), but, if you are close on typical #langs besides Rhombus, then would it be feasible to salvage that work so that it powers the useful Racket Mode features you envisioned at the outset for such (most) languages? It's conceivable that Rhombus / portal syntax would become easier to analyze in the future as the language stabilizes, and could be incorporated at such a time? Just wondering.

(Please feel free to close this issue, unless you feel keeping it open would be useful to track potentially adding this feature via pdb).

[greghendershott]

Sorry to be so slow to reply.

Honestly my first reaction was ~= "I am so done with this topic".

Allowing myself to think about it, again, more recently:

Maybe I need to break this into pieces or "layers".

0. A simple "check-syntax cache".
1. A kind of "plugin" system where a #lang can register code to run when 0 runs, and do extra analysis and store extra data. This extra data can be arbitrary, but a defined subset will cover exports and imports, to be queried later.
2. I supply a default plugin that works for langs that transparently expose their exports/imports in fully-expanded #%require and #%provide syntax.
3. As for other langs that are unwilling or unable to do so? Someone else's problem, which they can fix (or not) by supplying such a plugin.

Or something along those lines??

[countvajhula]

This layered approach sounds reasonable. If you think that it represents a minimal path for integrating pdb into mainline racket-mode development and that that would (1) offer new possibilities for the user (even if not fully taken advantage of by the initial implementation) and (2) make your life easier as a maintainer (rather than harder), then I would say that it could be a worthwhile effort. On the other hand, if it's going to be a lot of effort just for a project search-and-replace feature, then I would incline toward your initial assessment and avoid the rabbit hole 🙂