Thanks. Is Markdown.html_inline what I should be using to produce html output in a similar manner to terminal_print?
On Monday, 9 June 2014 14:24:12 UTC+2, Mike Innes wrote: > > This is just because Markdown.jl didn't have a release – I don't know if > there's a way to depend on such packages and/or arbitrary git repositories > (if not perhaps we should have a way?). Adding Pkg.clone("Markdown") during > the build step would work I guess. > > Anyway, I just pushed 0.1.0 so it should work if you re-do the build. > > > On 9 June 2014 13:04, Michael Hatherly <michael...@gmail.com <javascript:> > > wrote: > >> I've managed to get it to store the markdown parsed docs now and display >> them correctly. Travis is complaining that it can't find Markdown though. >> Should I be doing something different in my REQUIRE file? >> >> >> On Monday, 9 June 2014 12:23:56 UTC+2, Mike Innes wrote: >> >>> Woops – yeah, terminal_print takes a columns keyword argument. >>> >>> sprint(io -> Markdown.terminal_print(io, md, columns = 80)) >>> >>> >>> On 9 June 2014 11:16, Michael Hatherly <michael...@gmail.com> wrote: >>> >>>> Great, just pushed some other changes so I'll look into this later this >>>> week. >>>> Having a quick look though, sprint(Markdown.terminal_print, ans) strips >>>> out the line wrapping. Is there an easy way to retain that formatting in >>>> the string? >>>> >>>> >>>> On Monday, 9 June 2014 10:49:56 UTC+2, Mike Innes wrote: >>>>> >>>>> I just fixed it up to work with n level headers – it should do >>>>> everything you need it to now. >>>>> >>>>> Just to get you started, this will render the first docstring from >>>>> docile.md: >>>>> >>>>> julia> Markdown.Block(Markdown.parse_file("/users/Mike/Documents/do >>>>> cile.md")[3:7]) >>>>> julia> sprint(Markdown.terminal_print, ans) >>>>> >>>>> On Sunday, 8 June 2014 22:07:40 UTC+1, Michael Hatherly wrote: >>>>>> >>>>>> So it does :) I'll have a closer look soon. >>>>>> >>>>>> On Sunday, 8 June 2014 22:29:13 UTC+2, Tim Holy wrote: >>>>>>> >>>>>>> On Sunday, June 08, 2014 01:16:51 PM Michael Hatherly wrote: >>>>>>> > Since everything in help is in Base as >>>>>>> > well, it doesn't seem to be a problem currently. >>>>>>> >>>>>>> Actually, the help system does take the module into account (I >>>>>>> believe Carlo >>>>>>> Baldassi implemented this): >>>>>>> >>>>>>> help> Base.print >>>>>>> Base.print(x) >>>>>>> >>>>>>> Write (to the default output stream) a canonical (un-decorated) >>>>>>> text representation of a value if there is one, otherwise call >>>>>>> "show". The representation used by "print" includes minimal >>>>>>> formatting and tries to avoid Julia-specific details. >>>>>>> >>>>>>> help> Profile.print >>>>>>> Base.Profile.print([io::IO = STDOUT], [data::Vector]; format = >>>>>>> :tree, C = >>>>>>> false, combine = true, cols = tty_cols()) >>>>>>> >>>>>>> Prints profiling results to "io" (by default, "STDOUT"). If you >>>>>>> do not supply a "data" vector, the internal buffer of accumulated >>>>>>> backtraces will be used. "format" can be ":tree" or ":flat". >>>>>>> If "C==true", backtraces from C and Fortran code are shown. >>>>>>> "combine==true" merges instruction pointers that correspond to >>>>>>> the same line of code. "cols" controls the width of the display. >>>>>>> >>>>>>> Base.Profile.print([io::IO = STDOUT], data::Vector, lidict::Dict; >>>>>>> format = >>>>>>> :tree, combine = true, cols = tty_cols()) >>>>>>> >>>>>>> Prints profiling results to "io". This variant is used to examine >>>>>>> results exported by a previous call to "Profile.retrieve()". >>>>>>> Supply the vector "data" of backtraces and a dictionary >>>>>>> "lidict" of line information. >>>>>>> >>>>>>> >>>>>>> > I'll take another look >>>>>>> > when I get a chance. >>>>>>> > >>>>>>> > [1] https://github.com/JuliaLang/julia/blob/master/base/help.jl# >>>>>>> L102 >>>>>>> > >>>>>>> > On Sunday, 8 June 2014 21:32:36 UTC+2, Tim Holy wrote: >>>>>>> > > I agree with Daniel. We just need _something_, and on this issue >>>>>>> the >>>>>>> > > diversity >>>>>>> > > of tastes seems to make consensus impossible. So kudos to you. I >>>>>>> really >>>>>>> > > hope >>>>>>> > > this keeps moving forward. >>>>>>> > > >>>>>>> > > What prevents it from working with functions rather than >>>>>>> strings? >>>>>>> > > >>>>>>> > > --Tim >>>>>>> > > >>>>>>> > > On Saturday, June 07, 2014 02:16:11 PM Daniel Jones wrote: >>>>>>> > > > A good way of documenting packages is one of the biggest gaps >>>>>>> in the >>>>>>> > > > julia ecosystem right now. Part of the reason why is evinced >>>>>>> in the >>>>>>> > > > issues you cite: no matter what the system is, someone is >>>>>>> going to hate >>>>>>> > > > it. At this point, I'm sort of hoping someone will just ignore >>>>>>> all >>>>>>> > > > feedback and build whatever they want. >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > That said, I think this is a pretty elegant solution. Just >>>>>>> relying on >>>>>>> > > > markdown h1 and h2 headers leaves open the possibility of >>>>>>> generating >>>>>>> > > > html documentation from the same source. That's something I >>>>>>> appreciate, >>>>>>> > > > since I'd also want to generate html docs with example plots >>>>>>> rendered >>>>>>> > > > for gadfly. >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > With Jake Bolewski's julia parser, I hope it will become >>>>>>> easier to >>>>>>> > > > extract documentation from source code, either from comments >>>>>>> or >>>>>>> > > > something like docstrings. Have you given any though to that? >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > On Thu, Jun 5, 2014, at 03:13 PM, Michael Hatherly wrote: >>>>>>> > > > >>>>>>> > > > Hi all, >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > I've just put up a rough prototype for package documentation >>>>>>> at >>>>>>> > > > [1]https://github.com/MichaelHatherly/Docile.jl. This is not >>>>>>> meant to >>>>>>> > > > be a solution to the documentation problem, but rather to >>>>>>> start some >>>>>>> > > > fresh discussion on the matter. >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > Any feedback would be great. There's more details in the >>>>>>> readme. >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > Regards, >>>>>>> > > > >>>>>>> > > > Mike >>>>>>> > > > >>>>>>> > > > References >>>>>>> > > > >>>>>>> > > > 1. https://github.com/MichaelHatherly/Docile.jl >>>>>>> >>>>>> >>> >