Re: [fossil-users] Supporting markwon syntax for wiki
Hi, regarding the buffer code: On 27.04.2012 23:07, Natacha Porté wrote: on Friday 27 April 2012 at 22:14, chris wrote: 1. both have their own buffer concept and do not allow to hand in a string that makes it necessary to copy from Fossils Blob blob_str output into the input buffer => needs twice the input docs size :-( That's where I spent most of the time in my attempt to integrate libupskirt into fossil. The idea was to remove libupskirt's dynamic buffers completely and replace them with fossil blobs (which are dynamic buffers too). would'nt it be easier to implement sth like a "fixed buffer" within libupskirt that takes a char* and a length and only keeps a reference without copying the content? Each attempt to change the size of such a buffer would result in an error. If libupskirt does not mess with the input buffer size then this would be a cheap (wrt effort) solution. Chris ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Supporting markwon syntax for wiki
@Natacha,
no offence intended and none taken :-). Email is such a bad medium when
it comes
to discussions with people you don't know. The personal/emotional/visual
part
is completely missing.
BTW: yes, it was a compliment :-)
@all
Back to the topic from below regarding integration: I wanted to be able
to identify
the *content* of a txt file independently of its extension. With that I
can write md
in .txt files. Normal fossil will render it as pre-formatted text.
MD-enhanced fossil
renders it as html.
Therefore pure mime-type based integration would not work.
Find attached a proposal to extend sundown with at least the detection of
Pandoc style header lines similar to discount. I'd intend to integrate
callbacks
for the header into the callback structure if this is something of
interest here.
And one more on the licensing issue: is sundown under the same license as
libupskirt or do the differ? From the license info in the source it
should both
be OK. Am I wrong here?
Chris
On 27.04.2012 23:07, Natacha Porté wrote:
Hello,
just to be clear, I had no intention either to start a flamewar or
anything, and no intention to specifically advertise "my" solution (or
rather, my library).
The only point of my previous message was to make clear what I could
offer, which has changed since last time I posted here. And bottom line
is I DON'T have an integration to offer anymore, though copyright
assignmnet and support offers still stand.
I answer to specific points below.
on Friday 27 April 2012 at 21:06, chris wrote:
- server side I tried libupskirt today but it was difficult to get it
to compile under
win. finally I created a makefile for nmake but then header parsing
or better
the rendering part caused issues ("" header tags instead
of "").
The vprintbuf function has/had a problem. The I borrowed the code
from sundown
only for this function and it worked fine.
This is a known issue, primarily due to the lack of C99 support in
windows. I don't have access to any windows machine, so I can't make any
meaningful development or testing. However I seem to remember some
people on this ML have already solved it or worked around it. Anyway,
the whole dynamic buffer code should go IMHO.
I did not look at the legal stuff (yet) and it's definitely a point to
consider. If I'd still
be a candidate for the tooth fairy my wish would be to bring libupskirt
& sundown back
together and use both under linux& win together with fossil
I haven't dove into the details of both implementations, so there might
be details that
prevent this.
There isn't. The crux of the matter is the dynamic buffer code (and to a
lesser extend the dynamic array code). See below.
Besides: I like the libupskirt approach on how to integrate the
renderer. I want
to createy S5 HTML slide output from some markdown files and that approach
woulk make it quite easy to implement it.
Thanks a lot :-) (I took it as a compliment on my design)
on Friday 27 April 2012 at 22:14, chris wrote:
Hi all,
I've integrated sundown and found two problems that it shares with
libupskirt:
1. both have their own buffer concept and do not allow to hand in a
string that
makes it necessary to copy from Fossils Blob blob_str output into
the input
buffer => needs twice the input docs size :-(
That's where I spent most of the time in my attempt to integrate
libupskirt into fossil. The idea was to remove libupskirt's dynamic
buffers completely and replace them with fossil blobs (which are
dynamic buffers too).
I didn't finish it, however from the part I did I'd say it's tedious but
not difficult.
2. discount (somewhat) supports the markdown header extension of pandoc:
three
% lines at the beginning of the file denote title, author and date.
I used this
to differentiate between real markdown (if title parsing was
successful) and
normal text for .txt files. That's not possible anymore.
My solution for that point was to use a dedicated extension for markdown
files (actually two, .mkd and .markdown), and then simply add them in
doc.c with text/x-markdown MIME type, along with a special handler for
text/x-markdown in doc_page() function from doc.c, besides the handling
of application/x-fossil-wiki and text/plain.
It seemed to be the least intrusive way of introducing markdown support
(but only as an embedded doc rendered into HMTL on-the-fly). That's the
only modification of fossil's current code that is needed, everything
else is integrating the markdown library into the binary.
Hoping this helps,
Natasha
diff --git a/src/markdown.c b/src/markdown.c
index 260483d..46c0dac 100644
--- a/src/markdown.c
+++ b/src/markdown.c
@@ -2447,6 +2447,38 @@ sd_markdown_new(
return md;
}
+static size_t
+sd_markdown_hdridx(size_t start, const uint8_t *document, size_t doc_size)
+{
+int hdrlines = 0;
+size_t i = start;
+while (i < doc_size) /* iterating over lines */
+{
+/* stop at first line n
Re: [fossil-users] Supporting markwon syntax for wiki
Hello,
just to be clear, I had no intention either to start a flamewar or
anything, and no intention to specifically advertise "my" solution (or
rather, my library).
The only point of my previous message was to make clear what I could
offer, which has changed since last time I posted here. And bottom line
is I DON'T have an integration to offer anymore, though copyright
assignmnet and support offers still stand.
I answer to specific points below.
on Friday 27 April 2012 at 21:06, chris wrote:
> - server side I tried libupskirt today but it was difficult to get it
> to compile under
> win. finally I created a makefile for nmake but then header parsing
> or better
> the rendering part caused issues ("" header tags instead
> of "").
> The vprintbuf function has/had a problem. The I borrowed the code
> from sundown
> only for this function and it worked fine.
This is a known issue, primarily due to the lack of C99 support in
windows. I don't have access to any windows machine, so I can't make any
meaningful development or testing. However I seem to remember some
people on this ML have already solved it or worked around it. Anyway,
the whole dynamic buffer code should go IMHO.
> I did not look at the legal stuff (yet) and it's definitely a point to
> consider. If I'd still
> be a candidate for the tooth fairy my wish would be to bring libupskirt
> & sundown back
> together and use both under linux & win together with fossil
>
> I haven't dove into the details of both implementations, so there might
> be details that
> prevent this.
There isn't. The crux of the matter is the dynamic buffer code (and to a
lesser extend the dynamic array code). See below.
> Besides: I like the libupskirt approach on how to integrate the
> renderer. I want
> to createy S5 HTML slide output from some markdown files and that approach
> woulk make it quite easy to implement it.
Thanks a lot :-) (I took it as a compliment on my design)
on Friday 27 April 2012 at 22:14, chris wrote:
> Hi all,
>
> I've integrated sundown and found two problems that it shares with
> libupskirt:
> 1. both have their own buffer concept and do not allow to hand in a
> string that
> makes it necessary to copy from Fossils Blob blob_str output into
> the input
> buffer => needs twice the input docs size :-(
That's where I spent most of the time in my attempt to integrate
libupskirt into fossil. The idea was to remove libupskirt's dynamic
buffers completely and replace them with fossil blobs (which are
dynamic buffers too).
I didn't finish it, however from the part I did I'd say it's tedious but
not difficult.
> 2. discount (somewhat) supports the markdown header extension of pandoc:
> three
> % lines at the beginning of the file denote title, author and date.
> I used this
> to differentiate between real markdown (if title parsing was
> successful) and
> normal text for .txt files. That's not possible anymore.
My solution for that point was to use a dedicated extension for markdown
files (actually two, .mkd and .markdown), and then simply add them in
doc.c with text/x-markdown MIME type, along with a special handler for
text/x-markdown in doc_page() function from doc.c, besides the handling
of application/x-fossil-wiki and text/plain.
It seemed to be the least intrusive way of introducing markdown support
(but only as an embedded doc rendered into HMTL on-the-fly). That's the
only modification of fossil's current code that is needed, everything
else is integrating the markdown library into the binary.
Hoping this helps,
Natasha
pgpXUVZ5OzTmg.pgp
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Supporting markwon syntax for wiki
Hi all, I've integrated sundown and found two problems that it shares with libupskirt: 1. both have their own buffer concept and do not allow to hand in a string that makes it necessary to copy from Fossils Blob blob_str output into the input buffer => needs twice the input docs size :-( 2. discount (somewhat) supports the markdown header extension of pandoc: three % lines at the beginning of the file denote title, author and date. I used this to differentiate between real markdown (if title parsing was successful) and normal text for .txt files. That's not possible anymore. Any thoughts on both topics? checkin link: http://server.ac-drexler.de/fossil/fossil/info/b4715c17bca42209 Chris ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Supporting markwon syntax for wiki
Hi all,
I have a personal "need" (better interest)
in having markdown integrated and looked into what other people did
before. I have found
many discussions but no realization (i missed out on the cline-side
rendering solution
with pagedown at that time). So I was looking into whether markdown
should be integrated
at all and if so,how can it be done minimally invasive.
Let me give you some detail on my experiences/opinions:
On 27.04.2012 12:38, Baptiste Daroussin wrote:
Le 27 avril 2012 12:14, Natacha Porté a écrit :
Hello,
Since we are talking about alternatives for markdown-in-fossil, you
might remember my repeated mentions about integrating my [markdown
library][libupskirt] into fossil.
I've chosen discount because it was readily available for linux & win
and with
that I could explore integration possibilities. Since then I looked at
client side
rendering and also at libupskirt and sundown as well.
To be perfectly honest, I lost interest in the idea, and went for the
generated embedded docs idea (same as what was previously said with
AsciiDoc). Even though I still don't like putting generated stuff into
the SCM, I find it to be a lesser evil compared to the risk of
spectacular failure when embedding such complex code into fossil,
especially with regard to security (since it's the same binary, a
vulnerability in the markdown code can mean read/write access to at
least the whole sqlite database)
I also don't like checking in generated code/doc at all. Right now I'm
also exploring
something like a python service that pulls the markdown/reStructureText
documents
from fossil and renders them. But I don't really like that I've to have
two services installed,
configures & up-and-running for this.
So I looked into integrating markdown more tightly.
So my question is now, is there anybody willing to take it over, or do I
just send it to the heaven for bits?
For the record, I think the main pros my library still has over discount
is legal stuff (I can hand over copyright of fossil's fork any time) and
direct support from me. However these are probably not worth much if
merge into official release is still not going to happen.
Here my, as always subjective, summary:
- discount is heavy with everything around it but was easily
compilable/avail for
linux & win. Under win I only compiled lib markdown and the
integration was
done quite quickly (from a technical perspective).
- client side rendering lacks IMHO seemless link integration with
fossil artifact
links. some glue code helped to this with discount and can be done
easily with
any other server side library. I'm not sure how this can be achieved
with client
side rendering (any ideas here?)
- server side I tried libupskirt today but it was difficult to get it
to compile under
win. finally I created a makefile for nmake but then header parsing
or better
the rendering part caused issues ("" header tags instead
of "").
The vprintbuf function has/had a problem. The I borrowed the code
from sundown
only for this function and it worked fine.
I don't want to cause a flame war and I appreciate all the work people
did to support
markdown as a wider used markup language. But right now I'm looking into
integrating
sundown as the smaller / faster (?) library compared to discount and the
one easier
avail under win AND linux compared to libupskirt.
I did not look at the legal stuff (yet) and it's definitely a point to
consider. If I'd still
be a candidate for the tooth fairy my wish would be to bring libupskirt
& sundown back
together and use both under linux & win together with fossil
I haven't dove into the details of both implementations, so there might
be details that
prevent this.
Well performance is also very good point for your library, it out
performs discount by far and consumes far less memory.
Performance with larger markdown file was not evaluated as I don't expect
to have huge document to be displayed. Still that might be an adv of
libupskirt/sundown.
Besides: I like the libupskirt approach on how to integrate the
renderer. I want
to createy S5 HTML slide output from some markdown files and that approach
woulk make it quite easy to implement it.
Here I want to thank everyone who made it possible for me to explore all
these
things in such a short time (Richard, Natascha, Tin-Pot, ). And if
we don't get
consensus, then maybe I'll create a branch in the fossil repository and
people
can pull it if they are interested in my markdown integration.
Chris
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Supporting markwon syntax for wiki
Le 27 avril 2012 12:14, Natacha Porté a écrit : > Hello, > > on Thursday 26 April 2012 at 00:53, Ivan Vilata i Balaguer wrote: >> chris (2012-04-22 17:09:45 +0200) wrote: >> >> > Please check out >> > >> > https://server.ac-drexler.de/fossil/fossil/doc/tip/addons/markdown.md >> > >> > for an integration proposal of the discount library with the build >> > system of fossil. >> > >> > --- >> > ## Markdown support for fossil >> > >> > after looking for additional markup support for fossil I found [this >> > thread][1]. With the references and some afternoon work I managed to >> > integrate Markdown as an additional mime-type .md that the doc >> > interface handles in a similar way to .wiki& .txt. >> >> Looks nice! You may also be interested in my enhanced version of Bill >> Burdick's Fossil pagedown software which does client-side rendering of >> wiki pages and embedded `.wiki` and `.txt` docs starting with >> `@pagedown` and (similarly to your solution) all embedded docs ending in >> `.md.txt` (of course with no changes at all to Fossil and keeping repos >> portable). > > Since we are talking about alternatives for markdown-in-fossil, you > might remember my repeated mentions about integrating my [markdown > library][libupskirt] into fossil. > > To be perfectly honest, I lost interest in the idea, and went for the > generated embedded docs idea (same as what was previously said with > AsciiDoc). Even though I still don't like putting generated stuff into > the SCM, I find it to be a lesser evil compared to the risk of > spectacular failure when embedding such complex code into fossil, > especially with regard to security (since it's the same binary, a > vulnerability in the markdown code can mean read/write access to at > least the whole sqlite database). > > So my question is now, is there anybody willing to take it over, or do I > just send it to the heaven for bits? > > For the record, I think the main pros my library still has over discount > is legal stuff (I can hand over copyright of fossil's fork any time) and > direct support from me. However these are probably not worth much if > merge into official release is still not going to happen. > Well performance is also very good point for your library, it out performs discount by far and consumes far less memory. regards, Bapt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Supporting markwon syntax for wiki
On Fri, Apr 27, 2012 at 12:14:47PM +0200, Natacha Porté wrote: > > Looks nice! You may also be interested in my enhanced version of Bill > > Burdick's Fossil pagedown software which does client-side rendering of > > wiki pages and embedded `.wiki` and `.txt` docs starting with > > `@pagedown` and (similarly to your solution) all embedded docs ending in > > `.md.txt` (of course with no changes at all to Fossil and keeping repos > > portable). > > So my question is now, is there anybody willing to take it over, or do I > just send it to the heaven for bits? If you have a fossil branch with those changes, it would be great to have the branch in the main fossil repository. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Supporting markwon syntax for wiki
Hello, on Thursday 26 April 2012 at 00:53, Ivan Vilata i Balaguer wrote: > chris (2012-04-22 17:09:45 +0200) wrote: > > > Please check out > > > > https://server.ac-drexler.de/fossil/fossil/doc/tip/addons/markdown.md > > > > for an integration proposal of the discount library with the build > > system of fossil. > > > > --- > > ## Markdown support for fossil > > > > after looking for additional markup support for fossil I found [this > > thread][1]. With the references and some afternoon work I managed to > > integrate Markdown as an additional mime-type .md that the doc > > interface handles in a similar way to .wiki& .txt. > > Looks nice! You may also be interested in my enhanced version of Bill > Burdick's Fossil pagedown software which does client-side rendering of > wiki pages and embedded `.wiki` and `.txt` docs starting with > `@pagedown` and (similarly to your solution) all embedded docs ending in > `.md.txt` (of course with no changes at all to Fossil and keeping repos > portable). Since we are talking about alternatives for markdown-in-fossil, you might remember my repeated mentions about integrating my [markdown library][libupskirt] into fossil. To be perfectly honest, I lost interest in the idea, and went for the generated embedded docs idea (same as what was previously said with AsciiDoc). Even though I still don't like putting generated stuff into the SCM, I find it to be a lesser evil compared to the risk of spectacular failure when embedding such complex code into fossil, especially with regard to security (since it's the same binary, a vulnerability in the markdown code can mean read/write access to at least the whole sqlite database). So my question is now, is there anybody willing to take it over, or do I just send it to the heaven for bits? For the record, I think the main pros my library still has over discount is legal stuff (I can hand over copyright of fossil's fork any time) and direct support from me. However these are probably not worth much if merge into official release is still not going to happen. Natacha [libupskirt]: http://fossil.instinctive.eu/libupskirt/index pgp4fgiQSUNjf.pgp Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
