Option for markdown syntax.

[GordianDziwis]

Hi,

I think markdown support would be a nice addition to taskwiki. With markdown support we could use taskwiki in any markdown document. @tbabej how much effort would this take?

Cheers

[tbabej]

Hard to tell. It does not seem like a super extensive piece of work, since taskwiki is written fairly sanely, but it's something I can't devote myself at the moment (and likely motivation will be lacking in the future as well, even if time allows).

To sum up the changes, one would need to:

• Think up suitable markdown-friendly viewport and task syntax
• Implement some kind of decision logic that determines the file format used (are we in a markdown file? or mediawiki? should we work both in mediawiki/markdown? probably some user options / reuse of vimwiki options is at place here)
• Create markdown-specific regexes for taskwiki object parsing
• Write a lot of tests for markdown parsing (due to our test framework, this is actually quite fun)
• Create additional logic to be able write objects down to the text file in either markdown/mediawiki format (currently mediawiki format is hardcoded) - I would like it if this became its own layer, which would handle format-dependent parsing and text generation

Just from the top of my head, there might be some additional complications involved.

[GordianDziwis]

I underestimated the effort, right know I am not procrastinating that hard. Thanks for the write up!

[DancingQuanta]

I like to see this feature though :) Would it be worth to generalise the code into layers, one of these layers works with syntax and other manage tasks with taskwarrior? I believe that taskwiki should use vim_wiki lists options to choose syntax and separate tasks data directory as in #83.

[tbabej]

It would certainly be worth the effort. Abstracting syntax-specific stuff should not be that hard, most syntax elements are realized using regexes that parse the lines content. We would need to introduce a layer that would offer the correct version of regexes depending on the current syntax being used.

[DancingQuanta]

The regexes could be loaded depending on vimwiki's list that specifies the syntax used or by filetype.

[tbabej]

Indeed, automated syntax detection as well as manual overrides via taskwiki config options would be desired.

[DancingQuanta]

I have found that a restructuredtext wiki plugin called riv.vim also supports checkboxes under the name of Todo list (I have been looking into moving from markdown to restructuredtext for sometime). This may means that taskwiki must have its own wiki list rather than rely on vimwiki list options. I will investigate the source code of taskwiki and see if I could abstract away any syntax.

[DancingQuanta]

My idea for the header view port is to let the user define the pre and post syntax.

pre HEADER | FILTER post

So for the vimwiki, both the pre and post are the same eg variation of = which I believe that the regexes can cover by matching pre with start of line, a number of = and a space before HEADER and post regex match a space, a number of = and end of line.

However markdown is not one syntax, there are a number of different flavours of markdown and this shows in their headers. There are two types of headers; Setext and ATX

# Setext header

ATX header
==========

Some headers start with hashes # and other headers is followed by a line of characters such as - or = underneath, Pandoc recognizes these headers.

Restructuredtext uses ATX headers.

[tbabej]

Well, I'd argue that defining pre and post syntax by the user relaxes the space state too much - there's going to be too much burden placed on the user.

Instead we should ship several 'supported' syntaxes. These would load different regexes, but can also implement different parsing logic (every from_line which handles object parsing could be reimplemented in each syntax if necessary). This would be able to handle the more complicated cases as with RST or markdown ATX headers, while abstracting syntax away in a separate layer.

Then the current syntax could be determined and applied dynamically, or using supplied (vimwiki/taskwiki) configuration options.

[DancingQuanta]

I would go for a number of ftplugins, one for each syntax. Each ftplugin must share some common code that do not depend on the syntax of the text file and when a file is opened, the ftplugin tells the python code what syntax to use. Are you happy with this approach?

[tbabej]

Sure, if you're willing to do this, I'm not going to tie your hands too much. We can always refactor later. The suggested approach sounds sensible though.

[indeedwatson]

Is lack of markdown support the reason why tasks such as - [ ] task don't get added to taskwarrior? (I have to use * [ ] instead, but I prefer the former).

[DancingQuanta]

Markdown do support both - and * so this is less to do with lack of markdown support.

What is not supported here is variety of list points such as -. taskwiki is designed with *. I suspect that a easiest resolution to this task list would be to let the user define the list point. However, this only let the taskwiki work on one type of list point.

Can adding more syntax flexibility to taskwiki slow things down?

[tbabej]

@DancingQuanta Great work on this feature so far. I'll make sure to review in coming days.

As far as the syntax flexibility goes, it would definitely slow things down, although probably not notably.

Either way, I'd like to avoid it - the reasoning is simply due to the fact that I would like to either include direct listing of annotations at some point, and using a different list marker may be a nice way of supporting that.

* [ ] Buy a new digital piano
  - Check this useful site https://bestdigitalpianos.shop/deal/

[DancingQuanta]

Good argument on the annotation list marker. That will give some meaning to the list item.

On subject of extra-syntaxes, I suggest rebasing your branch on master for now so I can work on new tests that were added to master.