A possible PND-system replacement

[levi]

Yeah, that's true.  It should be a trivial sed command to knock out any user defined roles, but that's a bit hacky.  I was looking for a way to do it within the format language itself, but I guess anything within the format can probably be disabled by other things in the same file.

 

[Neelix]

Wouldn't that only be a problem if that aspect of the format is implemented?  If you control the implementation you can ensure that attempts to embed HTML are ignored, no?

-Neelix

 

[slaeshjag]

After looking into ReStructuredText, I can't say I'm in favour of it though. At all.

 

[thatgui]

Well as B-ZaR already suggested,  Markdown could work well.  It also occurs to me that we could use a subset of BBCode, which was designed for the exact purpose of providing a set of formatting codes that could be used to format user provided content without having to permit the use of raw html in the content itself. There's no need to re-invent the wheel here.

Oh, did miss that - sorry.

I  am not comfortable with using "BBCode" or the mentioned "RestructuredText" as this sets the entry level higher for package maintainers as they occur to me as rather "exotic" languages. Markdown may have its merits, but which one would or should it be ? Depending on the intended requirements (= what should be possible in terms of text magic) we may need to use a variation that also allows to embed html. And then we are back at square one: if we need to filter anyway, why not html directly > its widely know, and a gazillion tutorials,editors, libraries, controls, etc are already available ?

 

[slaeshjag]

You don't really understand the issue. Embedded HTML isn't really a problem as long as no HTML at all is the target.

There shouldn't be any need for any special markdown extensions, just plain standard markdown should do. This means existing markdown editors can be used.

 

[thatgui]

You don't really understand the issue. Embedded HTML isn't really a problem as long as no HTML at all is the target.

There shouldn't be any need for any special markdown extensions, just plain standard markdown should do. This means existing markdown editors can be used.

Oh, ok - would you be willing to tell me were exactly I don't get it ? I thought this was about finding a "language" that allows to embed some text formatting into the field so whichever software is reading this particular field can present this to a user in a more "non plain text" fashion. With html you can do that, but with the problem (you initially mentioned ) that it needs some sanitation to keep a certain level of security. But at least one major target client/plattform will be the repo, which means in the end we are bound to html anyway - so if we choose something that has no html syntax (like Markdown) we need to convert it to html - which is again, legwork.

Or am I completly on the wrong track here ?

Disclaimer: Just to be sure, this is not meant to be sarcastic at all, I see myself too in a position where I am trying to keep up with people that know a lot more then me

 

[bzar]

Well as B-ZaR already suggested,  Markdown could work well.  It also occurs to me that we could use a subset of BBCode, which was designed for the exact purpose of providing a set of formatting codes that could be used to format user provided content without having to permit the use of raw html in the content itself. There's no need to re-invent the wheel here.

Oh, did miss that - sorry.

I  am not comfortable with using "BBCode" or the mentioned "RestructuredText" as this sets the entry level higher for package maintainers as they occur to me as rather "exotic" languages. Markdown may have its merits, but which one would or should it be ? Depending on the intended requirements (= what should be possible in terms of text magic) we may need to use a variation that also allows to embed html. And then we are back at square one: if we need to filter anyway, why not html directly > its widely know, and a gazillion tutorials,editors, libraries, controls, etc are already available ?

Markdown has the benefit that it's actually quite readable and clean even in its plaintext format.

 

[notaz]

Yeah markdown would be nice. If you don't like it you can ignore it and just type plain text to get the result we have in PNDs now.

 

[Christoph.Krn]

Are there any arguments against using MultiMarkdown? Some of its additional elements would be useful to have for documentation.

 

[slaeshjag]

Well, there need to be usable libraries for C and PHP, preferably in repo, for it to even be considrered..

 

[bzar]

Well, there need to be usable libraries for C and PHP, preferably in repo, for it to even be considrered..

php-markdown (PHP), sundown (C)

 

[thatgui]

Markdown has the benefit that it's actually quite readable and clean even in its plaintext format.

With that in mind, and that it has a rather simple syntax (which is, thanks to git, probably widely known) it looks like a viable option - do you know wether there are libs widely available / already "common" to convert it to html ?

 

[ible]

sundown is apparently being superceded by hoedown:

https://github.com/hoedown/hoedown

 

[bzar]

Markdown has the benefit that it's actually quite readable and clean even in its plaintext format.

With that in mind, and that it has a rather simple syntax (which is, thanks to git, probably widely known) it looks like a viable option - do you know wether there are libs widely available / already "common" to convert it to html ?

http://www.w3.org/community/markdown/wiki/MarkdownImplementations

https://github.com/markdown/markdown.github.com/wiki/Implementations

 

[bzar]

The biggest downside to markdown I know is no nice table support.

 

[thatgui]

http://www.w3.org/community/markdown/wiki/MarkdownImplementations

https://github.com/markdown/markdown.github.com/wiki/Implementations

thanks

The biggest downside to markdown I know is no nice table support.

probably why Christoph.Krn suggested Multimarkdown (?), according to the lists you provided, using it instead of markdown should not be too much of a hassle. Even if support was even less then the links suggest, even I could come up with a simple non fancy (=no css) converter in less than an hour.

edit: After taking a closer look, better make that two hours: figuring out a clever way to differentate a table definition from "akward text" probably needs some effort
 

 

[slaeshjag]

Well, there need to be usable libraries for C and PHP, preferably in repo, for it to even be considrered..

php-markdown (PHP), sundown (C)

Sundown isnt in repo. There is however another library for plain unextended markdown (libmarkdown2 in repo).

 

[Christoph.Krn]

The sample implementation of MultiMarkdown 4 itself is written in C.

There's no PHP version, but is it (edit: a library that's actually written in PHP) really neccessary (edit: or are there viable alternative means of achieving the same thing within the already existing PHP code)? I assume it's meant for a repository-type website, would containing the executable with SELinux, using PHP's exec securely, and storing results in the database, be a viable alternative? If not, maybe there's a fitting transpiler.

*Insert mandatory rant that PHP sucks anyway and should not be used.*

 

[slaeshjag]

Then write your own damn repo. Don't complain about the tools of others if you're not doing the work yourself. I'm not writing the repo, so milkshake will have to comment on what he's prepared to use, but it'll probably involve PHP.

I require all dependencies that I'm to use to be present in the official repository of Debian Jessie, if they aren't, I'm not going to consider it.

 

[Christoph.Krn]

Now that I look at my previous post again, I notice that there was a language slip. The "it" in "There's no PHP version, but is it really neccessary?" wasn't meant to refer to PHP. Rather, I was trying to ask "For use with PHP, would a version of a MultiMarkdown library that's actually written in PHP be really neccessary, or could another version (written in a different language) be used in the PHP code?" My apologies. That sentence of mine would have been unambiguously clear in German.

My question is genuine, I didn't know that it was milkshake who was working on a new repository, or whether there even was anyone working on a new repository right now.

As for it being required for things to be in the debian repository, point noted, though I have to note that you previously stated that it'd merely be preferred.