Giter VIP home page Giter VIP logo

vscode-markdown-scripture's Introduction

Markdown Scripture

Build Status

Allow your Markdown notes in VS Code to track references and include quotes from verse-based documents such as the Bible.

Table of Contents

Features

Git + Markdown + VS Code (+ the many excellent VS Code extensions for enhanced Markdown) is a very powerful combination of tools for keeping notes on any topic.

With the Markdown Scripture extension, you can leverage these powerful knowledge management tools for Bible study. Markdown Scripture allows you to easily reference and even include scriptural verses in your Markdown notes.

Referencing and including verses

Referencing verses is very simple, using a mostly familiar format of ?[john#3:16-17]. For actual inclusion of the quoted verses, instead of passive referencing, use an exclamation mark: ![john#3:16-17]. Multiple ranges can be specified: ?[john#2:1,4-5]. When a reference cannot be resolved, it is displayed with distinctive markup.

image

Full compatibility with Markdown syntax

All other Markdown markup remains available. For instance, you can use tables to compare multiple translations or to place multiple synoptic Gospels side by side:

image

Configuration

You need to properly configure the Markdown Scripture extension to look for biblical source documents and to make those sources available in your Markdown notes. You can currently add sources in two ways (both ways can be mixed in a single project):

  1. Bibles included with VS Code extensions, including the Markdown Scripture extension itself.
  2. Providing your own Bible(s), locally, within your own notes project.

As with any VS Code extension, the required configuration can be global or local (local meaning the project workspace in which you keep your notes). In the following sections, we'll assume that you will configure Markdown Scripture locally, in a workspace.

Adding sources included with extensions

Currently, the Markdown Scripture extension itself only includes a single translation of the Bible: the publicly available Challoner version of the Douay-Rheims Bible (see SOURCES.md for more details). The set of included sources may be expanded in the future.

To use the included DRC translation, add the following to your workspace configuration (e.g. for a project mynotes, that would be mynotes/.vscode/settings.json):

{
  // ...other config...
  "markdownScripture.sources": [
    { "extension": "swils.markdown-scripture", "include": "en/drc", "ref": "${filename}" },
  ]
}

The extension key tells Markdown Scripture to look for a Bible included within some extension. (Obviously, swils.markdown-scripture is the published name of the Markdown Scripture extension itself.)

The include key specifies which of the Bibles included with this extension you want to add. As mentioned earlier, the Douay-Rheims-Challoner translation (en/drc) is currently the only Bible included with Markdown Scripture.

Each book in a Bible is stored in a separate Markdown file. For instance, john.md stores the Gospel of John and ps.md stores the Book of Psalms (see SOURCES.md for a full overview of all books and their filenames). The ref key tells Markdown Scripture how you want the books of the specified Bible to be made available for referencing. Since we only add a single Bible in the above example configuration, we make each book of that Bible available using only its filename. For instance,

  • the reference ?[john#3:16] will point to John 3:16;
  • the inclusion ![ps#8:2-3] will include Ps 8:2-3.

See below for information on how you can use the ref key to provide multiple Bibles simultaneously in a single workspace.

Providing your own sources

If you want to use your own source documents, such as your own Bible translations, these files can be placed at any location inside the VS Code project where you keep your Markdown notes.

These sources are also just Markdown text documents, but with annotations for chapters and verses. The annotation format was chosen to be lightweight and in line with typical Markdown conventions. You can look for examples within the Markdown Scripture source code. (The format may change in the future to support new features and edge cases.)

Chapters are marked with HTML comment tags of the form <!-- scripture:... -->. For instance:

## Chapter 2 <!-- scripture:2 -->

When Markdown Scripture encounters an annotation like this, it understands that any verses it encounters, from this point until the next chapter marker or until the end of the document, is part of chapter 2 of this document.

The beginning of a verse is marked inline inside regular text paragraphs, using rectangular brackets [ and ]. A verse runs until the next verse marker or until the end of the paragraph:

## Chapter 2 <!-- scripture:2 -->

[1] And the third day, there was a marriage in Cana of Galilee: and the mother of Jesus was there. [2] And Jesus also was invited, and his disciples, to the marriage. [3] And the wine failing, the mother of Jesus saith to him: They have no wine.

Many source texts for translations can be downloaded from the web and annotated using VS Code's powerful regex find-and-replace support. If you have annotated a publicly available Bible translation and consider the result to be of proper quality, you can always contribute it by inclusion in a public extension (see Contributing for more details).

Specifying the location of your own sources

While it is entirely up to you where to put your own source files inside your project, it is necessary to keep texts belonging to the same translation within the same folder. We also recommend to respect the filename conventions for the various books of the Bible.

As an example: imagine that we put the files for a Dutch translation of the Bible (Petrus Canisius) in a local project directory sources/can1939. The following configuration instructs Markdown Scripture to make those source files available as references:

{
  // ...other config...
  "markdownScripture.sources": [
    { "include": "sources/can1939/*.md", "ref": "${filename}" },
  ]
}

As you can see, in contrast to adding an included Bible, we didn't specify an extension key in this configuration. And the include key is now a glob pattern. The result of this configuration is that the reference ?[john#3:16] will point to John 3:16, as found in the local file sources/can1939/john.md.

Including multiple sources

Because we strongly recommend everyone to use the same filename conventions for the books of the Bible across different translations, when adding multiple Bibles to a single project, we need to be able to distinguish them in our references.

For instance, imagine that we want to use both the DRC included with Markdown Scripture and a locally provided translation (Petrus Canisius). Since both contain a Gospel of John stored in a file named john.md, we need to avoid name clashes in our references. The following example configuration does just that:

{
  // ...other config...
  "markdownScripture.sources": [
    { "extension": "swils.markdown-scripture", "include": "en/drc", "ref": "drc/${filename}" },
    { "include": "sources/can1939/*.md", "ref": "${filename}" },
    { "include": "sources/can1939/*.md", "ref": "can1939/${filename}" },
  ]
}

Here, Markdown Scripture is instructed to add two different translations, using three different reference formats:

  • ?[john#3:16] will point to John 3:16 in the Petrus Canisius (can1939) translation;
  • ?[can1939/john#3:16] will also point to John 3:16 in the same Petrus Canisius translation;
  • ?[drc/john#3:16] will point to John 3:16 in the DRC translation.

Changing the verse numbering layout

The way VSCode renders Markdown can be tweaked with custom CSS.

So in the settings file for your project add a line like:

"markdown.styles": ["style.css"]

All verse numbers generated by Markdown Scripture are wrapped in a span element with CSS class md-scripture-verse-num. This means that the file style.css in your project can contain something like this:

.md-scripture-verse-num {
  vertical-align: super;
  font-size: 0.8em;
}

Future plans

  • Customizable book names.

    Some people will prefer john, others will prefer e.g. jn. It is desirable to maintain conventions for book filenames (john.md for the Gospel of John, regardless of translation), but to make them available in your notes using customizable and localized keys.

  • Partial verse references.

    Sometimes a new pericope begins in the middle of a verse. It would be nice to be able to "split" such verses in a reference.

  • Expand the set of available translations.

    The set of available source documents may be expanded in the future to include more languages and multiple relevant editions. These can be made available either within the main extension, or through separate extensions, depending on how things work out. Either approach will undoubtedly benefit from user contributions (see Contributing).

  • Clickable links.

    Clicking your references should open the original text to which the reference links.

  • Note templates.

    Given a pericope (or any given range of verses), it would handy to automatically create the scaffolding for a verse-by-verse commentary on that pericope, using a fixed template.

  • Support for a broader set of classical documents.

    Markdown Scripture depends on a text having small enough parts which are numbered (verses or paragraphs), to allow referencing and inclusion. Next to the Bible there are other texts (e.g. the Summa Theologica or the Catechism) which Markdown Scripture could also support. This requires a more general annotation system which goes beyond chapters and verses.

  • Integration with other Markdown extensions.

    The VSCode marketplace has a number of very nice extensions for general cross-referencing across notes, with support for [[wiki-links]], backlinks and #tags. It would be cool if the Scripture references are integrated with e.g. the backlinks mechanism of the most popular extensions.

... and many other things, given enough time :-)

Contributing

If you want to contribute something, or if you need help setting up your own extension to distribute source documents, contact me privately; or open an issue or PR at Github:

Issues and requests

Issues with this extension or feature requests can be reported here:

Before reporting an issue, make sure to check whether the issue has already been reported.

Release Notes

See CHANGELOG.md.

vscode-markdown-scripture's People

Contributors

swils avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

andrwj johnbeatty

vscode-markdown-scripture's Issues

Next steps?

Hi @swils,

Great work - this looks really useful! I'm interested to know what you have planned next, and if I can help out. I've been thinking about this a bit, and what I'd want from a bible note taking system and:

  • I think something like foam (https://github.com/foambubble/foam) or makrdown-notes (https://github.com/kortina/vscode-markdown-notes) has a lot of functionality (especially backlinks etc. which I think will be really nice e.g. "show me all my notes where I've referenced John 3:16" etc.). No sense reinventing the wheel, so something that integrates nicely with these would be great.
  • Unfortunately, it doesn't seem to support the nested/range structure of verse links (e.g. john#3:16-18). The best you could do would be to create a file per verse and something like john/3/16 or maybe per chapter with john/3#16. Which isn't terrible TBH, and then you get nice code completion etc. - it just makes reading your source bible harder. I don't see how it'd support john/3#16-18 though - we'd need something specific for that.
  • Furthermore, while I like how your extension works, I'd actually want the raw scripture inserted into the markdown, not just into the render. This is because a) it keeps raw markdown powering things (as opposed to relying on this extension/vscode being maintained etc.), and b) it means I can edit the scripture (emphasis, add notes, etc.). NB: A potential downside is that updating references would need a bit of thinking (e.g. if the user has edited an inserted block, and then wants it updated), but that seems doable. This is how https://github.com/kuchejak/obsidian-bible-linker-plugin does it. (The hidden verse references are clever for backlinks to each individual verse.)

Some thoughts:

  • VS Code have just started using a markdown language server. They require you to provide your own markdown-it parser, which you've done. This presumably then gives a lot of things for free (definitions etc.?). I'm not familiar with language servers, but it's possibly a way forward and will eventually mean nice support for e.g. "Go to definition" etc.
  • I really like the create note from selection feature and it could be very useful i.e. navigate to your chapter (possibly in a nice preview window with a search bar?), and while reading select the text you want and "Copy scripture reference" which you can then paste elsewhere.
  • I'd personally accept the superscript 'extension' to Markdown for verse numbers - I find it's just a lot nicer to read. (Already supported in vscode with <sup>1</sup> but not ^1^.)
  • I can't decide on extending [[wikilinks]] and then trying to force other tools to work with it (e.g. verses + ranges). I see three options:
    1. Hack away at existing [[wikilink]] providers to add support for verse ranges etc., and backlinks to sections not files. Potentially a lot of development work maintaining the fork, etc.
    2. Keep [[wikilinks]] but take the approach of https://github.com/kuchejak/obsidian-bible-linker-plugin i.e. a custom command for inserting links to verses. This maintains all the power of backlinks etc., without much effort for the user. But ... I feel like changing/updating links could get messy, and those hidden links are a bit superfluous and might make reading really hard if you use word wrap.
    3. Don't use [[wikilinks]] for bible references (though users may still use it for their notes etc.). Treat the bible linking separately - which is what you're doing by using single square brackets. Anyway, then you could easily have the bible in chapters, or even a single markdown file. Then we roll the linking like you've done (potentially with full inserts of text), and roll our own backlinking (which should be easy to do if it's purely for finding all references to a given bit of scripture.) This does mean you lose the full power of backlinks (e.g. the network graph of foam), but it's also much cleaner to keep it separate from the [[wikilink]] style tools.

There's a lot there, but I'm keen on your thoughts given you've been actively using this, and presumably have researched a lot of other tools.

expand file extensions supported

Hi,

I love the potential of this extension -- thanks for building it! I'll admit that it's only part of what I was hoping for when I went searching for a vscode extension to handle scripture citations. I do have the extension working according to your provided examples; thanks for the good documentation.

I use Quarto for vscode for a lot of my markdown documents, rendering them to PDF or HTML as needed. Quarto req's a .qmd file extension in order to work. But in a lot of other ways, it's still a markdown document before it gets rendered. What I noticed was that this vscode extension does not work for any file extension other than .md. And I couldn't find a way to modify settings to change that behavior. Is there a way?

Minor bug in GIFs

FYI the GIFs show e.g. jn#2:1-3 but these don't work out-of-box currently - they need to be john not jn. I spent a wee while debugging this before figuring it out by accident.

Working with content packs

We need a way to collect source documents (such as Bible translations) into an external content pack and publish that pack independently. This avoids cluttering the main extension repository and will hopefully make contributions or creating other content packs easy.

In the main extension, we need to support the identification of external content packs using configuration settings.

Pericope note creation command

We need a command that creates a new Markdown note for verse-by-verse commentary for a certain range of verses. This should probably be made from a template file that can be used-specified.

Referencing an entire chapter

Something like [book#1] or [book#1-3] is currently not properly parsed. This should work. It means that reference parsing needs to be aware of the source files.

Dealing with book titles such as "2sam"

How can we easily map book references to readable names? E.g. a book in file "2sam.md" should be rendered "2 Sam" in references. Just capitalising doesn't cut it.

Tests open editors in the Extension Development Host

Something in the tests is opening up a number of empty editors in the Extension Development Host. To clean this up, I currently have to add the following to a root hook running after all tests:

await vscode.commands.executeCommand("workbench.action.closeAllEditors");

Find out the cause so that maybe this is no longer necessary.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.