Closed with-heart closed 4 years ago
I am having precisely the same problem.
OS X Yosemite 10.10.5 Atom 1.7.3 advanced-open-file 0.16.2
I am unable to replicate the issue. Here is a video of my attempt: https://youtu.be/TChbmctcvUg
OSX El Capitan 10.11.4 Atom 1.7.3 advanced-open-file 0.16.2
Per @yudai-nkt in #107, this appears to be an issue caused by UI theme settings. I have not had time to investigate and fix the problem for all themes, but for the time being, putting the following in my styles.less
makes at least the second line of the box visible:
.advanced-open-file atom-text-editor.mini {
max-height: 100px !important;
}
@lionize Thanks for the quick fix!
This problem has been fixed for me with version 0.16.3.
Thank you!
Cool! FYI 0.16.3 was a revert of rewriting the UI in React so it makes sense. :P
I'd like to keep this open until some resolution to the issues around that revert comes up.
Okay, well, just to be helpful (if possible) let me explicitly describe what I saw:
Before 16.2 and after 16.3:
Activating advancedOpenFile (cmd-option-o) brings up a dialog. The first element of the dialog is a text field with the current path prefilled (per my settings) and the insertion point blinking at the end of that path. As I type new directories/filenames thereby lengthening the path, the text in the box scrolls left so that I can see what I'm currently typing. Pretty much what's expected (and correct!).
During 16.2:
Here the plugin would activate and appear the same as above, however: as I would type new directories/filenames thereby lengthening the path, the insertion point and the lengthened path would extend out the right side of the text area so I could not see the insertion point or whatever I was typing. Attempting to force the text display to scroll, such as by clicking and highlighting or any other mouse/keyboard technique would fail to bring the insertion point into view.
(According to some, the text wasn't extending out the right side of the viewable area, but rather was wrapping to a second line. This may be, I never got around to tweaking the styles.css to try the fix for that).
Anyway, glad it's working normally again at least for the present. I hope a solution presents itself that allows you to code it in the way you were hoping.
@Osmose: As of 16.3, things are working correctly again.
If there's any further feedback you'd like, please let me know. I really appreciate your work on this—I love this package and use it constantly.
The problem is still present when using "Atom Light" theme and v0.16.5. No problem with "One Light" theme.
The text should at least be aligned right so one can edit the file name!
Linux Debian Jessie Atom 1.13.0 advanced-open-file 0.16.5 atom-light-ui 0.46.0
The problem is still present when using "Atom Light" theme and v0.16.5. No problem with "One Light" theme.
The text should at least be aligned right so one can edit the file name!
Linux Debian Jessie Atom 1.13.0 advanced-open-file 0.16.5 atom-light-ui 0.46.0
Interesting! I'm on OSX but otherwise tested the same setup of packages, and didn't experience the issue. Maybe your syntax theme is having an effect? Which syntax theme are you using?
Interesting! I'm on OSX but otherwise tested the same setup of packages, and didn't experience the issue. Maybe your syntax theme is having an effect? Which syntax theme are you using?
Looks like it append with every syntax theme (I tried with Atom Light & One Light).
I can reproduce the problem with theses themes:
But not with the following:
I just noticed that when the problem occurs, a tiny scrollbar appears on the right of the text area, so it is difficult but possible to scroll down to the end of the file path.
Moreover, putting the following code in styles.less does not help:
.advanced-open-file atom-text-editor.mini {
max-height: 100px !important;
height: 100px !important;
}
Reproduced on:
macOS Sierra 10.12.3 Atom 1.13.1 advanced-open-file 0.16.5 native-ui 0.20.3
Works properly with One Light UI theme.
Seems to be fixed, input box now scrolls on long text.
atom 1.17.0 advanced-open-file 0.16.6 native-ui 0.20.6
Having a long path name hides the second line of text and the textbox defaults to only showing the beginning of the path name. Similarly, if the path name fits in the box and I type past the end of the textbox, the textbox does not scroll so I can no longer tell what I am typing. Working in a nested folder structure is frustrating because every use of advanced-open-file requires that I use a pointer to scroll down the textbox first before I can use it.
Environment OS: OS X El Capitan 10.11.4 Atom: 1.7.3 advanced-open-file: 0.16.2