autocompletion for metadata values in filter expressions

[zacchiro]

It'd be nice to autocomplete metadata values after the corresponding metadata label followed by ":" is entered in the filter box.

For instance, given these transactions:

2018-01-01 * coffee
    trip: "2017-12-20-beijing-holiday"
    Expenses:Dining:Bar  2.00 EUR
    Expenses:Cash

2017-01-01 * coffee
    trip: "2017-12-20-rome-holiday"
    Expenses:Dining:Bar  1.00 EUR
    Expenses:Cash

after entering trip: in the filter box, it'd be nice to have a pop-up proposing to choose between trip: "2017-12-20-beijing-holiday" and trip: "2017-12-20-rome-holiday".

[yagebu]

This feels like something you should be using tags for, not metadata. Tags are there to group entries into some sets (and I think the prime example in Beancount's documentation is basically the 'vacation trips' usecase).

[zacchiro]

OK for trips, that's my choice, and it's totally debatable. But any metadata that have a finite set of values is eligible for autocompletion. And you can't really say use tags for all of them, because there might be conflicts between metadata fields with different but not disjoints sets of values.

[yagebu]

But any metadata that have a finite set of values is eligible for autocompletion.

That seems to be to me the distinguishing feature between tags and metadata: tags have a limited set of values, whereas metadata might have a different value for each entry (e.g. transaction ids from online banking, statement documents etc.).

because there might be conflicts between metadata fields with different but not disjoints sets of values

I don't quite understand this. An entry can have multiple tags just like it can have multiple metadata values. Or do you mean that this would lead to some namespacing clash?

[zacchiro]

On Tue, Jan 09, 2018 at 10:53:51AM +0000, Jakob Schnitzer wrote: That seems to be to me the distinguishing feature between tags and metadata: tags have a limited set of values, whereas metadata might have a different value for each entry (e.g. transaction ids from online banking, statement documents etc.).

Agreed. But I'm still not sure why that's an argument against autocompletion for metadata values. Given a beancount file, the set of values for any metadata is finite, so why shouldn't autocompletion there be supported? I'd understand more a performance argument, as the set of metadata values might be very large. But then, even the set of tags existing in a given beancount file might be very large...

I don't quite understand this. An entry can have multiple tags just like it can have multiple metadata values. Or do you mean that this would lead to some namespacing clash?

Yep, that what I'm saying. You might have: - metadata1: foo - metadata1: bar - metadata1: baz - metadata2: bar - metadata2: baz - metadata2: qux and you don't want to complete "metadata1: qux". In a sense here you have different autocompletion scopes, while if they were all tags (#foo, #bar, #baz, #qux) there will be a single, global autocompletion scope.

[yagebu]

I have two concerns with this: One is the performance argument. This can be addressed by asynchronously loading the list of metadata values for a key. The other is that this could flood the completion lists, but if it only shows up when the key has been typed already, that's not a problem either.

[yagebu]

A PR for this would be welcome!

[zacchiro]

On Tue, Jan 09, 2018 at 11:21:29AM +0000, Jakob Schnitzer wrote: A PR for this would be welcome!

Of course :-) I should've clarified in my previous message that my main motive for submitting this (and the partially related #633) was to explore the idea with the maintainers and make sure the feature request was welcome. I do plan to start hacking into Beancount code, as it's already become my default accounting UI. Don't hold your breath yet, but I'm motivated for contributing! Thanks for your feedback! Cheers.

[bdowling]

I noticed the differences from the master branch and demo site search fields.

The demo site is showing fields for tag, account and payee separately, with auto-completion enabled for payee for example, but the master branch seems to have a field for account with completion and a combined field for "Filter by tag, payee.." with no auto-completion?

It looks like this change came in PR #631 ref #603.

The auto-completion seems rather useful, is there an effort to add this back in for all the filter prefixes?

Also, I had to do some digging to understand the payee:syntax, etc, -- perhaps there could be a better hint or tool tip while you are entering data in this field.

@zacchiro if you haven't had a chance to start this, I may take a stab at it, just don't want to double up on the same effort.

Thanks

[aumayr]

I noticed the differences from the master branch and demo site search fields.

The Demo-site runs off the PyPI-version, which is a couple of months old, not from master.

@yagebu What do you think about a new release?

[yagebu]

combined field for "Filter by tag, payee.." with no auto-completion?

It does have autocompletion. If it doesn't work for you could you try running from master locally and open an issue?

Also, I had to do some digging to understand the payee:syntax, etc, -- perhaps there could be a better hint or tool tip while you are entering data in this field.

For one, the autocompletion will give a list of all payees (like payee:"Restaurant"), so I think that gives a slight hint at the syntax. Also, we don't currently have a system for showing help in-place, so I think it's natural to expect from users to go to the help pages (where the syntax is hopefully explained well enough).

What do you think about a new release?

👍