Dedicated Snippets folder and scripts for snippet management

[petrowsky]

Added two AppleScripts which allow for managing a library of Snippets within a dedicated Snippets folder. One script opens the folder for management within the OS and the other simply presents a file chooser and copies the contents to the clipboard and converts to FM Objects.

If the changes to using notification center over dialogs is undesirable you can revert those. Or, I can make a new patch.

[petrowsky]

Oh, and also added some example scripts. If you didn't want to include sample scripts you could simply put a README within the Snippets folder providing instructions about how to use the folder.

Suggested subfolders for anyone who wants to use these scripts would be

• Fields
• Functions
• Layouts
• Menus
• Scripts
• Steps
• Tables
• Themes

[DanShockley]

Matt, I like the Snippets folder idea, and thank you for switching over some of the dialogs to use notifications.
I'm thinking about the Snippets folder contents. Including the contents lets us use this repository as a way to share useful objects. But, it means that anyone using git to keep FmClipTools up-to-date as a user would lose their own changes/additions.
I think, ideally, we would need to have a Snippets Shared folder that is part of the project, and that those of us contributing can agree on adding useful objects, while also having a Snippets Private folder that gets created when Snippets are first used, and which the user can then modify, while git is set to ignore it.
Actually, perhaps there should be a Private folder within FmClipTools. In it could go a Snippets Private folder, but possibly also other user-specific preferences used by FmClipTools. For example, a FmClipTools.config file could be in Private which lets a user exclude "Snippets Shared" they do not want to see.
Thoughts?

[jwillinghalpern]

This is really well done!

I tend to think this repo should avoid become a repository of blessed snippets because reconciling everyone's opinions sounds difficult. Including some sample snippets is smart, but as someone with my own large library of snippets already, I'd prefer to see any included snippets treated as examples rather than "official".

I like the idea of creating a config file somewhere and potentially even an AppleScript to open that config file in Finder and/or a default code editor. Users/<USER>/Application Support is a common location for that kind of thing. And maybe that config file could point to the user's chosen snippet folder? Just brainstorming.

I should also add for transparency, that I probably won't personally use the Snippets Select Snippet feature much (even though it works great), because I'm not a big fan of the MacOS file dialog for searching snippets. But I do see value in having a built in way to save and use snippets for users who want a one-stop-shop and don't want to roll their own in a tool like Typinator.

[petrowsky]

I only added the few example scripts so it would showcase just one of the many methods of Snippet organization. I would personally just add the Snippets folder itself and included a README.md file with information about the various methods of snippet organization. Leave the Snippets folder empty for the end user to choose how they want to organize/manage things. Here are just a few of the possible ways.

• Snippets -> flat list of plain text snippet files.
• Snippets -> folders breaking down classes/categories of snippets. (e.g. Layout/Menu/Steps/Scripts...)
• Snippets -> git submodules
• Snippets -> One or more symlinks to various snippet repos.

Essentially, the goal would be a single location which is easy to open. If the end user chooses to enable the Script menu in the menu bar then a simple script to open this folder is effective in getting the end user to their starting point. Whether managing their own personal flat list or managing a folder hierarchy of multiple git submodules.

I would not use the /Application Support folder as this is typically reserved for applications to use since it is behind the hidden ~/Library folder. All you need is a dedicated folder and then let the user decide how they want to use it. I agree with @jwillinghalpern in that it should not be a repo of snippets. That was not my intention. I only included the examples to give you a taste of what would be possible.

There are MANY various tools in which snippets can be loaded onto the clipboard. I personally use BetterTouchTool and LaunchBar. But I'm aware of the original Quicksilver, Raycast, Alfred, TypeIt4Me, Typinator and others.

Create a branch and merge in the pull. Get rid of the example scripts and put a link into a README.md within Snippets pointing the user to possible snippet repos and info about organization options. Ultimately, you just need a way for the user to open a singular location and a way to load things from that location.

[DanShockley]

So, since I might want to start using the Snippets folder myself, while still being able to push my changes to the project, I'm thinking I will do the following:

1. Merge this pull request into my master branch. I don't think I need a separate branch for it, do I?
2. Delete the Snippets folder entirely, but modify the Snippets script to create it if it does not exist.
3. Commit and push those changes.
4. Add the Snippets folder to the .gitignore file so that a user's (including us!) own future customizations are not removed if they use git to sync the project.
5. Add an explanation to the README.md about what the Snippets folder does.

For the config file idea, which we wouldn't yet need for the above, I'm considering the following:

1. Add a config-sample.txt file to the project, which will gradually include examples of settings a user can put into an actual config.txt file within their own FmClipTools folder.
2. Make sure that config.txt is in the .gitignore list so that a user retains their own customized settings.

I like the idea of having customizable settings, especially since some of the scripts currently have internal properties that can be switched on or off, and users might want, for example, to re-enable the automatic "prettification" of XML, as long as they are aware of the downsides/risks involved.

Either of you have any suggested changes to the above two courses of action? Anyone else?

[petrowsky]

