Support relative path for snippet's filename attribute

[csessh]

closes #320

This pull request contains changes to support both relative and absolute path types for snippet file's filename attribute.

Given the test case listed in #320:

The same case presented in the issue

Given this config:

[General]
...
SnippetDirs = []
SnippetFile = "~/.config/test/test.toml"
...

SnippetFile is a relative path which expands to /home/csessh/.config/test/test.toml

Current Pet version:

fw13 :: ~/Documents/pet ‹feat-syspath*› » pet new 
Command> ping google.com
Description> hey Google
fw13 :: ~/Documents/pet ‹feat-syspath*› » cat ~/.config/test/test.toml 
   1   │ 
   2   │ [[Snippets]]
   3   │   Description = "hey Google"
   4   │   Filename = "/home/csessh/.config/test/test.toml"
   5   │   Output = ""
   6   │   Tag = []
   7   │   command = "ping google.com"

As expected, ~/.config/test/test.toml expands to /home/csessh/.config/test/test.toml

Using feature branch version:

fw13 :: ~/Documents/pet ‹feat-syspath*› » go run main.go new      
Command> ping google.com
Description> Hey Goolge
fw13 :: ~/Documents/pet ‹feat-syspath*› » go run main.go edit
fw13 :: ~/Documents/pet ‹feat-syspath*› » cat ~/.config/test/test.toml
   1   │ 
   2   │ [[Snippets]]
   3   │   Description = "Hey Goolge"
   4   │   Filename = "~/.config/test/test.toml"
   5   │   Output = ""
   6   │   Tag = []
   7   │   command = "ping google.com"

file path stays the same. The same result applies for the following test case:

[General]
...
SnippetDirs = []
SnippetFile = "/home/csessh/.config/test/test.toml"
...

Full path is rendered for every snippets.

I didn't go too deep into testing filename with the use of multiple directories as I ran into #321 problem. However, I did include the safeguard check for it in this PR too.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[csessh]

@RamiAwar could you review this PR, please?

[RamiAwar]

How are you handling interaction with snippet directories?

[csessh]

Directories can also be expressed in relative path format, e.g. ~/.config/pet/.
This PR doesn't touch this feature's logic, apart from expanding paths to ensure snippet files can be read/opened.

[csessh]

As mentioned in #321, I made an assumption that if SnippetFile is omitted, it should simply return 0 for line count instead of panicking.

Perhaps whoever understands multiple directories better could correct me here.

[RamiAwar]

hmmm yes let me look into this further.

I'm concerned about having a relative snippet file with directories, not sure how that would be handled.
That's even a concern in the current version of pet where you might have an absolute snippet file path as well as directories. Might not be an issue, just have to look into it and possibly document it.

[csessh]

I think having both SnippetDirs and SnippetFile configurable can be rather confusing due to the lack of signs to indicate which one of those two options should take priority.

I'd propose something like this:

SnippetFiles = ["~/.config/pet/snippet-1.toml", "/var/tmp/pet/snippet-2.toml" ]

This consolidates the option of managing multiple directories under one single configurable item.
If you want to keep everything under a single file, specify a single snippet file.
If you want to manage multiple files, in various directories, specify multiple paths.
When save/edit, a prompt to choose which file to save/edit is simple enough.

Of course, I image it'd be a breaking change.

[csessh]

@RamiAwar I could take a jab at this approach later this week if you think it's worth considering

[RamiAwar]

@csessh sorry I still didn't look into this more, I was actually typing up a reply at some point but lost the tab 😓

I think it's not a problem and there's no work necessary on your end, but I want to better document this. Will respond in a few days time!

[RamiAwar]

Going to add some more context here - will add it to the docs later as well. You don't have to act on this, just FYI, going through this to review your PR properly.

Having the main snippet file is mandatory.

If snippet directories are also configured, then the snippet Load method will load snippets from the main file + all files inside the snippet directory!

What does this mean for:
1- Edits: How do we edit a snippet if it can be part of any of several files? -> We make the user select the snippet they want to edit first, which tells us which file we should open for editing.

This is still not amazing UX because we send them to the beginning of the file and not the correct snippet line - this should be fixed. (should add a test for this, making sure we jump to the right line + fix it)

2- Search: We just search across all snippets from all files.

More fundamental operations:

3- Load: Loads snippets from the core file (mandatory) + all the files in all directories specified into one big list. Nice, expected.

4- Save: Given a slice of SnippetInfo, this loops over every snippet and checks its filename. This logic doesn't look right to me - we're just overwriting the snippetFile as we loop through? If it's empty, we're setting it to the FIRST snippet directory + a custom file name (???).

I think here it was meant to be snippet.Filename maybe. This definitely seems like a bug, consistent with what you reported in that issue #321 I think.

[RamiAwar]

Do you think it makes sense for the sync to only sync the main snippet file and ignore files in the directories?

I want to try and avoid having to sync multiple files and keep track of each. Directories are nice, but I want to keep it a 'secondary' feature until I iron out the kinks. There are quite some bugs

[RamiAwar]

#323 fixes some of these

[csessh]

It'll be fine if it's communicated clearly in the tool's documentation that only main snippet file is sync'd.
I, personally, don't use directories. sync or not.

[csessh]

Resolved conflicts

[RamiAwar]

Awesome, thank you! @csessh Will review this carefully this week. Thanks for waiting 🙏🏼 ✨