Markdown syntax

[lil5]

Instead

---[ Shopping ]
+++# Shopping
---bread # 1
+++- [ ] bread `1`
---// bananas # 6
+++- [x] bananas `6`

compatibility to .lst

• [ ] add a converter

So markdown rendered

---

Shopping

• [ ] bread 1
• [x] bananas 6

[woefe]

I like the idea. I think it could be quite nice if the syntax was valid Markdown. However, I see some problems with this change.

• The current syntax is simpler and more concise
• Markdown is more difficult to parse (but should be doable)
• A markdown parser will be more restrictive, i.e. more files will be rejected because of syntax errors (e.g. because of a missing second *)
• It is not backwards compatible

The new syntax could be like this:

# thelist
- an item
- ~~a checked item~~
- an item *with quantity*
- ~~a checked item *with quantity*~~

and rendered:

thelist

• an item
• ~~a checked item~~
• an item with quantity
• ~~a checked item with quantity~~

I'd like to get more feedback before I implement this (breaking) change.

[knezi]

This sounds great. One of the things I use this for, is list of all companies selling tickest (bus, train, planes). If this was a markdown file, I could simply use a markdown viewer on my computer to make these clickable. Also, syntax would work in VIM...

I like the syntax @woefe has proposed, however the amount is not really that distinguishable. What about using pipe (|) or something similar?

[lil5]

@knezi | pipes are used for tables, not lists :-1:

[knezi]

@lil5 not true, if you write blah | blah it gets rendered as a pipe, because it's not a valid table. And we still should be able to escape this pipe (like \|? I don't know if this is valid though). Anyway, that's not important. I wrote or something similar, because I don't feel like italic is distinguishable enough, so I proposed to use some character which would make it more obvious.

[lil5]

@knezi then it would use non standard syntax.

And italics to me does not seem an issue:

---

Groceries

• Bread half
• Bananas 7
• ~~Pizza 2~~

---

[woefe]

I don't like the idea of using some special character to separate the amount. I want to keep it to standard markdown formatting directives. The options then are bold, italic or code. I prefer not to use bold, because ** is more difficult to parse. It has some unwanted properties, when specifying a CFG. I want to leave the option open to use parser generator (like antlr) to parse the shopping list files.

So it's either italic or code, if I'm not missing any other formatting directive.

[lil5]

@woefe underscore _ works just as well if you're worried about the asterisk *.

---

This is *an* **Asterisk**

This is an Asterisk

---

And this is _an_ __Underscore__

And this is an Underscore

---

[woefe]

Yes, I know. The problem is the double asterisk or double underscore, which would match as two single asterisks in a context-free grammar.

[knezi]

@woefe then I'd use code, it's still more distinguishable, then italics.

[DJCrashdummy]

yes... it's still not perfect, but i guess the best choice - if we completely stick to the standard syntax (which is IMHO a good idea) - is to use code for the quantity. so this is also a bit of an eye-catcher to quickly see which items already have a quantity and which does not.

[DJCrashdummy]

perhaps helpful: Nextcloud/Owncloud Notes uses RxMarkdown (License: Apache 2.0) for rendering. maybe it or parts from its code can be used for this project.

[DJCrashdummy]

perhaps thinking about using the todo-syntax can make sense... (i've also picked up the category-idea from #45 to make a first step):

# the list name
- [ ] an item
- [x] a checked item
- [ ] an item `with quantity`
- [x] a checked item `with quantity`
- [ ] an item `with quantity` _and category_
- [x] a checked item `with quantity` _and category_

the list name

• [ ] an item
• [x] a checked item
• [ ] an item with quantity
• [x] a checked item with quantity
• [ ] an item with quantity and category
• [x] a checked item with quantity and category

---

in opposite to the classic strike through:

# the list name
- an item
- ~~a checked item~~
- an item `with quantity`
- ~~a checked item `with quantity`~~
- an item `with quantity` _and category_
- ~~a checked item `with quantity` _and category_~~

the list name

• an item
• ~~a checked item~~
• an item with quantity
• ~~a checked item with quantity~~
• an item with quantity and category
• ~~a checked item with quantity and category~~

---

i kind of like the little checkbox... IMHO it is easier distinguishable (and easier to edit) if you have to work with the plain text-file, but a little less distinguishable in the rendered view. :slightly_frowning_face: using both of them together may be a bit of a overkill and probably cause more problems than necessary if edited manually (with opposing syntax). not to mention the additional work if edited manually...

# the list name
- [ ] an item
- [x] ~~a checked item~~
- [ ] an item `with quantity`
- [x] ~~a checked item `with quantity`~~
- [ ] an item `with quantity` _and category_
- [x] ~~a checked item `with quantity` _and category_~~

the list name

• [ ] an item
• [x] ~~a checked item~~
• [ ] an item with quantity
• [x] ~~a checked item with quantity~~
• [ ] an item with quantity and category
• [x] ~~a checked item with quantity and category~~

---

eventually accepting both (resp. all 3 variants) may also be an interesting idea: so that either a checked todo or a stroked through bullet point (or both together) is shown as "done" in ShoppingList. so it is more relaxed and easier to import existing lists and we only have to decide what should be the native syntax used by ShoppingList. ...or even not and simply add a setting for "experts" to not mess up their "imported" lists. hopefully this is not that much more work than implementing one syntax... what do you think?

[DJCrashdummy]

It is not backwards compatible

@woefe it must not completely break the backwards compatibility: just keep the "legacy rendering code" and add a check at the start of the app if there are .lst-files and convert them (perhaps ask/warn before doing so) into .md-files with the markdown-syntax. probably editing an existing list will/should also cause a conversion...

[ghost]

In my opinion this would greatly improve the usability of this app. With Markdown and webdav support you could use any markdown editor on the desktop with the same look and feel like in the app.

Additional some points which are important in my opinion:

• with markdown also link-support would be possible so I could also deal with stuff I want to by online
• Anyway how the quantity is handled I would expect the quantity before the item
• I would go for the checkbox because this would open the possibility to hide checked items and in my opinion is the more logical connection than striked items