Content slicing, table support, and miscellaneous fixes

[Witiko]

The witiko/markdown package has recently seen the introduction of several new options and syntax extensions sponsored by David Vins and Omedym, which may be worth porting back to jgm/lunamark:

• Content slicing refers to typesetting only certain parts of a markdown document and combining several markdown documents into a single output. Currently, content slicing is supported through the following options:
  • slice (see 163bbcc), and
  • shiftHeadings (see f9d5d24).
• Tables are supported through the following options:
  • pipeTables (see e93978f, 62365d3), and
  • tableCaptions options (see ac61383, 8d0fe1f, e1bea84).

There have also been several bugfixes in witiko/markdown, which apply to jgm/lunamark:

• the removal an unreachable branch of the parsers.line parser (see 5653f51), and
• the completion of support for named HTML5 entities (see 4d24fc3).

Let me know which patches you would like to backport, and if you would like me to do the backporting. Any other comments are also appreciated.

[jgm]

I think it would be worth porting the bugfixes, but probably not the new extensions.

[Witiko]

I can certainly backport the (minor) bug fixes. Arguably, table support would also be useful to the users.

[jgm]

Sure. No objection to receiving PRs for tables too! I don't know how many people use this library. Vít Novotný <[email protected]> writes:

…

I can certainly backport the (minor) bug fixes. Arguably, table support would also be useful to the users. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #31 (comment)

[Witiko]

Well, the library still has twice as many stargazers as the fork.

[Omikhleia]

@Witiko I have backported the pipe table support from witiko/markdown to my local copy of this library, in order to try it. It seems fairly interesting!

However, this very "lunamark" library is MIT-license, whereas the Wikito "fork" has switched to LPPL...

I might be wrong, but in my understanding, these licenses are not compatible in that way: one cannot use LPPL-licenced code in MIT-licensed code... So in order to propose a backport, the original code either has to be dual-licensed, or right-owners have to allow it explicitly by some clause.

Back in 2019, you seemt favorable for a backport, can you possibly help sorting out the licensing terms?

[Witiko]

the original code either has to be dual-licensed, or right-owners have to allow it explicitly by some clause

@Omikhleia It is my understanding that there are several legal theories of who the owners are in copylefted software projects. I have developed the pipe tables extension, but there are many contributors who may possibly all need to agree to dual-licensing or relicensing the code depending on jurisdiction.

Back in 2019, you seemt favorable for a backport, can you possibly help sorting out the licensing terms?

Back in 2019, the library was still MIT-licensed. It is my understanding that you can borrow any code up until 609aeee under the terms of the MIT license.

Personally, I would be willing to dual-license witiko/markdown, so that it can be treated as MIT-licensed for the purpose of porting code back to jgm/lunamark. As said, this would probably need to go through all contributors and would involve the help of a lawyer in drafting the text of the conditions.

[Omikhleia]

Back in 2019, the library was still MIT-licensed.

That's so cool. I just checked the main page without looking when the license change occurred. I'll move forward then, i.e. test my backport (also to see how it integrates with my table module for SILE) and propose it here when done. I'll add all the legalese comments and also the credits :)

There are several legal theories of who the owners are in copylefted software projects. (...)

Yes, it was also my fear that contributors would possibly have to be involved, etc., and at least all the appropriate developers, if that piece of code was under LPPL. Licenses have plenty of subtleties, hence my asking before involving more efforts ^^

[Witiko]

Licenses have plenty of subtleties, hence my asking before involving more efforts ^^

@Omikhleia I am not sure licenses themselves touch on this. It is my understanding that this depends mainly on the jurisdiction and if it views software development as joint authorship (all contributors own the entire source code), collective work (all contributors own their own bits), or something else entirely.

[Omikhleia]

Well I sort of disagree, perhaps - A license says it all, IMHO (but I am not a lawyer). I have code under MIT, GPL, LGPL, various CC-things etc. for some good reasons (or so do I hope). I don't like the LPPL much (I am not going to comment further here), but any license-shift is not without consequences, for sure.

Anyway... Let's move on ;) -- You really made my day happy, and I feel very grateful...

In the best world, yes, oh gals and boys ! LaTeX (which I used a lot in my youth) or SILE, with a mix of Lua -- good "old-way" typesetters (read: not WYSIWYG) -- still have their word to say, hand-in-hand, in this world. You did a real good job with these tables, congrats!

[Witiko]

Glad to have helped. 😉

[Witiko]

Well I sort of disagree, perhaps - A license says it all, IMHO (but I am not a lawyer).

Neither am I, but I have seen several projects require contributors to sign contributor license agreements as a prerequisite for merging a pull request. These are generally separate from software licenses and are meant to clarify what claim the contributors have to authorship. See also https://google.github.io/opencasebook/authorship.