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 <michaelhathe...@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
>>>>
>>>
