Unable to see whole path when creating file with very long path/name and dashes

[adamreisnz]

Try creating a new file (or duplicating/renaming one), and type a very long name into the dialog box (e.g. some/path/my-very-very-long-filename-to-test-this-issue).

You will notice that once the text reaches the end of the box, you cannot see the end of the filename anymore. Moving left/right/up/down with arrows doesn't help. Only pressing space seems to trigger the display of the end of the filename.

[mnquintana]

Would you mind attaching a screen capture of this behavior? I can't seem to reproduce this with OS X 10.10.3 and Atom 0.208.0-c06d62e, but I want to make sure I'm looking for the right thing.

[adamreisnz]

Yes, sure thing. Can you recommend a decent screen grabber? I tried Gifgrabber earlier, but it was rather obnoxious...

I'm on OS X 10.10.3 as well, but Atom 0.207.

[mnquintana]

@AdamBuczynski You can try LICEcap (which is what I usually use)

[adamreisnz]

As you can notice, when the filename becomes too long, without spaces/slashes, it doesn't move the view to the "right" to see where you're typing. When using spaces, it does.

[williamboman]

+1. @adambuczynski Have you solved this somehow?

[adamreisnz]

Sorry no I haven't.
@mnquintana could you update the status from more info needed to bug or do you still need more information?

[williamboman]

@adambuczynski Which themes do you use? This seems to be a pretty isolated issue.

[adamreisnz]

That screen cap was with the Atom Dark theme (comes bundled with Atom).

[adamreisnz]

In the One Dark theme, the input box turns to multi line, which is a neat solution:

Maybe the Atom Dark theme can adopt this as well. Is there a issues repository for that specific theme?

[izuzak]

cc @simurai for 🎨 👀

[simurai]

I'm not able to reproduce it. In my case, the file name just keeps moving to the left:

Same thing with One dark.

As you can notice, when the filename becomes too long, without spaces/slashes, it doesn't move the view to the "right" to see where you're typing. When using spaces, it does.

That sounds like the text wraps to a new line. Or it behaves like a multi-line input, with only a height of one line. One dark must have some auto height. Have you tried with atom --safe to only test with core packages?

[adamreisnz]

Same happening with atom --safe

Could you try renaming a file with slashes in the path to see if that makes a difference?

[izuzak]

@simurai 😮 that's strange -- I can definitely reproduce this in the latest master version of Atom (0.211.0-fc4f2a1) in safe mode on OSX 10.10.3 with the Atom Dark theme:

[simurai]

Haa.. me still not and I got the exact same setup as @izuzak.

And just to be sure, what syntax theme? Although I tried all of the core ones. Also retina/non-retina screen.

[izuzak]

Ah man, now it's getting interesting :D I think I see the problem -- I see the same behavior as @simurai if I turn the Soft Wrap config setting OFF, but if I have Soft Wrap turned ON -- I see the behavior described in the issue. Do you see the same, @simurai?

(Syntax theme: Atom dark, UI theme: Atom dark)

[simurai]

Yes, that's it. Kinda makes sense now.

That's something I wondered already a few times. Wouldn't it be simpler to just use <input>s? Or what's the reason that all inputs (like here or in the settings) are full featured atom-text-editors?

[izuzak]

Or what's the reason that all inputs (like here or in the settings) are full featured atom-text-editors?

Wish I could answer that question 😄

However, the interesting thing here is that the OneDark/OneDark theme combo behaves differently than the AtomDark/AtomDark theme combo with the Soft Wrap config setting turned ON -- OneDark/OneDark expands the textbox while the AtomDark/AtomDark doesn't. With the Soft Wrap config setting turned ON -- both theme combos have the same behavior: the textbox scrolls horizontally as you type.

[simurai]

Ya, the mini editors in the One themes don't have a fixed height and just expand if the content grows. I think it wasn't intended like this and is just a lucky side effect of making the UI resizable based on font size.

