Symlinks, directories, and the magical `..` entry have never played well together. However, tools usually are consistent in the interpretation of `..` in this context: Either it is the parent of the symlink folder, or the parent of the target folder.
In geany, however, it just causes strange and subtle errors, which is never a good thing.
Here's an example so I have things to talk about. Note that I write `~` only for succinctness. Geany correctly uses only the fully expanded paths.
``` # Setup ~/test$ mkdir -p realdir/subdir ~/test$ ln -s realdir/subdir/ symlinksubdir ~/test$ echo "Some text" > realdir/existingfile.txt ~/test$ echo "Different words" > toplevelfile.txt ~/test$ cd realdir/subdir/
# Demonstrate behavior in plain folders ~/test/realdir/subdir$ ls .. existingfile.txt subdir ~/test/realdir/subdir$ geany ../newfile.txt # (1) Opens a tab for a not-yet-existing file ~/test/realdir/newfile.txt ~/test/realdir/subdir$ geany ../existingfile.txt # (2) Opens the existing file ~/test/realdir/subdir$ cd ../../symlinksubdir
# Demonstrate behavior in symlink folders ~/test/symlinksubdir$ ls .. # The entry '..' points to '~/test/realdir', not '~/test' existingfile.txt subdir ~/test/symlinksubdir$ touch ../toplevelfile.txt # Shell expansion sees '..' as pointing to '~/test', not '~/test/realdir' ~/test/symlinksubdir$ geany ../newfile.txt # (3) Opens a tab for a not-yet-existing file ~/test/newfile.txt ~/test/symlinksubdir$ geany ../existingfile.txt # (4) Fails when fetching file information (?), refuses to open a new tab. ~/test/symlinksubdir$ geany ../toplevelfile.txt # (5) Opens a tab for a "not-yet-existing" file ~/test/toplevelfile.txt ```
Expected behavior, flavor "parent of symlink": - Command 3 opens a tab for a not-yet-existing file `~/test/newfile.txt` (matches actual behavior) - Command 4 opens a tab for a not-yet-existing file `~/test/existingfile.txt` (differs) - Command 5 opens a tab for the already existing file `~/test/toplevelfile.txt` (differs)
Expected behavior, flavor "parent of target dir": - Command 3 opens a tab for a not-yet-existing file `~/test/realdir/newfile.txt` (differs) - Command 4 opens a tab for the already existing file `~/test/realdir/existingfile.txt` (differs) - Command 5 opens a tab for a not-yet-existing file `~/test/realdir/toplevelfile.txt` (differs)
Expected behavior, flavor "avoid weirdness": - Command 3 refuses to resolve `symlinksubdir/..` at all (differs) - Command 4 refuses to resolve `symlinksubdir/..` at all (matches actual behavior) - Command 5 refuses to resolve `symlinksubdir/..` at all (differs)
Note that the cases 3 and 4 "only" cause confusion about where a file is or will end up. In case 5, a user might attempt to write something into a file (i.e., add to a TODO-style list), find it empty on the current machine, and save it – and thus, without any warning, overwrite the existing file. Data loss. Sad panda.
I have no idea how the "Open File" dialog stuff relates to this. The bugtracker apparently knows nothing like this.
If I were to touch the code that deals with the file name resolution and handling, which flavor would you prefer for a PR? Parent-of-symlink or parent-of-target?