[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: tla update
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Re: tla update |
Date: |
Sat, 13 Sep 2003 14:57:19 -0700 (PDT) |
> From: =?iso-8859-1?q?Michael_Teichgr=E4ber?= <address@hidden>
> I have tested this by extending struct vu_handler (maybe this is no
> good idea) to
> struct vu_handler
> {
> struct vu_fs_discipline * vtable;
> void * closure;
> struct {
> int indent;
> int column0;
> } printfmt_settings;
> };
> , modifying printfmt_va_list as explained, and enclosing three
> printfmt occurences in cmd-update.c like this:
>
> printfmt_set_indent (1 /* fd */, 0);
> safe_printfmt (1, "\n* reapplying local changes\n");
> printfmt_set_indent (1, 2);
> With a similar function one could prepend each line of output from a
> subcomponent with a prefix string.
Let's say it's an _interesting_ idea.
There's a pattern that crops up from time to time wherein you have
some program that wants to do just "free-form" human readable output.
At the same time, you'd like it to do machine-parsable output so that
the output is programmatically useful as a (conceptual) "return value"
from an invocation. (GDB is another example of a program where this
pattern crops up.)
Whenever practical, obviously, you just want really simple output
formats. (E.g., a list of values, one per line.) It doesn't always
work out that way, though -- as in tla (or GDB) where you wind up
wanting to "compose" outputs to form more complex outputs and so
forth.
I'm all in favor of adding a little bit of goo to the printfmt
family of functions to better structure output. I'm not too
confident that your particular first-pass hack of adding an
indent-level to printfmt is the right design.
-t