Link to Edit and Contribute should point to CONTRIBUTING.md

[snipe]

Seems like it would make more sense to have the default "Edit and Contribute" point to the CONTRIBUTING.md when there is one, and maybe default to LICENSE or LICENSE.md if that's not present.

[snipe]

Actually, I see what's happening here now. The _input variable used in theme/templates/includes/book/summary.html seems to replace the url dynamically, so if I'm on a page called features.html within the generated gitbook, that "Edit and Contribute" link changes to features.md in the remote repo (which doesn't exist for me, since the gitbook is documentation of a project in the master branch, while the book lives in the gh-pages branch.)

<li>
    <a href="{{ githubHost }}{{ githubId }}/edit/master/{{ _input }}" target="blank">Edit and Contribute</a>
</li>

If that's actually the intention, it's problematic for a few reasons - the first of which being the use-case I'm describing. My gitbook is actually the documentation for a project, so the md files won't be in the master branch repo I specify in the --github flag while building the book. The documentation md files are on a different branch (gh-pages).

Secondly, it's a confusing UX element, since the other two items in that block (About the Author and Questions and Issues) are persistent throughout the project no matter what page you're on, so having one that changes on the fly based on what part of the book you're in is inconsistent.

My book is here, if you're curious to see an example of what I mean.
http://snipe.github.io/laravel4-starter/

[JonGretar]

👍 on this.

I'm also using to to document a project and would need one of these supported:

• Specify a branch (The book is in the gh-pages branch)
• Specify a project subfolder (Book lives in the project subfolder './documentation')

[kevinpapst]

👍 on this.

I'd like to have an option to skip the "Edit and contribute" link completely or at least specify a base URL, which would allow us to keep the documentation files where we want at GitHub.

In my example the documentation .md file are stored in their own repo, documenting a project which lives in another repository.

[snipe]

@kevinpapst that's my use case as well, although I don't want it to be. Ideally, I'd just be able to run this on a branch of the project for docs instead of taking up two repos. Makes much more sense to me (for my use case) to keep docs and the project together, and allow people to fork and PR on the docs branch.

[SamyPesse]

Ok, with the new configuration design using a book.json file, it's much more easy to add something like,

Let me know if I forgot something:

• Add a configuration to change/disable the author link (default to github profile)
• Add a configuration to change/disable the contribute link (default to github PR).

@snipe @kevinpapst ?

[snipe]

@SamyPesse Thanks so much for working on this so quickly!

I ran npm update gitbook -g to update, and then attempted to build a book:

agianotto$ gitbook build ./docs --output=./source
Starting build ...
SyntaxError: Unexpected token /
    at Object.parse (native)
    at /usr/local/lib/node_modules/gitbook/lib/generate/index.js:74:28
    at _fulfilled (/usr/local/lib/node_modules/gitbook/node_modules/q/q.js:787:54)
    at self.promiseDispatch.done (/usr/local/lib/node_modules/gitbook/node_modules/q/q.js:816:30)
    at Promise.promise.promiseDispatch (/usr/local/lib/node_modules/gitbook/node_modules/q/q.js:749:13)
    at /usr/local/lib/node_modules/gitbook/node_modules/q/q.js:557:44
    at flush (/usr/local/lib/node_modules/gitbook/node_modules/q/q.js:108:17)
    at process._tickCallback (node.js:415:13)

My book.json is located in the root level in docs, same as the SUMMARY.md.

I'm about to hop on a flight out of town for a few days, but I'll definitely check when I get back. I'm sure I donked something up in my rushing around to finish packing.

[snipe]

(Also, thank you so much for building this project - it's wonderful!)

[SamyPesse]

Can you paste me your book.json please.

And you're welcome 😄

[snipe]

Sure, sorry! (As I said, running around packing.)

{
    // Folders to use for output (caution: it override the value from the command line)
    output: "public",

    // Generator to use for building (caution: it override the value from the command line)
    generator: "site",

    // Book title and description (defaults are extracted from the README)
    title: "Documentation for Laravel 4 Bootstrap 3 Starter Site",
    description: null,

    // GitHub informations (defaults are extracted using git)
    github: null,
    githubHost: 'https://github.com/',

    // Plugins list, can contain "-name" for removing default plugins
    plugins: [],

    // Global configuration for plugins
    pluginsConfig: {}
}

[SamyPesse]

Ok, it's not a valid json, you need to remove the comments (that starts with //), you can use http://json.parser.online.fr/ for testing.

[SamyPesse]

Here is the valid json:

{
    "output": "public",
    "title": "Documentation for Laravel 4 Bootstrap 3 Starter Site",
    "plugins": [],
    "pluginsConfig": {}
}

[snipe]

duh OMG so dumb. Thank you. This is what I get for doing too many things at once.

[kevinpapst]

You might want to adjust the docu then, as I would have copy&pasted the code as well ;-)

I'd like to see some switches to adjusted the link destination completely. I am still thinking that keeping the docu in its own repo is a valid usecase and the infos/links are incorrect in such circumstances. The docu will for example get no stars, where the real app does.... and so on.

Should be easy with the book.json to allow overwriting of each config flag. If a setting is explicit given and null or false disable it, if it exists use its value, if it doesn't exist use the default.

[ghost]

Comments in JSON are not semantically valid on purpose, but here's a common technique suggested by Douglas Crockford to annotate your JSON:

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

I like the idea of providing a commented json in order to have a more intuitive config file. Can you pipe it through uglifyjs via Grunt?

[jbryer]

I added the "links" options but it seems to have no effect on the output. I am running 0.4.1.

[erixtekila]

Wait for the new release or clone the repo in your local node_modules folder