That's because I wanted to generate the JSON index from an empty query, I needed the tags for the web search to implement tag filtering. The tags are accumulated from all the zettels that match the query, so effectively an empty query returns all the tags that are used in the zettelkasten, which was also supposed to prepare support for the --list-tags query. Another use is that once we switch to GHCJS (miso looks really cool btw), we could maybe run the query dynamically and only suggest tag filters that have results in the dropdown. Would you rather prefer to generate the index other than with a query? My concern was that it would require to iterate through all zettels twice, once for accumulating all zettels, and another for accumulating the tags.
I should have adapted neuron query to return only the zettels though, and maybe provide a --dump-tags argument if the user wants them anyway.
In general, it is a good idea to do any "customization" close to the place where it is needed, instead of modifying the behaviour of the core function. runQuery should continue to return a list of zettels, and neuron query should just produce a JSON of a list of zettels, as before. If one of the callers (search.html in this case) wants extra data, it should produce its own JSON.
I'll open a PR to make the change so that only zettens are produced by the query command. I don't think tags is used in https://github.com/felko/zettel-mode/blob/master/zettel-mode.el@felko - but I imagine it woud be useful in future. So something like neuron query --list-tags can be added (CLI spec being: (--list-tags | --tag TAG | --uri)).
Yeah indeed, that's a better interface
I was planning on using tags in zettel-mode.el to select tags from already existing ones, which would avoid creating duplicates (something you mentioned a few days ago I believe)
I seemed to have overlooked it? Why does
neuron query
include tags? And zettels via an indirection of "zettels"? image.png@felko
That's because I wanted to generate the JSON index from an empty query, I needed the tags for the web search to implement tag filtering. The tags are accumulated from all the zettels that match the query, so effectively an empty query returns all the tags that are used in the zettelkasten, which was also supposed to prepare support for the
--list-tags
query. Another use is that once we switch to GHCJS (miso looks really cool btw), we could maybe run the query dynamically and only suggest tag filters that have results in the dropdown. Would you rather prefer to generate the index other than with a query? My concern was that it would require to iterate through all zettels twice, once for accumulating all zettels, and another for accumulating the tags.I should have adapted
neuron query
to return only the zettels though, and maybe provide a--dump-tags
argument if the user wants them anyway.In general, it is a good idea to do any "customization" close to the place where it is needed, instead of modifying the behaviour of the core function.
runQuery
should continue to return a list of zettels, andneuron query
should just produce a JSON of a list of zettels, as before. If one of the callers (search.html in this case) wants extra data, it should produce its own JSON.If we want to query tags, we could do something like this:
Or something like this. It keeps the user requirement of "a way to query zettels" intact and simple, while also supporting other results.
(That's just an example, btw. I'm not sure if that's the best way to define it)
I'll open a PR to make the change so that only zettens are produced by the query command. I don't think tags is used in https://github.com/felko/zettel-mode/blob/master/zettel-mode.el @felko - but I imagine it woud be useful in future. So something like
neuron query --list-tags
can be added (CLI spec being:(--list-tags | --tag TAG | --uri)
).--list-tags
would return a JSON of list of tags. The others would print a JSON of list of zettels. No mixing of types here; to keep things simple.Yeah indeed, that's a better interface
I was planning on using tags in zettel-mode.el to select tags from already existing ones, which would avoid creating duplicates (something you mentioned a few days ago I believe)
Yea, I want that feature as well!