How to return to project dir if project tab desyncs with project dir?

[sethidden]

Repro:

1. C-x p p and open some project
2. Repeat step 1 but with another project, so that there are 2 tabs
3. In the project that was opened second, C-x d to "~/" - this creates a situation where the second tab's group is "[project 2's name here]", but the current directory is not that project's root directory (you can just also go to any file outside of that project)
4. Switch to the first tab
5. C-x p p and select the second project again - this will change the tab to the already existing second project's tab, but will not pop up the 'project-switch-commands' minibuffer prompt. You will just be moved to the second tab, where the directory is not the project directory.

Is there anything I can do to quickly go back to the root dir of the project that has the same name as the current tab group name? In the case that the tab no longer points to the dir, because I went outside of it. My first instinct is to just "reset" the current dir by manually running C-x p p and switching to the same project as is in the tab name, but due to this package's override, it just switches me to that tab instead.

Right now I do the "walk of shame" by C-x C-f to the project dir by manually typing in the file path

---

Naturally I could just write a script that takes the current tab group name, looks through the saved projects and changes to that dir. I'm just wondering if there's a more built-in way

[fritzgrabo]

Hi Artur,

thanks for reaching out, and thanks for the detailed description of the issue. I sometimes run into the same issue, and also do a "walk of shame", albeit a different one: I just close the tab group altogether and start over afresh 😅.

Your report prompted me to look for a better way though, and here's what I came up with:

In step 5, after switching to the project's tab, project-tab-groups--select-or-create-tab-group would detect that the tab's current buffer's working directory is not part of the project that we just switched to, and presents the familiar project menu in the echo area as a result, as if you had just opened the project anew.

I believe this new behavior follows the "principle of least surprise" in the given situation, but it's probably still a good idea to put it behind a customization option so folks can turn it off if they find it annoying.

Let me know if I understood the issue correctly and if the above sounds like a viable solution to you. Thanks!

[sethidden]

@fritzgrabo Yep, I think that would be a good solution that fits into your package's elegant minimalist approach :)

---

Another idea would be to add a new interactive function as I described in the OP:

Naturally I could just write a script that takes the current tab group name, looks through the saved projects and changes to that dir.

That could be less obtrusive, as you have to call the function yourself.

So the imaginary M-x project-tab-groups-cd-to-tab-group-project-root could work like this:

1. call tab-bar-tabs to get all tabs,
2. Find the active tab,
3. Save the active tab's group string to a variable
4. Call project-tab-groups-tab-group-name-function on each entry in project-known-project-roots and try to find the project root that matches the active tab's group
5. Once you find the project root dir, switch to it

Admittedly this solution has more moving parts than what you proposed. However, I can perhaps picture a situation where somebody intentionally keeps a split with a buffer that's not in the project dir (say there are 3 splits open, and only one - the active one - is outside the project), and then gets annoyed that the project prompt appears when switching. I'm not really sure which solution would fit best 🤔

[fritzgrabo]

I just pushed an update that introduces a new customization option project-tab-groups-reconnect-tab; it should be available via MELPA soon.

• In its default setting (t), it will show the project dispatch menu when switching to a tab finds that tab "disconnected", as discussed above.
• A value of nil would ignore situation altogether -- this is what folks could use to get the old behavior back.
• And finally, if set to a function's symbol, that function will be called with the switched-to project's root directory as its single argument.

You could use that last option to implement the behavior you described, where you'd "bring back" the tab to its project's root in some other way.

Please give this new version a whirl if you can, and let me know if it works for you.

Thanks again for reaching out and for your input -- this package is now better than it was before because of it! 🎉

[sethidden]

Just tried it out. Working great! :) Thanks so much!