Avoid use of `query prefix`

[kentookura]

When I updated the neovim plugin for forester to 4.0, I removed the call to query prefix in favor of explicitly configuring prefixes in toml files on a per-forest basis. Recently, there have been some discussions about the status of prefixes in forester. If the vscode plugin also adopted this approach, we could remove the query prefix command altogether, which I only added to support editor tooling in the first place. What do you think?

https://lists.sr.ht/~jonsterling/forester-discuss/%3CD0ZV58LERXYL.1QFR0IG4T8WXM@gmail.com%3E

@Trebor-Huang @jonsterling

[Trebor-Huang]

Can we not alter the behaviour of query prefix to read from the toml, instead of the vscode plugin having to read the file itself? This way it is much more robust to further format changes, because forester is in charge of parsing all the files, instead of the plugin trying to peek into them.

[jonsterling]

@Trebor-Huang That's a possibility, but think before further altering the query interface (aside from decreasing its footprint), I would like to have an actual API with well-defined format, etc.

[kentookura]

I think the query command should just be a frontend for running queries as defined in https://git.sr.ht/~jonsterling/ocaml-forester/tree/main/item/lib/core/Query.ml with no subcommands.

One thing to consider is in which format the user should pass the queries, I think when working on the command line, the backslash-centric syntax is likely to cause problems, especially when users write shell scripts. How about something like and(not(author(foo)),tag(bar))? Obvious con is adding new syntax, but this is something for advanced users anyway. If we reuse the text file parser, users will probably need to do double backslashes \\and{\\not{\\author{foo}},\\tag{bar}} on the command line.

Tomorrow I'll send something out to the mailing list so other people can discuss, we're kind of having this conversation "off the record" atm.

Regarding your comment, Trebor, I personally really like that I can independently make use of the toml config when adding features to my plugin, without them having to be upstreamed into forester. A hypothetical example to illustrate this further is a deployment tool that reads some fields such as a URL and a file containing deployment keys. It makes sense to have this be a part of the toml config to have it be associated to a forest, but I would argue it would not make sense to change the forester tool to regurgitate this info.

[Trebor-Huang]

Ok, this does make sense.

[jonsterling]

This sounds like a very good plan, and I agree with @kentookura about third party (or 'second party') tools making their own use of the toml file.

@Trebor-Huang I would like to release Forester 4.0 pretty soon, but I am hoping to have the query prefix feature removed before release. How do you feel about the dependency of the VS Code extension on this feature in the near future?

[Trebor-Huang]

I can do it tomorrow, once I clear off some homework deadlines.

[jonsterling]

thanks very much!