I guess we could try the same with Atom dark/light. Although other themes will still have this issue. So it might also be worth preventing soft wrap for all mini editors.. maybe not in find+replace?

[acusti]

Should this issue be in a different repo? It isn’t specific to the tree view, but rather applies to any “mini” atom-text-editor. I opened a duplicate issue in atom/atom#7228, but then closed it when I realized it was a duplicate; maybe keeping it there makes more sense, considering that the behavior lives in that repo.

From my perspective, while the One theme behaviour has interesting behavior, that behavior is incidental and the best solution is to disable soft wrap on all mini atom-text-editors. They look like text inputs, so I think user expectation is that they will behave like text inputs. Looking at the TextEditor model, the ignoreInvisibles flag already has special handling (here and here) based on the @mini attribute, so extending those exceptions to include modifying the softWrapped attribute (which is also set on the DisplayBuffer) seems pretty straightforward.

I guess tests for softWrapped would then need to go in the text-editor-spec, though that spec seems pretty low level. Should they instead be part of the “when the 'mini' property is true” suite in the text-editor-component-spec?

Would it be worthwhile at the same time to extend the text editor instantiation tests to check if the constructor sets ignoreInvisibles and softWrapped based on the value of the mini attribute? And to add a separate test of the same behavior for the setMini method?

[louisgv]

Hi all,

How can I temporary fix this behavior? I need soft wrap for coding but also want the horizontal behavior for the mini path editor.

Interestingly, Softwrap was disabled but still work with markdown files:

I'm using Seti UI theme and Monokai Syntax

[simurai]

@acusti They look like text inputs, so I think user expectation is that they will behave like text inputs.

I kinda agree with this. Having the input expand to multiline might work in some cases, but could also cause layout issues.

I opened a duplicate issue in atom/atom#7228, but then closed it when I realized it was a duplicate; maybe keeping it there makes more sense, considering that the behavior lives in that repo.

Yes, now that the root cause (SoftWrap) is known, it would make sense. Maybe issue atom/atom#5503 will take over. Proposal is to have <atom-text-editor>, <atom-text-area> and <atom-text-input> (current mini editor).

---

@louisgv Interestingly, Softwrap was disabled but still work with markdown files

Soft Wrap can be changed on a per language basis. In the settings, try to search for the language-gfm package. There you can enable/disable Soft Wrap for only Markdown files, regardless of your "global" Soft Wrap settings.

[Trudko]

+1 thanks @simurai for workaround.

[swrobel]

Using @simurai's recommended styles.less fix isn't working for me. I tested on multiple themes in Atom 1.2.4 on OS X 10.11. Is there any hope of getting this fixed soon?

[arielnoname]

For the record.
Now: OSX 10.11, Atom 1.2.4
Happened to me since always.

Cheers

[matheussampaio]

I'm still having this issue, even in safe mode.

Versions

Atom : 1.8.0
Node : 6.2.2
OSX: 10.11.5

[clemsos]

Idem here on Debian with Atom 1.2.1

[vekien]

This is still an issue in Atom 1.8 on OSX. With the option Soft Wrap turned on the text goes to a new line. Turning off the option fixes it. @simurai Solution did not work for me (but could be the Theme).

[simurai]

@viion What's the theme you're using? It probably needs a stronger selector.

[Sam-Hoult]

I used the fix from @simurai, but added !important flags:

atom-text-editor[mini] {
  height: auto !important;
  max-height: none !important;
}

[chiangs]

@Sam-Hoult , thanks, the !important flags made the difference for me on v 1.12.9 with Seti-ui theme.

[GioLogist]

@simurai good temp fix!

Any plans on getting this incorporated directly into Atom?

[winstliu]

atom/atom#13764

[chiangs]

@viion, I use advanced-open-file package and it works great with wrapping long file paths/names.

[winstliu]

This will be fixed in Atom 1.17.0.