You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been happening for quite a while, and I think is a pretty important feature and hasn't been addressed yet and as I couldn't find a similar Issue created yet I will leave it here with a gif that shows the behavior.
If you guys need any more info I would be happy to help sorting this issue
The text was updated successfully, but these errors were encountered:
I think is a pretty important feature and hasn't been addressed yet and as I couldn't find a similar Issue created yet I will leave it here with a gif that shows the behavior.
Definitely. I've seen this come up a few times, but haven't been able to reproduce locally - trying to figure out what is different between the environments.
I just opened #3096 to add some additional logging around the expand-node-path - maybe can give us some clues. In particular, we weren't logging if there was an error while executing the readdir to get data.
Some other info that might be helpful:
Would it be possible to share the full path? I'm wondering if there is a special character, a space, a size limit, or something that could breaking our path resolution.
How did you open the folder? Was it through the menubar, command line argument (oni2 C:\some\path), or via an x command (:cd)?
Might be related to #2213 - there was a similar issue expanding the folder on Windows there, but went away after updating
C:\Users\ingjo\Documents\andrea\api-money-back (this is where the project lives).
My results for every method:
2.1. I just tested with oni2 . and this way it works nicelly.
2.2. Opening the project from file context menu does not work.
2.3. Opening the project with :cd source_to_project works aswell
Interesting! Thanks for testing and sharing the results @Jorgee97 . Indeed, there is nothing suspicious about the path itself - no special characters, under the 260 character limit imposed by some older path APIs.
Glad one of those options works.
For the attempt that failed, 2.2:
Opening the project from file context menu does not work.
Just to confirm, the folders didn't expand in that case? Or did something else go wrong?
I suspect that the path must be coming through in a different form in that case where it isn't working 🤔
Not sure if it is related, but right-clicking on the sub-folders gives a weird-looking path, with the last slash being a backslash. (Parent folder was selected through File>Open Folder, and I don't get opening sub-folders either. Win10).
__Issue:__ On Windows, there would be cases in which the explorer directory nodes would not expand on click or keyboard interactions.
__Defect:__ Windows paths would be split with the default windows path separator `\`, but in some cases normalized paths would make it to the explorer, and the split-on-default-separator logic wouldn't work (in particular, the logic to split up a path into hashes would fail).
__Fix:__ Working with paths-as-strings is problematic for reasons like this - especially since `\` and `/` are both valid directory separators in Windows.
The `string` type isn't very useful for representing paths, at least not in the context of a stronger type system, because just looking at a `string` leaves a lot of questions open about how the path is / should be interpreted:
- Is this an absolute or relative path?
- Are the directory separators normalized?
- Is there a trailing slash?
To fix this, I've refactored the pipeline for the `Component_FileExplorer` and `Feature_Explorer` to use strongly-typed paths with the [`Fp`](https://github.com/reasonml/reason-native/blob/master/src/fp/Fp.rei) library. This ensures that we have a consistent, normalized representation for paths up-and-down our pipeline.
- Need to continue refactoring `string`-paths to strongly-typed `Fp.t` paths.