tnichols217 / obsidian-columns

GNU General Public License v3.0
207 stars 9 forks source link

[FR] automatic multi-column for lists #47

Open nousernameavailableanymore opened 1 year ago

nousernameavailableanymore commented 1 year ago

Feature Request

Allow ordered / unordered lists to be automatically split into 2/3/4 columns using only one codeblock.

Details / Ideas / Implementation

In Rainbells multi-column implementation, there were different codeblocks for different amounts of columns. So for example "ad-col-2" for two columns. This would automatically distribute all list items within that codeblock evenly in two columns, without having to manually specify where the break was (which is very unpractical for growing lists).

So suggestion would be to use col-2 to create automatic 2 column lists and so on.

tnichols217 commented 1 year ago

so like, a codeblock where you put a list in it and it automatically splits the list? or it takes the lists out of whatever text you have inside the codeblock and splits those?

nousernameavailableanymore commented 1 year ago

Yes, a codeblock. Call the codeblock (as an example) col2, put in a list and it will split the items evenly into two columns. Have another codeblock, called col3, that splits the list evenly into three columns. I think two and three columns are the most common use-cases.

The advantage is that you could nest a dataview query and it would automatically split the dv list output evenly into two / three columns. Also, even with manual lists, it would make the source much cleaner and easier to read as there is only a codeblock line at the beginning and one at the end. No ugly additional nested codeblocks that make the source harder to read.

tnichols217 commented 1 year ago

Sounds great! However i don't think col2 is a nice name, additionally I'm thinking of instead making one lost-column codeblock and just having a settings block at the top to choose the columns. Any name suggestions?

nousernameavailableanymore commented 1 year ago

Well, the main reason for the FR was to cut down on complexity as much as possible and optimize readability in plain text.

Setting the columns via a settings block instead of using two separate codeblocks would increase the amount of metadata lines (everything that is not the actual list) by 100% (from two (codeblock start, codeblock end) to four (codeblock start, codeblock end, three =, line with the setting)).

Thats why I personally would prefer two separate codeblocks (one for two automatic columns, one for three automatic columns) with intuitive names. col2 and col3 sounds good to me, but everything reasonable short and intuitive is fine.