Follow symlink when resolving canonical path

[Corentin-pro]

I created an issue in the spacemacs project (syl20bnr/spacemacs#16070) because the root-project was not find every time I was opening files from my projects.

It turns out that if projects are from a symlinked folder the lsp-session always saves the canonical path following the symlinks but during the matching when opening a file the symlink are not followed.

Adding a file-truename to the lsp-f-canonical fixes this issue.

[yyoncho]

The whole point of coping f-canonical from f package to lsp-mode package was to remove f-truename call due to perf issues. In your case you should either add the symlinked project root or the other one.

[Corentin-pro]

I changed the code to only call file-truename in lsp-find-session-folder. This would mitigate the perf issue for any other lsp-f-canonical calls (not sure that following symlinks should be a perf issue in the first place).

The suggested manual add of project folders for every single project that happens to be in a symlinked directory feels wrong for user experience.

There is probably a semantic discussion about if symbolic links should be treated as separate files or not, so that all packages would treat them accordingly. For now ivy and others do not try to resolve but projectile does (projects added are always resolved following symlinks). Because projectile seems to only add symlink-folllowed path (automatically, maybe this happens somewhere before), I think that when matching a file to already known project we should resolve symbolic links.

[yyoncho]

directory feels wrong for user experience.

We should either not resolve anywhere or resolve everywhere. If we resolve like you are suggesting it will break the opposite case when the user is not following the symlinks for the files but the root symlinks are followed.

[Corentin-pro]

I don't see the opposite way of breaking : the user is not following the symlinks for the files but the root symlinks are followed. -> this is my problem right now and what this PR is fixing (the root are always following symlinks). I have no idea how to get any discussion/consensus about this issue.

I understand following symlinks could break other things but now it seems that every lsp-mode user will have problems if/when having any symlink to their projects.

[yyoncho]

You have the following layout:

• bar
  • projectFile
• bar-symlink

If I go into bar and open projectFIle the filename will be bar/projectFile. If you do the same from bar-symlink then I will get file bar-symlink/projectFile. Based on whether I do file-truename for the file will get only one of these working, right? If you make one of them work you will break the other. Furthermore, if I open projectFile under the symlink I will be asked to import the symlink dir as project root. If I do the same from the real path I will be asked to import the real path. lsp-mode cannot make both working without resolving to using file-truename everywhere which we have decided not to do because it kills emacs performance.

[Corentin-pro]

if I open projectFile under the symlink I will be asked to import the symlink dir as project root

This is exactly the opposite, I can open from bar or bar-symlink, it will always use bar as project root. Hence the issue I was facing here : syl20bnr/spacemacs#16070 . Only the bar version was registered so I kept being prompt to import the project if I open anything from bar-symlink

[yyoncho]

This is exactly the opposite, I can open from bar or bar-symlink, it will always use bar as project root.

The root of the project is not automatically selected but it is selected/confirmed by you. On my side it recommends the symlink version and it most likely depend on settings like vc-follow-symlinks and related. As you can see going one way or another cannot handle both cases and it will me up to the user to pick appropriate project root based their custom configuratoin.

[Corentin-pro]

I'd love to know other people feedback on this. I'll let this PR open for a while and will close it if no discussion appears on this issue. Feel free to close it if you think this will never happen anyway.

I will try to dig more on the possibilities to setup emacs environment to avoid the problem I faced.

[Corentin-pro]

I am closing this PR, this may not even be relevant any more.