Would you accept a PR for adding a slash command + rendering datalog queries in an inline editor? Here’s roughly how the before and after would compare:
Before
Currently, Datalog queries are a little uncomfortable to write from an ergonomics standpoint.
The #+BEGIN_QUERY syntax is likely unfamiliar to most users.
The code block would be more readable if it were rendered in a classic monospace font rather than a sans-serif, in order to differentiate it from the rest of the bullets on a page.
It’s hard to discover the capability, because it’s not a slash command at the moment like most other features. As a result, you have to know that the #+BEGIN_QUERY syntax is available in order to use it.
If a user clicks into the results, instead of going to the raw text (as it does right now) it would go into the editor view.
If the user does want to get to the raw view, they can get there by going into the editor view and clicking “query” in the top right corner.
Feedback wanted
I don’t love the /Query (advanced) naming I proposed for the slash command. I wanted to use /Query, but that’s taken by the simple query already (i.e. /Query generates {{query }}). One thing we could do is rename that one to /Query (simple) to maintain a bit more symmetry with /Query (advanced), or we could name the new query slash command to just /Datalog query. I’d love to hear entirely different suggestions too.
from a ux perspective I would prefer if the ‘/slash command name’ is the same as the code block language (when using 3backticks followed by language name. as this would probably be my preferred way to create the block).
so I would not go with ‘/query (advanced)’, but rather stick with ‘/query’ or 3backticks+‘query’ or ‘/datalog’ (3backticks+‘datalog’) – and maybe rename simple queries as /simple-queries?
Love this!
The Datalog queries are complex than the simple queries for most users, I guess most users would like /query for simple queries
I agree with both you and @cannibalox that we can have a /Datalog query.
It can generate this for markdown:
``` datalog
```
For org-mode:
#+BEGIN_SRC datalog
#+END_SRC
The datalog syntax is actually Clojure, so we need to tweak it in CodeMirror.
Another question if I have understand it right. If we use “datalog” in 3batsticks how can Logseq differentiate it from another generic datalog query? Imagine that I have some snippet code of datalog and I create a code block marked as datalog. Will Logseq try to execute it because it thins that it’s an advanced query?
Perhaps it’s needed another name.
“logseq-query” or “ls-query” can be less generic and more specific. For future code blocks related to Logseq it can be used as a pattern “logseq-*” so there is not collision with future codemirror languages or if some plugin uses it to execute its contents.
Let’s see what others think about it.
After reading the commommark spec related to 3batsticks, and doing a test in Typora and VS code, it’s possible to use some words as info string (name of the string after 3batsticks). So you can use “clojure query”, “clojure datalog”, “clojure logseq query”, etc.
Using “clojure” first in the info string would make editors mentioned above render it with syntax highlighting and also logseq will get enough information from info string to know if execution is needed. So we get compatibility, syntax highlighting outside of Logseq and a query result inside. A big wing
great ! seems like ```clojure query and /clojure query would be a good compromise between usability and features.
probably ```clj query would work for code highliting in code-mirror ? and the slash command could be: /clj query ?
I come very late to the discussion. I do not know if this is still relevant but here are my thoughts.
Why distinguish between both types of queries. Personally I find the current /query and <query confusing. I had to ask here to find out the <query is advanced query and /query is simple query.
Just make a one /query slashback command. Or optionally use backticks ```.
Prefill the query windows with “#simpleQuery” as the default is simple query. When the user wants to use advanced/datalog/closure query they can change it to “#datalogQuery” or something like that.
I think it is valuable to have just 1 /query option where all your queries are made.
If you create an editor windows (like the original poster suggested I think) you might even add a GUI element (check or dropdown) to make switching between the two even easier.
I think this issue, expressing desire to have a custom view of a query, highlights that preferred way to view data is subjective.
Some folks may prefer to deal with query data as simple text, some may prefer to have a more semantical view of a rich text editor, some may prefer to have a full-fledged UI.
Options for how to present stuff are endless. The stuff to present, however, stays the same.
Shall we, perhaps, allow end-users to express their desire of how they can view stuff?
Then stuff will stay simple data (in our case, edn marked as ‘datomic query’) and users will be able to choose from a set of UIs/widgets to present such data. (a user-wide setting)
Akin to the Semantic Web.