So, since I might want to start using the Snippets folder myself, while still being able to push my changes to the project, I'm thinking I will do the following:

1. Merge this pull request into my master branch. I don't think I need a separate branch for it, do I?

If you make a 'working' branch, then you can merge the pull into that branch and make the changes you want. Then you can merge that into your master branch. But that's just one way of doing things. You're the repo owner so you can do what you want with the pull.

2. Delete the Snippets folder entirely, but modify the Snippets script to create it if it does not exist.

I would ask why? Why create code just to create a folder when it can already be part of your code structure.

You can even just merge the existing pull and then just delete the examples and create the README within Snippets. It's just another commit and if anyone was ever interested they can read the commit log.

3. Commit and push those changes.
4. Add the Snippets folder to the .gitignore file so that a user's (including us!) own future customizations are not removed if they use git to sync the project.

If you're going to treat a folder named Snippets as your starting point for entry into managing one or multiple sources of snippet code, then why ignore it. As part of your code structure you're simply saying "This code references a folder named Snippets. Anything you put in there will be accessible once the Snippets folder is opened." This is no different than any other repository which chooses to use src, dist, build, etc. It's simply the choice of a name of a folder which your code references or stores things.

5. Add an explanation to the README.md about what the Snippets folder does.

Yep. People always like documentation about how things work.

For the config file idea, which we wouldn't yet need for the above, I'm considering the following:

1. Add a config-sample.txt file to the project, which will gradually include examples of settings a user can put into an actual config.txt file within their own FmClipTools folder.
2. Make sure that config.txt is in the .gitignore list so that a user retains their own customized settings.

I like the idea of having customizable settings, especially since some of the scripts currently have internal properties that can be switched on or off, and users might want, for example, to re-enable the automatic "prettification" of XML, as long as they are aware of the downsides/risks involved.

Either of you have any suggested changes to the above two courses of action? Anyone else?

Personally, you're simply providing some executable code which is not super complex. Adding a config setup seems a bit much unless your AppleScripts are going to reference that config.

And...if you are going to use a config file, then the natural choice would seem to be a .plist as AppleScript is an Apple technology. Using something like a plain .txt, .json or .yml would require translation. Where you can likely directly access the config settings using a .plist. Here's some sample code

[DanShockley]

On the Snippets folder:
Perhaps I'm missing something with how git works. If I do not set the Snippets folder to be ignored, and I put my own code into the Snippets folder, which is the repo for this project, then when I make any other changes and push them, my own personal Snippets will be pushed into the project, right? Is there a way to avoid having that happen?

On having a config file:
I was proposing that the AppleScripts could check for the presence of a config file and use that to override internal defaults within the script. Similar to my question above, that would allow people to use git to keep the script up-to-date without losing their own personalizations.
I like your point about using a plist file instead of some arbitrary txt format. I've used that before elsewhere, and it makes a lot of sense.

For both of these, I'm wondering if there is a way of using git that makes my concerns moot. If so, can you point me in the right direction?

[petrowsky]

Probably a communication/wording issue. You said "Add the Snippets folder to the .gitignore file", in which adding Snippets to .gitignore is different than adding Snippets/*. By including the Snippets folder within your repo, you are declaring that it is your official location. Hence your AppleScript for opening that specific folder relative to your root.

So, I would suggest committing the folder Snippets and one included file named README.md to your repo. You would then add Snippets/* with the wildcard to ignore all things added to that folder subsequently.

When you say "Add the Snippets folder to .gitignore...", that is different than saying ignore the contents of the Snippets folder.

The Snippets folder would be your root starting point for all snippets. In my personal use case, I will be using git submodules to point to multiple external repositories of snippets, plus including my own collection in that root. It currently looks like this.

Snippets
	Fields
	Functions
	Layouts
	Menus
	Scripts
	Steps
	Tables
	Themes
	External
		filemakerstandards_repo
		private_collection_repo

[DanShockley]

Ha! Thank you, Matt. I actually hadn't realized that the .gitignore would support a wildcard like that, but of course it would. That makes a lot of sense. I'll do that.

I'll also do the config.plist, if/when I find a few places in the various scripts where a user might want to customize default behaviors.

[petrowsky]

Can I get some eyes on this and get a merge. If not, then just let me know and I'll maintain my own fork and close this merge request. The only things happening, other than the added two AppleScripts used for folder interaction, and the Snippets folder being updated in .gitignore, is the one remaining revision to Scripts/fmClip - Clipboard XML to FM Objects.applescript where I had updated the dialog to an OS notification.

If you don't want the updates using Notifications instead of dialogs then let me know and I'll revert that in my branch and you can merge this in with it's innocuous use of an empty Snippets folder (where I will personally be using git submodules to manage my own snippet collections). If you don't want to identify the Snippets folder as a convenience to end users, then let me know and I'll close this request or you can close it yourself as an indication that you don't want to suggest a dedicated Snippets folder for end-user managed snippets.

[DanShockley]

Update: I plan to make the changes Matt recommended next week. Hopefully my schedule will be agreeable. Thanks for the advice and the proposed changes, Matt!