Fwd: [Bitbucket] Issue #392: Booking method not applied when used in included file (blais/beancount)

[Martin Blais]

One often recurring issue is that of new users getting confused about options in included files.

I'm contemplating simply disabling them to avoid confusion.

Does anyone care for options in included files, or use them for anything useful? 

(AFAIK they shouldn't be working.)

Let me know,

---------- Forwarded message ---------
From: Alen Šiljak <issues...@bitbucket.org>
Date: Sun, May 5, 2019 at 5:16 AM
Subject: Re: [Bitbucket] Issue #392: Booking method not applied when used in included file (blais/beancount)
To: <bl...@furius.ca>

Alen Šiljak commented on issue #392: Booking method not applied when used in included file If I move the booking method directive to the root file (split.book.bean), then it gets applied. View this issue or add a comment by replying to this email. Unsubscribe from issue emails for this repository.

[Stefano Zacchiroli]

On Sun, May 05, 2019 at 08:09:30AM -0400, Martin Blais wrote:
> One often recurring issue is that of new users getting confused about
> options in included files. I'm contemplating simply disabling them to
> avoid confusion. Does anyone care for options in included files, or
> use them for anything useful? (AFAIK they shouldn't be working.)

What is confusing is that they work in the main file but not in included
ones. Disabling them completely from included files (which is what I'm
assuming your proposal here is) wouldn't make it any less confusing.

More generally, when you have file inclusion support in some sort of
language/templating system, the general expectation is that it is should
be completely transparent and that you can always "refactor" your files
any way you like without incurring in semantically meaningful changes.
I have no idea how hard it would be to get that with Beancount (maybe
inclusion should just become a purely textual operation, delegated to a
"dump" file processor?), but IMHO *that* is what will make file
inclusion not confusing at all.

Cheers
--
Stefano Zacchiroli . za...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[Alen Šiljak]

This is exactly what I was expecting with the include directive: https://bitbucket.org/blais/beancount/issues/392/booking-method-not-applied-when-used-in#comment-51970529

I find it keeps things simple and opens more doors than it closes. A "selective" include directive is too moody for me. The meaning is hidden somewhere in the source code. To illustrate the point, after hitting a few walls like that I almost feel as if I'm walking through a minefield, not using a tool that's supposed to help me get the job done.

[Alen Šiljak]

It is interesting that the option to set the operating currency works from included file, though. That makes it even more confusing. :)

[francois PEGORY]

According me , I think either :

1) it is possible anywhere and it work as it was put in the main file.

Easy to explain , hard to implement.

2) if you put it in a file included, it raise a error.

The only question  is which directive are reserved for the main file. 

First thought , include and options

What do you think ? 

Le dim. 5 mai 2019 à 14:43, Alen Šiljak <alen....@gmx.com> a écrit :

It is interesting that the option to set the operating currency works from included file, though. That makes it even more confusing. :)

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/6d1f7edf-4677-44ed-a267-3b4c89104386%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alen Šiljak]

While I have not looked at the related source code yet, I'm wondering what is it that makes it hard to implement.

My assumption was that include directives would be parsed, the related files concatenated into the end-result: a complete input file. From there on, the actual processing of directives would continue.

Or, if directives would be processed one-by-one, the included file with options being the first, should still somehow get processed first.

Obviously, there are reasons why things are not this simple.

[Zhuoyun Wei]

On Sun, May 5, 2019, at 20:51, francois PEGORY wrote:
> According me , I think either :
> 1) it is possible anywhere and it work as it was put in the main file.
> Easy to explain , hard to implement.
>
> 2) if you put it in a file included, it raise a error.
> The only question is which directive are reserved for the main file.
> First thought , include and options
>
> What do you think ?
>

I'm with the second approach. Raising an error if any option directives are detected in included files is better than sliently ignoring the options and confusing (new) users.

--
Zhuoyun Wei

[Martin Blais]

This is what I meant. By "disabling" I meant not silently ignoring, but raise an error.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/42a9180e-d023-46f4-be0e-c8a66993b5b1%40www.fastmail.com.

[Martin Blais]

BTW, as a quick note, purely textual include should be doable with a simple wrapper script that invokes the c++ preprocessor frontend.

(I can't remember why I didn't implement it as such at the time.)

[Stefano Zacchiroli]

On Sun, May 05, 2019 at 03:05:28PM -0400, Martin Blais wrote:
> BTW, as a quick note, purely textual include should be doable with a simple
> wrapper script that invokes the c++ preprocessor frontend.
> (I can't remember why I didn't implement it as such at the time.)

Yeah, that's what I was referring to with using a "dumb" preprocessor
for dealing with includes. It would be the best solution for settling
once and for all all include surprises.

[Martin Blais]

On Mon, May 6, 2019 at 3:56 AM Martin Michlmayr <t...@cyrius.com> wrote:

* Martin Blais <bl...@furius.ca> [2019-05-05 15:05]:

> BTW, as a quick note, purely textual include should be doable with a simple
> wrapper script that invokes the c++ preprocessor frontend.

Wouldn't that mess up line numbers and error messages?

Ahh yes. Beancount would have to honor the #line directives.

 

--
Martin Michlmayr
https://www.cyrius.com/

[Stefan Monnier]

>> > BTW, as a quick note, purely textual include should be doable with
>> > a simple wrapper script that invokes the c++ preprocessor frontend.
>> Wouldn't that mess up line numbers and error messages?
> Ahh yes. Beancount would have to honor the #line directives.

There can be other surprises with CPP, since it's specifically designed
for C/C++ and not for Beancount. We used to use CPP to generate Emacs's
Makefile and there were a few oddities we had to work around (can't
remember the details, but at least there were a few predefined CPP
constants which caused undesired substitutions).


Stefan

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2019-05-05 15:05]:

> BTW, as a quick note, purely textual include should be doable with a simple
> wrapper script that invokes the c++ preprocessor frontend.

Wouldn't that mess up line numbers and error messages?

[Red S]

Related, I'm guessing: I'm unable to use the plugin directive from an included file. +1 for Stefano's comment earlier about include being transparent, so refactoring the source files has no effect.