Allow easily getting full note paths, for compatibility with other commands

[pimterry]

Outputting nice short names (just note.md) is great for readability when flicking through your notes. For compatibility with other commands though (e.g. cat: #9), you need a way to easily get the full file path (/home/tim/notes/note.md).

There's a couple of options:

• Only output short names to a TTY, but automatically output full paths instead when piping.
• Add a notes path command, which gives you the path to a given note (useful generally), or transforms a pipe of short note names into full note paths. E.g. notes find | notes path to get the full paths for every note you have.

Thoughts welcome!

[primis]

We could add a switch like -p rather than a whole subcommand.

[primis]

I was doing some initial research into this, The outputting short names to TTY option is good in theory, however, it breaks over SSH (since an ssh session isn't a real TTY). As an aside, it casually breaks most of our automated tests, since they don't emulate a tty proper either. While I can deal with breaking tests (They're fixable) the SSH problem is slightly more complex. I'll have to look into it a bit more to see if there's anything else to help with that problem.

[pimterry]

@primis Any progress?

The SSH issue is interesting, and if you do manage to find a solution that solves that too, that'd be great. I think it might be ok anyway though, as long as the output is still correct and useful even if a TTY isn't available. Essentially, we could optimise for human reading if there's a TTY, and we drop the niceties if there isn't, but still come back with essentially the same information. E.g:

With TTY:

> notes find
work/a-note
plans

When piping, or using over SSH:

> notes find
/home/user/notes/work/a-note.md
/home/user/notes/plans.md

It's not quite a nice or easy, but it's still perfectly workable as a fallback. We could provide an option/extra command that would override to force pretty formatting, for cases where that's important.

That means the key constraint to this are:

• When piping we always output the computer-readable content (we have to be able to guarantee this is true for this to work properly)
• Only when we know for sure that we're outputting to a person do we output human-readable content
• If we're not sure, we output computer-readable content by default
• Human-readable formatting for a given command can be anything we like, but should be pretty close to the computer readable version (e.g. short note paths, maybe include extra colourization or highlighting or note snippets, but the same core info)
• Computer-readable formatting should output the minimum core information for the next command, but still in a way that a human can use it perfectly effectively

[primis]

@pimterry I'll get to work on a PR to satisfy that request. In the meantime, would you mind reviewing the pull request I made for the install script? (#36)

[pimterry]

Yep, on it. Busy few weeks, I'm just starting to go through and test it at the moment.

[primis]

Fixed the "SSH is seen as a pipe" error. changed very little existing code to do this too. Managed to update tests not to break by adding in a path suppressant switch (I also added a faketty function, but it's rarely needed except to actually test the suppressant)

[primis]

I dropped the PR since the code is now dated.