Feature to Export to Html?

[gkielian]

Would it be possible to add a feature to export a certain note or set of notes to html?

Currently doing this with regex, but would be cool if it was officially supported : )

[lambtho12]

Not sure if it fits here. There are already countless options to convert markdown to html (pandoc being the first that comes to my mind). I think we should try to limit ourselves to note making/editing in nvim and let other plugins/external do other stuff.
IMO the goal is not to re-make a complete note editor that can do a billion different stuff. But I may be wrong and I am not the original creator of Telekasten... So maybe Rene can chime in at some point when he gets time.

Could you detail a bit more your workflow or what you have in mind?

[cnshsliu]

Agree. Markdown to HTML has many tools available already.

[TheTaoOfSu]

I think this would be great for some use cases, particularly where content might be published online. Some of my vaults are personal, but some of mine could be shared with relevant groups, and automated export would be very useful for maintaining current copies in formats other than the one I prefer to work in.

I'm considering trying to implement something like this using pandoc. Ideally, it would be enabled and disabled on a per-vault basis, probably defaulted to off, and you could preset all the configurations like where to put the exports, what file type(s) you want to export to, etc.. It would trigger on writing to the file, exporting to one or more alternative formats and placing them in the appropriate folder(s).

Using pandoc has the benefits of outsourcing all the actual conversion work, providing coverage for a wide range of file formats, and allowing users of uncommon file types to define their own conversions in Lua. It would also be relatively easy to tie in since you only need to define and monitor a trigger (write to a file set to export), then execute a system command and monitor a bit of the output for error reporting.

I'm enjoying the plugin, and I'd like to learn a bit about neovim plugin dev and Lua, so I'd like to try to implement this. I've been considering this and a few other things that seem small to me, at least, but the rest are best suited for other discussions.

[lambtho12]

As already answered above, I still think this is something that should be the core of an other plugin. If you look, this is already the case for markdown previewers. Adding this feature to Telekasten will only lead to slower development (which is definitely already too slow as it is) and increase maintenance difficulties. I really see no benefit of integrating that to Telekasten directly.

[TheTaoOfSu]

I think it depends a bit on if you use Telekasten as a wiki or as a zettlekasten, and both are listed as intended use cases. A zettlekasten is a personal knowledge repository, and its structure is often highly personalized or simply a pile of connected notes. A wiki, on the other hand, tends to be more structured, which lends much better to sharing. Markdown previewers are great for personal use, but if you want to share anything you've created, you need something else.

And that's really the crux of it. Telekasten manages most aspects of collecting, organizing, and utilizing information for yourself, but some knowledge is meant to be shared, and it could do more to facilitate that. I personally like working in neovim, but the vast majority of people won't even touch it. Even if I could convince people to do so, sharing the files and using them through neovim is clunky. I want my workflow to be primarily through the Telekasten in neovim, but I have to reconcile that with the fact that some of what I'm creating is intended to be shared, and the easiest way to do that is to convert to file types that are more cumbersome to work in like HTML or dokuwiki .txt files that can be synced to an existing server install. However, since not all vaults are intended to be exported, this can't be set to simply be done to all .md files or whatever my relevant file extension is. I need it configured on a per-vault basis, which is why I think it should be implemented directly in Telekasten, not as another plugin. Given all it needs to do is execute a single pandoc command on file write, it doesn't even need an entirely new plugin.

As for the development expense, as I mentioned above, this is something I'm personally considering implementing, so it would be of no detriment to other development efforts. It would be my first foray into Neovim plugin development, but it seems rather manageable from my current understanding. It would require a few configuration options, but all it really needs to do is manage autocommands that trigger on write to files in the vault. Telekasten already has a setting to take over the home directory, so it's already able to tell when you're editing a file in a vault. It would only need to extend that check a little further to see if automatic export should be enabled and, if so, to set the autocommands.

Unless you're quite against the effort, I would like to open an issue soon to detail what I think an implementation of this feature might look like and make sure there are no complaints or suggestions before I begin attempting to implement it.

[lambtho12]

I do understand the desire for a HTML viewer or something to export the notes in a more easily "browsable" way for non-vim users.

However, since not all vaults are intended to be exported, this can't be set to simply be done to all .md files or whatever my relevant file extension is.

Vaults are just a directory on your machine, so it is not like it is something specific to telekasten that can not be used easily by external tools.

Given all it needs to do is execute a single pandoc command on file write, it doesn't even need an entirely new plugin.

I am not familiar with pandoc. If it is indeed a single command, sure we can do that. But then people will ask for an other tool to convert to HTML because they do not like pandoc, etc. What I want to avoid is to add 250 lines of code for a feature that can be handled externally very easily.

As for the development expense, as I mentioned above, this is something I'm personally considering implementing, so it would be of no detriment to other development efforts

If it is just a single pandoc command, I am all in for that. A basic implementation as below would allow the creation of simple custom mappings, as well as the extensibility to other tools in the future.

local function MakeHtml(opts)
    opts.dir = <VAULT DIRECTORY PLAEHOLDER>
    opts.software = opts.software or "pandoc"
    opts.args = opts.args or ""
 
    <IMPLEMENTATION>
end

[TheTaoOfSu]

Okay, so I managed to spend some time thinking about what an actual implementation would look like, and I did find just one thing that would need to be processed: links. There are two cases here that I see.

In the first case, the user is using pure markdown. This is unlikely given the current state of support for markdown links, but it's the easiest to handle. Links are direct to files, even if only relative to the current note, and they include an extension. If everything is being exported to a different format, all these links will break, so links would need to be parsed so that internal links (and only internal links) can be modified to take the proper new extension based on the export format. The act of editing the link should be easy, and I think detecting internal link shouldn't be too complicated. Logic may exist in the function for following links, but I have not had the opportunity to examine that yet. Either way, the file as saved by the user can't be exported directly, so it may require the creation of a temp file? I'm not quite sure yet and haven't been able to look deeper.

In the second case, the user is using Telekasten's wiki style links. This actually complicates things because Telekasten mostly uses markdown, so most converters are going to expect markdown links, and these links are based on a note's title, not it's file location. There's already code to follow these links, so we can probably leverage that to get the link's true location, but we might have to then replace the wiki style link with a markdown style link that a converter will expect.

I would like to note that while the first case could be arguably handled through an external tool, the second case cannot specifically due to Telekasten's blend of formats. If it had simply adopted an existing wiki format or stuck with pure markdown, it would be much easier to pass off to converters like Pandoc, but the blend of styles will require some purification.

All in all, this still doesn't seem too complicated. Definitely more complicated than I initially expected, but not excessively so. Nevertheless, since the only complication is links, I think I would like to help with markdown link support first, as has come up in another discussion thread. Refactoring did, too, so this may be a good time to simplify some functions. For example, the function to follow links probably handles locating the appropriate file and opening it (could be wrong, haven't gotten to look yet), but if locating the appropriate file was its own function called by the follow link function, it can be also be used to find the location of links being fixed on export without duplicating code.