On Fri, Jan 4, 2013 at 4:12 PM, engelbert gruber <engelbert.gruber@gmail.com> wrote:
hei,

* what should the output be ansi-escapes or ... ?

ANSI escapes are fine. 

But at the place of use, this is all abstracted. For example for debugger messages I have routines for "error message" and"section".

Also at present, for call stack listings and disassembly listings I am using pygment's terminal formatter which understands "dark" and "light" backgrounds. One day I may generalize to allow selection of the 256-color terminal support in pygments.
 
* output would be cached/preprocessed ?

This is a weird question. pyficache in fact does cache Python source text with a way to update or clear the cache. For retrieving arbitrary source lines and for colorizing source text, this is sort of an obvious thing to do. For the debugger command documentation it is much less clear. The speed of rendering debugger command help isn't that critical.

And one has to be careful here when caching formatted output because we allow one to change the line width dynamically inside the debugger. Changes in line width change how lines are reflowed. The nice list of columnar commands inside the debugger already handles this properly. For the previous reasons, columnar lists are not cached and I don't see any need to.

At any rate, I'll see what I can work up in the pygments framework. I was asking because I don't want to reinvent the wheel if I don't have to. Instead, I'd rather funnel into any existing documentation formatting tools. By comparison, in the corresponding Perl Debugger I have been working on I hook into Pod::Text or Pod::Text::Color. This not only saves coding but if you look at the HTML documentation in that link given before, that too makes use of the same debugger-command markup. 

In sum, this debugger has come a way from help given by the stock Python debugger pdb.

 

all the best
  engelbert


On 31 December 2012 02:01, Rocky Bernstein <rocky@gnu.org> wrote:
> Hi -
>
> I am revising the python debugger that I wrote several years ago [1] and
> have been adding better terminal support. For example, the next release will
> include syntax colorization via pygments.
>
> Debugger commands can have somewhat extensive online help. This is stored as
> the docstring of command's class.
>
> For example, here is the help for the debugger's "eval" command, or
> docstring for class EvalCommand:
>
>
>    eval <python-statement>
>
>    Run code in the context of the current frame.
>
>    If no string is given, we run the string from the current source code
>    about to be run. If the command ends ? (via an alias) and no string is
>    given, the following translations occur:
>
>       {if|elif} <expr> :    => <expr>
>       while <expr> :      => <expr>
>       return <expr>       => <expr>
>       var = <expr >       => <expr>
>
>    The above is done via regular expression matching. No fancy parsing is
> done, say,
>    to look to see if expr is split across a line or whether var an
> assignment
>    might have multiple variables on the left-hand side.
>
>    Examples:
>
>    eval 1+2  # 3
>    eval      # Run current source-code line
>    eval?     # but strips off leading 'if', 'while', ..
>              # from command
>
>    See also 'set autoeval', `pr', `pp' and `examine'.
>
>    Aliases: eval?
>
> I would like to use richer formatting than just plain text for terminal
> output. For example <python-statement> might be italicized and "Examples:"
> might be made bold or put in some sort of section.  The debugger currently
> also allows terminal highlighting to be turned off. So in that case, tagging
> should be adjusted, or the tagging shouldn't look too ugly if it does happen
> to have to bleed through. And simple docutils-like tagging is also nicer for
> programmers reading the source code.
>
> Also, the debugger allows for line widths to get set. So the paragraph that
> starts "The above is done..." should be reflowed to adjust to desired line
> width, same as columnize[2] does to to reflow lists of things.
>
> So I am considering docutuils/reStructuredTextr. Also, there is a pygments
> lexer in case I need that; this is useful since pygments will be a
> dependency in the next release.
>
> Is there a reStructuredText to terminal formatter? Is there some other
> simple thing I could use instead that is equivalent or more desirable? Other
> thoughts?
>
> Thanks in advance.
>
>
> [1] https://code.google.com/p/pydbgr/
> [2] https://code.google.com/p/pycolumnize/
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Docutils-users mailing list
> Docutils-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.
>



--
http://jazsoup.net