[help wanted] Remove useless things. Make this package intuitive.

[math2001]

I like the aim I had a few years ago: everything should be fast, and as small as possible (compare FileManager's context menu to SideBarEnhancements). But I now think (realize?) I was wrong about one thing: settings. I just put way too many possible settings that no one uses, and it hides the options that are actually useful (which leads me to doing things like #52).

A good plugin isn't configurable: it takes the decision for you, because the author thought about it a lot, and found the perfect solution, so the user doesn't have to. If there is no perfect solution, only then should the author be allowed to add a setting/option to his plugin. Adding a configuration option should feel like a failure.

I really like andreas kling's opinion about software being discoverable. Having a lot of "useless" options just limits users from enjoying spending time looking around in the settings.

The discoverability of an option should be proportional to the distance between the perfect solution and the current solution. (horrible wording here, it's late ok)

For example, the setting index_folder_separator is technically required in case someone has the good idea of putting > in the root folder name. Come on. Who does that? If you do that, you are pretty much asking for trouble. So, the current solution is nearly perfect, because it works for 99.9999% of the cases. Hence, index_folder_separator shouldn't be "advertised" too hard, because it's not going to serve many people.

But making this package "fun" to explore is also something I do NOT want to do. After spending a few years learning and using vim, I realize that using fancy tools can be a bottle neck too. It takes a lot of time to learn and it clusters your finite brain with more information which might not be that useful. In fact, this is why I'm trying to switch back from vim to sublime text. I feel slower coding like a wizard, because I have to think about how to use my wizard skills rather than thinking about the code.

For example: if someone reads the entire FileManager documentation, then they will have wasted several hours, and clustered their brain with a lot knowledge that will probably never be useful to them.

So, I don't want users to spent any time learning how to use this package. That's a bit extreme, but that's what I'm aiming for. A more realistic version: users should "feel" how to use the plugin straight away. The little that will not be intuitive should be discoverable and succinctly documented. If just an example of code block to copy/paste will do, then just use that. Think of code blocks as pictures. They convey so much more information at once, it's crazy. Words are slow. Use as little of them as possible.

An example where this is done well: when a user right clicks a folder/file. You look at every options, and provided you've used a computer before, you know exactly what each option will do. No need for documentation.

An example where this is not done well: more than one user has thought "How can I disable the default keybinding" alt+n. Why would they think that? Because it overrides their AZERTY default key binding (ref #32).

Where would I look? Probably google first, something like sublime text disable plugin keybinding which gives a few useless links, with the interesting one here.

But that's kind of a pain, and hopefully the user would realize that. Instead, and it's not the most obvious thing in the world, the user could look in FileManager's settings. This should be everyone's default behavior. A plugin doesn't do what I want it to do? Look at it's setting, someone's probably already thought of that. (TODO: quote this in the README).

Right now, the poor user would have to scroll pass useless options to the bottom of the file to find the unclear "create_keybinding_enabled" and set that to false. So, it's not discoverable, though the documentation (the comment above) is succinct.

In fact, it is that unclear and hidden that I even forgot about it, and an issue was raised and remained open for a year, whilst the solution which was implemented 2 years prior to the issue being raised was just lingering around (ref #32)

And that's by no mean the raiser's fault. It's the plugin's fault (so by extension mine). It's not well organized, so people don't know where to look. But that can be fixed 🙂 And this is what this issue is all about.

How can you help

If you have a problem, and it takes more than a minute for you to find the solution, then you should definitely let the package know. Please raise an issue, there's definitely something that can be done about it (change the default behavior so you don't have the problem anymore, and if that can't be done, document it succinctly and somewhere where people will look ie. the readme is my best idea right now).

[math2001]

Reorganize the settings files according to:

The discoverability of an option should be proportional to the distance between the perfect solution and the current solution

FileManager/FileManager.sublime-settings

Lines 2 to 3 in 4ecc88d

	// auto complete with files
	"complete_with_files_too": true,

What does that even do?

FileManager/FileManager.sublime-settings

Lines 5 to 9 in 4ecc88d

	// only relevant if complete_with_files_too is true
	// choose folder over file if folder and file are available for
	// completion. Null means that it will be selected by alphabetic order
	// valid values: "files", "folders", "alphabetic"
	"pick_first": "folders",

name too short. I have to read the comment to know what it does (i should only have to read the comment to learn how to use it, if I can't "feel" that. Ideally, I shouldn't need comment, but come on, I'm not smart enough for that).

FileManager/FileManager.sublime-settings

Lines 11 to 12 in 4ecc88d

	// define if the auto completion case sensitive
	"case_sensitive": false,

name too short. Same as above

FileManager/FileManager.sublime-settings

Lines 14 to 15 in 4ecc88d

	// recommended to be a char that cannot be in a file name
	"index_folder_separator": ">",

I don't know what this does, even reading at the comment.

FileManager/FileManager.sublime-settings

Lines 17 to 19 in 4ecc88d

	// which folder to pick for reference by default
	// (create folder from it)
	"default_index": 0,

why do I have to think about that?? Of course I'm going to pick 0. name to short. Same as above.

FileManager/FileManager.sublime-settings

Lines 21 to 25 in 4ecc88d

	// valid value
	// false: disable the log
	// "user": display a user friendly path. eg: ~/Desktop/ (working on window)
	// "computer": display a computer friendly path: C:\User\<user>\Desktop\
	"log_in_status_bar": "computer",

this shouldn't be an option. Remove it. Choose for the user. Always log the computer friendly path.

FileManager/FileManager.sublime-settings

Lines 27 to 58 in 4ecc88d

	// terminals
	// if there is only one, it will directly open it
	// otherwise, it will open a quick panel with all
	// the name listed
	// example for cmder:
	// { "name": "Cmder", "cmd": ["C:/cmder/cmder.exe", "/SINGLE", "$cwd"] }
	// $cwd will be replaced by the current working directory
	"terminals": [
	{
	"name": "CMD",
	"cmd": ["cmd"],
	"platform": "windows"
	},
	{
	"name": "Terminal",
	"cmd": ["open", "-a", "Terminal", "$cwd"],
	"platform": "osx"
	},
	{
	"name": "iTerm",
	"cmd": ["open", "-a", "iTerm", "$cwd"],
	"platform": "osx"
	},
	{
	"name": "GNOME Terminal",
	"cmd": ["gnome-terminal"],
	"platform": "linux"
	}
	],

good, it's intuitive to use, except for platform which should be called platforms and take a list. The comments should be clearer and more "compact", it doesn't feel like they belong to the terminals setting.

FileManager/FileManager.sublime-settings

Lines 60 to 62 in 4ecc88d

	// If set to true, all the command that are disabled (in grey)
	// will be hidden
	"menu_without_distraction": true,

I like that. Just reading the name I know I want that on. So that probably means it shouldn't be an option in the first place. But it's kind a cute. Should be removed for sure. 🙁

FileManager/FileManager.sublime-settings

Lines 64 to 65 in 4ecc88d

	// no need to comment anything on that one I guess :)
	"auto_close_empty_groups": false,

Remove "funny" comments please. It's not even that obvious.

FileManager/FileManager.sublime-settings

Lines 67 to 70 in 4ecc88d

	// auto refresh the side bar when you run any action that might affect it
	// by default, sublime text would do it by itself, but if this is
	// set to true, then it will be explicitly refreshed
	"explicitly_refresh_sidebar": false,

Is it expensive to always have that on? And by default it's off, and I've never had any problem... I wonder if some people have it on... So maybe it should be removed.

FileManager/FileManager.sublime-settings

Lines 72 to 74 in 4ecc88d

	// if true, each time you create/rename/duplicate etc a file, it will be revealed
	// in the sidebar
	"reveal_in_sidebar": false,

ok that's probably the best one right now. The name explain what it does. The comment is nearly perfect, it could be better if it used a different wording than the setting name (ie. reveal)

FileManager/FileManager.sublime-settings

Lines 76 to 77 in 4ecc88d

	// Save after creating a file (because a snippet can be inserted)
	"save_after_creating": false,

gooood. The comment should give case-scenario example, it's not the clearest (even for me).

FileManager/FileManager.sublime-settings

Lines 79 to 83 in 4ecc88d

	"aliases": {
	"st": "$packages",
	"des": "~/Desktop",
	"here": "$file_path"
	},

Perfect? Don't even need a comment saying you can use aliases within aliases because it does it in the default value, so the user can understand it off the bat. Maybe have a link to the list of default aliases in there though. And explicitly say that these aliases will be added to the default aliases.

FileManager/FileManager.sublime-settings

Lines 85 to 86 in 4ecc88d

	// See https://math2001.github.io/FileManager/aliases/#watch-out-for-infinite-loops
	"open_help_on_alias_infinite_loop": true,

pretty sweet, except the link's broken... The comment should indicate that it'll just open the browser for help.

FileManager/FileManager.sublime-settings

Lines 88 to 106 in 4ecc88d

	// Once again, to improve your speed, if there is commands
	// you never use, you can super easily hide them.
	// You can hide/show every command, and it will have no impact
	// on the other ones.
	"show_create_command": true,
	"show_copy_command": true,
	"show_delete_command": true,
	"show_duplicate_command": true,
	"show_edit_to_the_left_command": true,
	"show_edit_to_the_right_command": true,
	"show_find_in_files_command": true,
	"show_move_command": true,
	"show_open_in_explorer_command": true,
	"show_open_in_browser_command": true,
	"show_open_terminal_command": true,
	"show_rename_command": true,
	"show_create_from_selection_command": true,

I doubt anyone would decide to suddenly "hide" an option. If they do, then maybe that's a sign that it should be removed completely from file manager (a good indicator that I should remove it is me saying "to improve your speed". Don't aim to improve your speed by customizing your plugins. You're wasting your time. Code stuff). But it's cute. Remove it? 😢

FileManager/FileManager.sublime-settings

Lines 108 to 109 in 4ecc88d

	// Set to false to disable the default alt+n key binding
	"create_keybinding_enabled": true

Bad name (no one thinks of "New..." as "create"), but good comment.

[mwchase]

FileManager/FileManager.sublime-settings

Lines 67 to 70 in 4ecc88d

	// auto refresh the side bar when you run any action that might affect it
	// by default, sublime text would do it by itself, but if this is
	// set to true, then it will be explicitly refreshed
	"explicitly_refresh_sidebar": false,

Is it expensive to always have that on? And by default it's off, and I've never had any problem... I wonder if some people have it on... So maybe it should be removed.

I don't know if you mean "remove and act like it's defaulted to true" or "remove and act like it's defaulted to false", but for what it's worth, having it act like it's off (#54) makes the New file/folder stuff really annoying to use, and I haven't yet noticed issues from editing my local copy to force it on.

[TerminalFi]

FileManager/FileManager.sublime-settings

Lines 67 to 70 in 4ecc88d

	// auto refresh the side bar when you run any action that might affect it
	// by default, sublime text would do it by itself, but if this is
	// set to true, then it will be explicitly refreshed
	"explicitly_refresh_sidebar": false,

Is it expensive to always have that on? And by default it's off, and I've never had any problem... I wonder if some people have it on... So maybe it should be removed.

I don't know if you mean "remove and act like it's defaulted to true" or "remove and act like it's defaulted to false", but for what it's worth, having it act like it's off (#54) makes the New file/folder stuff really annoying to use, and I haven't yet noticed issues from editing my local copy to force it on.

What version of ST are you using? And you are saying that it is annoying to have it disabled?