Okay, so let's hear John's opinion on where and how init-file should be
handled.
The option handling code is kind of convoluted and neat at the same time
due to the use of macros. But the way I understand it every set-operation
leads to option_t::on() being called, either directly or through
option_t::handler() which in turn is called by the likes of
process_option()(through
option_t::operator()()).
An eye-opener for me was to se the macro expansion of an option definition,
so here you go: (Using c-macro-expand in emacs)
OPTION__
(global_scope_t, init_file_, // -i
CTOR(global_scope_t, init_file_) {
if (const char * home_var = std::getenv("HOME"))
on(none, (path(home_var) / ".ledgerrc").string());
else
on(none, path("./.ledgerrc").string());
});
gets expanded to
struct init_file_option_t : public option_t<global_scope_t> {
/* -i*/ init_file_option_t() : option_t<global_scope_t>("init_file_")
{
if (const char * home_var = std::getenv("HOME"))
on(none, (path(home_var) / ".ledgerrc").string());
else
on(none, path("./.ledgerrc").string());
}
} init_file_handler;
So when you see HANDLER or HANDLED somewhere that simply is a call to the
operator()() or bool() function of that class member (init_file_handler).
On Tue, Jan 8, 2013 at 7:39 PM, Craig Earls <[email protected]> wrote:
> Actually I misrepresented something here. the init_file was filled from
> handle_debug_option already, I simply code-fu'd that into submission. I
> did not add the init_file handling to handle_debug_options.
>
>
> On Tue, Jan 8, 2013 at 11:16 AM, Craig Earls <[email protected]> wrote:
>
>> You are correct, of course. I attempted that approach but decided moving
>> the init-file logic to the handle_debug_options was much simpler, even if
>> not as obvious from the names of the functions. Identifying the source of
>> the init-file specification was the key to eliminating the bug and I really
>> can't see anyway to do it other than using 'on()' (it appears to be the
>> only place that function is used based on grepping around the code). A
>> similar approach is needed for the price-db and get-quotes (if it ever
>> comes back)...
>>
>>
>>
>>
>> On Tue, Jan 8, 2013 at 11:04 AM, Johann Klähn <[email protected]> wrote:
>>
>>> The problem with 'init-file' though is that `read_init()` is called in
>>> the constructor of `global_scope_t` and the arguments are read later
>>> through a call to `global_scope->read_command_arguments()` in
>>> `main()`.
>>> Your patch introduced logic for init-file in `handle_debug_options()`.
>>> A cleaner way would be to set `init-file` using the option handling
>>> code in that constructor but one would have to introduce a further
>>> loop to extract the init-file argument before `read_init()` is called.
>>> Take a look at `global_scope_t::read_environment_settings()` for how
>>> to set an option using the option handling code.
>>> Maybe the option definition for `init-file` in `global.h` should check
>>> if the file can not be found and throw an error (using 'DO_')? But as
>>> the constructor also calls 'on()' the original question remains the
>>> same: How to differentiate between default and user-provided value.
>>>
>>> On Tue, Jan 8, 2013 at 6:06 PM, Craig Earls <[email protected]> wrote:
>>> > John,
>>> > Some time ago I submitted a pull request to fix a problem with
>>> ledger and
>>> > the default init file. You mentioned on the comments to the pull
>>> request
>>> > that ledger has a way of signaling that an option came from the
>>> command line
>>> > (I added a method to interrogate the data for the options command). I
>>> can't
>>> > figure it out when/where ledger is storing that information.
>>> >
>>> > There is a similar problem with pricedb (Bug705) that I want to work,
>>> and it
>>> > is probably worth solving both the same way.
>>> >
>>> > --
>>> > Craig, Corona De Tucson, AZ
>>> > enderw88.wordpress.com
>>>
>>
>>
>>
>> --
>> Craig, Corona De Tucson, AZ
>> enderw88.wordpress.com
>>
>
>
>
> --
> Craig, Corona De Tucson, AZ
> enderw88.wordpress.com
>
