Version: (using KDE KDE 3.5.5) Installed from: SuSE RPMs Let's say I have A.cpp file and symlink to it -- B.cpp. I explicitly open B.cpp -- what file is opened? A.cpp. I mean in file list, in title bar, there is no B.cpp, but A.cpp. Please, such "smart" following the links is not smart, it is annoying. User had her/his reasons to open the symlink, so please do open it and use appriopriate filenames
This is a feature and not a bug. We resolve the symlink to not have the same editor window for the file open twice which would cause all kinds of trouble. A symlink to a file is not different from the real file for kdevelop.
> This is a feature and not a bug. But the design of this feature is buggy then. > We resolve the symlink to not have the same editor window for the file open > twice which would cause all kinds of trouble. Ok, but please do it internally then. > A symlink to a file is not different from the real file for kdevelop. But it should be -- I don't work on a project with two files. I have tens of files opened _at the same time_ and when I open test.rb and this file is missing (in KDevelop) I don't want spend time looking through all the files and notice finally that Kdevelop opened "real" file mambo_test.rb so I was looking for the "wrong" filename. It is really counterproductive -- who has time to chase&guess "real" filenames? Conclusion: please resolve what you need, but please do it internally -- visually show the user exactly what she/he opened in place she/he chose.
Well, the feature itself is not buggy. Instead its really good working and its really reliable. KDevelop will _always_ resolve Symlinks upon opening a file and it will also _always_ just bring an already opened editor to focus if the resolved filename is the same as that of the already open editor. I'll let the bug open for you, but I think unless you come up with a patch to change this (search for editDocument function) this won't be changed anytime soon (read not in kdevelop3)
Andres, I am not saying that technically it is buggy -- rather it is correct. But the other thing is the user experience -- if you have big project, with all file names sorted and you open file A you don't expect it will be located between J and L, right? And this is what is happening.
Well, to be honest I wouldn't start symlinking files within a project anyway. Even on big projects. I really don't see the reasoning behind that, but I may of course be to blind to see it :) Anyway, as it currently stands this is not a bug, but a wishlist item because you'd like to have kdevelop not follow symlinks.
> not follow symlinks. "Visually" (only). Yes :-)
And what, pray tell, would we do with a second symlink to a file? Like: File X, symlinks S1 and S2 both to X. User opens S1, KDevelop displays S1. User opens S2, umm... display S1 or a second copy of X as S2? We don't really want to do either. The least confusing thing all around is to always resolve the symlink.
Jens, I am not sure what you mean by "resolve" -- internally? Sure! Visually -- no! > Like: > File X, symlinks S1 and S2 both to X. > User opens S1, KDevelop displays S1. Sure, and remember "X is really opened". > User opens S2, umm... display S1 or a second copy of X as S2? No. Exactly the same when you have file A and open again file A -- it just switches to this file. In this case extra dialog "you have already opened this file as S1" would solve the "problem".
So you want a msg box popup whenever a file is opened via symlink that is already opened via the real name? I wonder how that wouldn't be annoying, I mean you can't just have a dialog which has this "don't ask me again" as then you're back to current behaviour. I'm more and more leaning towards a WONTFIX.
Ok, I have one beer this evening, but my English is bad? :-) Andreas, > So you want a msg box popup whenever a file is opened via symlink that is > already opened via the real name? No, I just suggested it as extra-bonus :-) I would like the same behaviour it is already implemented -- switch to the file. But I just wrote about another idea. > I wonder how that wouldn't be annoying, I mean you can't just have a dialog > which has this "don't ask me again" as then you're back to current > behaviour. I know. Ok, let's better forget about this extra-dialog. In future I'll try not to write anything about extra dialogs :-) So, in case the file is already opened -- do nothing special, only what is already done. Anyway, please _display_ in file list and in title bar the pointed (chosen) file.
re-reading the discussion and thinking about it, this is a wontfix. It complicates the code for no good reason and it will confuse people who are actually aware that files X, S1 and S2 are the same.
This is odd, "people who are aware" -- because I am technically aware that something is symlink to something, but I don't remember every detail. So when I open file A.cpp (and it is symlink to file T.cpp) I will have to track list where it went and what the name is. As I said before -- it is counter-intuitive. The _displayed_ (for user) name should be the file A.cpp. After all... user opened A.cpp not T.cpp. Also note, that user for some purpose would rather work with linked name -- it is impossible with KDevelop because it forces user to use symlinked file (filename) actually. AND... :-) Kate works the suggested way, i.e. it displayed the filename that was opened. Bottom line -- Kdevelop violates principle of least surprise, user wants to open X file, show it to him, what is done internally it is out of the user scope.
Dear KDevelop developers, Please reconsider this issue. When some of the directories that lead to the file being edited are symlinked, smart-opening creates a lot of confusion and inconvenience. There are good reasons to symlink directories: for instance, the entire project may be located in symlinked directory so that switching the symlink would allow changing the particular version of code (or type of build) being worked on. After switching the symlink, I would expect that KDevelop session points to the projects in symlinked directories. However, the projects in the KDevelop sessions are bound to fully resolved locations, so switching symlink does not do the job. And please revisit the argument that the tool should better not try to outsmart the user, who definitely has reasons for symlinks if he uses them. You may add visual indication that two or more open files actually refer to same physical file (for instance, display 'link count' near the file name in the project window if the file is open under a number of names; also the editor title tab may display the link count and a tooltip listing all names under which this file is open). This would allow to have a number of different names in the list of open files that refer to same actual file, and have all of them refer to one editor window. (To make this more convincing, let's imagine that hardlinks are used instead of symlinks. How the editor would handle such case?)
Hello, I face the following issue: A lot of source files in my project are located on network drive with readonly access. Local project files are just symlinks to those. After resolving symlinks, kdevelop ignores the project-wide .kdev_include_paths and it cannot even save file-specific .kdev_include_paths because the destination is readonly. I build kdevelop manually anyway. Could you please help me with the patch to disable symlink resolution and treat symlinks as the target file content without smartly following them?
This smart symlink feature is real pain for python development. I have 2 files in the directory one is real file and other is a symlink: /project/a.py /project/b.py -> /opt/b.py If I want is to import file a.py from b.py kdevelop parser is looking for /opt/a.py NOT for /project/a.py! But normal python interpreter works ok in this case, only "smart" kdevelop causes trouble.