Opening the panel should default to root of currently open project

[ken-guru]

At the moment the panel opens with the path of the currently open file. More often than not I need to create a file in another directory, thus writing / tab completing the desired path would be quicker than having to remove the undesired parts of the automatically filled path before starting to write my desired path. Could also be implemented as a setting allowing the current behaviour to remain available if the user prefers it.

[Osmose]

I'm down with a preference for starting with a blank path instead of with the current file's directory. Thanks for the suggestion!

[crossman]

This was the first option I went looking for after switching

[jesseleite]

+1 for starting fresh from project path :)

I'm nearly always working from within a project repo, and rarely care about the deep folder structure outside of my project. Didn't Advanced-New-File default to blank path relative to project root. @Osmose was this an intended change after you forked?

Create and open multiple files and directories by typing a relative path.

^ Your package suggests relative path, but you show absolute path? :P

Anyway, thank you for your work on this :) Glad to see someone pick it up if @Trudko cannot maintain. Thank you @Trudko and @rev087 as well.

[Osmose]

Didn't Advanced-New-File default to blank path relative to project root. @Osmose was this an intended change after you forked?

It was. My personal use of advanced-open-file is mostly opening files outside of the project root, and having the current file's path pre-filled in is a preference I got from Emacs. But I'm totally down with making the old behavior possible.

^ Your package suggests relative path, but you show absolute path? :P

Yeeeeeeeeeaaaaaaaaaahhhhhhhhh

So after thinking this over, I think there are two things to do:

1. Add a preference for the default input value on toggle, with three options: Blank, Project Root, or Current File's Directory.
2. If a path in the input has a leading slash, consider it relative to the project root. If it has a leading slash, consider it absolute.

This way, if you want the old behavior of blank and relative, you use the Blank option and just start typing. I'll start work on PRs for this; in the meantime, any objections?

[jesseleite]

@Osmose, I don't have objections to more options :) Sounds great, though I am a bit confused on the details.

Add a preference for the default input value on toggle, with three options: Blank, Project Root, or Current File's Directory.

Confused on difference between blank and project root.

If a path in the input has a leading slash, consider it relative to the project root. If it has a leading slash, consider it absolute.

I assume the above pertains to the "Blank" option?

• If input is Blank (no leading slash), then it's relative to project root.
• If input is Blank, but you add leading slash, then it's absolute path.

If so, sounds great! I might suggest renaming "Blank" to "Project Blank" or something similar for clarity. You'd have these three options:

• Project Blank (as described above)
• Project Root (always starts at project root, but shows absolute path)
• Current File's Directory (as it behaves now)

All this combined with your Helm-style fast directory switching, sounds golden I think.

Thoughts?

[Osmose]

The preference pertains only to the default value of the input, and is separate from the relative path handling. So blank means that it has nothing in it, project root means it has the absolute path to the project root, and current file's directory is the current behavior.

Then, separate from that, when parsing the path in the input, a leading slash means the path is absolute, and no leading slash means it's relative to the project root.

So setting it to blank, along with the proposed relative path handling, is the behavior you want. But even if I have it set to Current File's Directory, I can still Cmd-A+Backspace to clear out the input, and enter in a relative path.

That make sense? Maybe it's confusing; we'll have to see what the README looks like to tell if users will be confused enough for it to cause problems.

[jesseleite]

Gotter. Sounds great to me 👍

[ken-guru]

This sounds like a good approach to the issue, and should probably be flexible enough for most users.

[Osmose]

Both features have been merged. I'm about to do a quick test to make sure everything is good and then release 0.9.0, which will have both these features enabled. Let me know how it goes, and thanks for all the help!

[jesseleite]

@Osmose: Nice. Seems to work well. Questions for you:

1. With Helm style option, would it make sense to ~ for home folder, instead of ~+/ (is the slash necessary for this)?
2. I'm nitpicking here, but the new + icons for adding folder to tree don't seem very well aligned to the right :P

Thanks for your work on this btw, I like the default blank option!

[Osmose]

With Helm style option, would it make sense to ~ for home folder, instead of ~+/ (is the slash necessary for this)?

I think so, mainly because it is possible to have a file or directory that starts with a ~. It's more consistent to treat it as a prefix until the / is typed than it is to specially consider it to be the home directory.

I'm nitpicking here, but the new + icons for adding folder to tree don't seem very well aligned to the right :P

How so? Is it that there's slightly padding on their right than there is on the left of the folder icons?

[ken-guru]

With Helm style option, would it make sense to ~ for home folder, instead of ~+/ (is the slash necessary for this)?

I think so, mainly because it is possible to have a file or directory that starts with a ~. It's more consistent to treat it as a prefix until the / is typed than it is to specially consider it to be the home directory.

Also ~/ is a standard unix way to indicate the home directory. In that context writing e.g. ~/workspace indicates the directory named workspace within the current user's home directory, where ~username/workspace indicates the directory named workspace within the home directory of the user named username.

[jesseleite]

@Osmose @ken-guru, Ah great explanation on ~/, thank you!

Is it that there's slightly padding on their right than there is on the left of the folder icons?

Yeah, I'm totally nitpicking. It's not that important :P I added some style modifications to show you my suggestions:

Before: http://b3.ms/8Wj9oPvDALKg

.advanced-open-file {
    .icon-file-add,
    .icon-file-directory-create {
        padding-left: 10px;
    }
    .add-project-folder {
        margin-right: -12px;
    }
}

After: http://b3.ms/we0AGVDg9mx5

The folder/file icons and plus icons are now more equally padded between left and right side of panel, as well as top and bottom of panel. I'm pixel pushing here, sorry lol :D

[Osmose]

I'm pixel pushing here, sorry lol :D

By sorry you mean "You're welcome", right? :P

It really does look better! I can merge a PR if you submit one, otherwise I'll get around to adding that CSS soonish. Thanks!

[jesseleite]

No problem, I'll PR for you :) See: https://github.com/Osmose/advanced-open-file/pull/31