Working with symlinked src subfolders

[JAremko]

Fix for #2433 introduced a problem for projects with structure like this - when src folder contains symlinked sub-folders.

The idea behind it is using project.clj from developmen parent dir for development (basically like a :dev profile). You can read why they're doing it here https://polylith.gitbook.io/polylith/

The problem is that sesman--expand-path uses file-truename that resolves symlinks into real paths so when you jack-in while in a buffer with a symlinked path you'll get "No linked CIDER sessions". Replacing file-truename with expand-file-name in sesman--expand-path solves the problem (don't forget about cache when testing)

The secondary issue is that find-file also resolves symlinks when the folder is under version control. It can be disabled but maybe Cider can do something smarter about it? Like attaching the same REPL to both "real" and "symlinked" file paths when you jack-in from a directory that contains symlinks? For example when you visit this file and jack-in in its buffer.

@vspinu

[vspinu]

The problem is that sesman--expand-path uses file-truename

This is not the "problem". Could you please describe your problem step by step with that example project?

Like attaching the same REPL to both "real" and "symlinked" file paths when you jack-in from a directory that contains symlinks?

This could be, but I cannot see all potential negative implications, nor I clearly see your use case. Because find-file resolves symlinks this solution would not really help with your case because you have many sub-projects linked. So you will have to link manually when you are visiting a real file from any of the sub-projecs other than the sub-project where the jack-in was initiated.

It can be disabled

How can that be disabled? Is there a variable? If so then maybe Sesman can respect that and don't resolve symlinks? Or maybe there could be a sesman variable to control that which could be set in project level dir-locals. Would that help in your case?

[JAremko]

Could you please describe your problem step by step with that example project?

A:

1. Clone https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app
2. Delete/rename .git subfolder
3. Open in Emacs clojure-polylith-realworld-example-app/environments/development/src/clojure/realworld/article/core.clj
4. jack-in
5. Wait for REPL to connect.
6. See "[nREPL] Direct connection to localhost:XXXX established" in minibuffer
7. Looks at mode-line - no connection.
8. Try to eval - you'll get "No linked CIDER sessions" in minibuffer
9. goto step 4 each iteration you'll spawn a new "unlinked" REPL

B:

1. Clone https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app
2. Delete/rename .git subfolder
3. Open in Emacs clojure-polylith-realworld-example-app/environments/development/project.clj
4. jack-in
5. Wait for REPL to connect.
6. Now open in Emacs clojure-polylith-realworld-example-app/environments/development/src/clojure/realworld/article/core.clj
7. Looks at mode-line - no connection.

---

How can that be disabled? Is there a variable?

(setq vc-follow-symlinks nil) or remove git (in this case) from version control list vc-handled-backends

If so then maybe Sesman can respect that and don't resolve symlinks?

Sounds reasonable. But vc-handled-backends complicates things. Mb vc provides a way to test if a folder is under version control.

Or maybe there could be a sesman variable to control that which could be set in project level dir-locals.

This also may be needed since I'm not sure that vc is only thing that makes find-file preserve symlinks 🤔

---

Quality of life improvements:

So you will have to link manually when you are visiting a real file from any of the sub-projecs other than the sub-project where the jack-in was initiated.

If I simply jack-in then they (real and symlinked files) will have different project files/REPLs. But mb I can connect to the existing REPL - it's inconvenient but can be used as a workaround.

Probably the best solution is to save both "real" and "symlinked" file paths of all project files during jack-in. Then when you visit a real file CIDER can prompt for recognizing it as the same file and connect same REPL or it can happen if you try to jack-in. It has to be optional because you may actually want to have different REPLs (that are using different project files) for real and symlinked folders/files.

But you'll also have to watch for new symlinks... 🤔

[JAremko]

Also there is find-file-visit-truename that must be honored.

So far the requirements for preserving symlinks are:

1. find-file-visit-truename is nil.
2. File isn't under version control - (vc-backend (buffer-file-name)) returns nil or vc-follow-symlinks is nil or ask and user decides to visit the file as is.

[vspinu]

Thanks @JAremko for figuring all this out. The situation is a bit crazy because the default setting of find-file-visit-truename and vc-follow-symlinks are contradictory. The latter is ask for me but never asks. The worst part is that if you are visiting a symlinked file then the vc-root-dir (which sesman uses as fallback for project discovery) won't work at all, neither if there is a VC in sym or real path. Such a deep mess :|

I think that your PR is the best option so far. Setting sesman-follow-links to t comes closer to the default vc-follow-symlinks behavior. This seems reasonable as most projects are VCed and the pattern used in realworld examples is surely less common than the other way around.

[JAremko]

The latter is ask for me but never asks.

https://github.com/emacs-mirror/emacs/blob/emacs-26/lisp/vc/vc-hooks.el#L834