Allow specifying additional notebooks in CLI

[srid]

Add a way to specify additional notebook paths (they are ultimately "merged" in order).

• Rethink Ema's -C argument (chdir behave makes no sense with multiple arguments)
• Implement this issue

---

Proposed CLI:

# Does nothing; just prints --help
emanote

# Fails, because requires a path argument
emanote run

# Runs emanote live server on the given folder (the only layer)
emanote run .

# Runs emanote gen command, with the given layers in argument order
emanote gen ./.deploy/github ./

# Run emanote live server on current directory, using common themes and public notes (3 layers)
cd ~/MyPrivateNotes
emanote run ~/myemanotethemes ~/MyPublicNotes ./

Originally posted by @srid in #20 (comment)

---

Implementation:

Consider extending fsLayers based on the paths passed in CLI,

emanote/src/Emanote/Source.hs

Lines 22 to 24 in 78c9a2c

	fsLayers <- liftIO locLayers
	Mount.unionMountOnLVar
	fsLayers

This may involve replacing LocUser with a LocUserProvided FilePath

emanote/src/Emanote/Source/Loc.hs

Lines 7 to 15 in 78c9a2c

	-- | Location of the notebook, even if it contains a subset of files.
	--
	-- The order here matters. Top = higher precedence.
	data Loc
	= -- | This always refers to current working directory
	LocUser
	| -- | The location of the emanote's default files directory containing
	-- templates, data, etc.
	LocEmanoteDefault FilePath

[hi-learn-triz-and-usit]

Why do we prefer files from the right over files from the left? The main functional advantage of that comes up when programmatically constructing the command, but I don't think that's a likely situation; otherwise it's a matter of perspective and aesthetics.

[srid]

It's the more natural order to me (you stack 'em up on top of another as you read left-to-right; plus the 'common' stuff gets put ahead, and you can create shell aliases easily that way), and I doubt most users would find it non-intuitive (but if they did, it can be changed).

[srid]

contd. from #20 (comment)

LocUser (NonEmpty FilePath)

Actually it should just be LocUser FilePath. However, we break the order assumption ... hmm gotta think.

EDIT: some options available,

• use LocUser Int FilePath (where the Ind acts as an index), but that is hackish.
• use https://hackage.haskell.org/package/ordered-containers-0.2.2/docs/Data-Set-Ordered.html

Option 3: Refactor Mount.hs to use NonEmpty source instead of Set source, and pass this non-empty list all the way from CLI parser. Ensure that unionMount retains this order when calling the change handler. Probably the simplest option.

[hi-learn-triz-and-usit]

# Run emanote live server on current directory, using common themes and public notes (3 layers)
cd ~/MyPrivateNotes
emanote run ~/myemanotethemes ~/MyPublicNotes ./

When wouldn't we want to include public notes and common themes when running emanote in MyPrivateNotes? Because if the answer is "never", and in fact if it doesn't even make sense to do so (because some links or themes will be broken) shouldn't the first two layers be part of the configuration file of the third layer?

Basically, I'm suggesting that the overlay graph should be expressed using an implicit linked list (or more generally a dag) in the configuration files of the layers (each layer has the option to point to layers it depends on). This handles the common use case, where a site is built up of pieces, without complicating the interface. This does not handle the case where we want to easily be able to swap the pieces; my question is whether this is actually a thing users will want to do.