is there an include/source feature?

[ri-aje]

can I have my pet snippet to include another pet snippet and have both available to pet search?
use case: I have some private commands that I sync across multiple machines. in addition to that, I also have some more commands for my work use only and would like clear separation between these two sets. from time to time, I make changes to both sets. my current solution is to sync the two pet snippet files to have the work pet snippet to pick up missing items from private pet snippet. ideally I would like my work pet snippet automatically picks up everything from my private pet snippet. the way I envision this to work is to have my work pet snippet to include the private pet snippet, i.e., an include or source feature. makes sense?

[jaroslawhartman]

That sounds like a good enhancement, @RamiAwar ?

However, I think that concept of "include" has a lot of gotchas and may be a bit challenging to implement:

• Handling circular references
• It is easy to load whole chain of snippets but what to do on save? As for now there is just one Snippets slice and it will be difficult to to refactor this.

Instead of this, my suggestion would be:

Changes

• Instead of a single snippet file, have snippetfile configured as an array:

[General]
  snippetfile = [ "/Users/jhartman/.config/pet/snippet-home.toml" , "/Users/jhartman/.config/pet/snippet-work.toml" ] 

On startup, pet loads all defined snippets.

• Any new snippets defined with pet new would go to a) first (default) file, or b) selected on snippet definition (well, maybe in phase 2 of this enh)

• Add one more layer of on top of Snippets struct, i.e. SnippetFiles (snippet/snippet.go):

type SnippetsFiles {
       Snippets []Snippets
}

type Snippets struct {
        Filename string
	Snippets []SnippetInfo `toml:"snippets"`
}

type SnippetInfo struct {
	Description string   `toml:"description"`
	Command     string   `toml:"command"`
	Tag         []string `toml:"tag"`
	Output      string   `toml:"output"`
}

More impact

• Syncing - an array with elements corresponding to General.snippetfile array:

[Gist]
  file_name = [ "pet-snippet-home.toml", "pet-snippet-work.toml" ]

Optionally, skip sync of a file if empty string provided. Example: sync work to Gist, home to GitLab:

[Gist]
  file_name = [ "", "pet-snippet-work.toml" ]

[GitLab]
  file_name = [ "pet-snippet-home.toml", "" ]

[RamiAwar]

Hey @jaroslawhartman ! So you mean to suggest that because embedding snippets in other snippets is difficult, maybe we can solve part of the problem and allow multiple snippet files?

[jaroslawhartman]

Hi @RamiAwar - yes, I'd say so. Effectively this should allow for configuration separation as requested in this ticket.

[RamiAwar]

@jaroslawhartman Okay, I like the proposal. I think we could start even simpler and only sync the first file in that list. The rest we just ignore.

As for "merging" snippets from different, we just read everything in order. No merging needed, just overwrite where necessary. I don't think we have a unique identifier for a command other than the command itself, and that means only description and tags would be overwritten I guess.

Adding new snippets needs to stay easy though. If we want to support HOME + WORK + other, we have to make adding to any of those 'environments' easy and without workarounds needed. This makes me think we need some identifier for a snippet file, so maybe a simple list is not enough.

I'm imagining the simplest syntax would be something like:
pet new -> Adds to the first snippet file
pet new --space=work -> Adds to the snippet file identified as 'work'

But it does kind of mess with the concept of 'tags' that we already have a bit. I would expect to be able to search across 'work' snippets only, or 'home' snippets only. Maybe we can support this by auto-tagging snippets that come from different files with the file identifier itself (ex. work, home) which re-uses our tags feature.

I might be going a bit too far with this 😁 You tell me!