How to exclude a block from being linked to a page/tag inside the same block tree?

TL;DR: is there some feature that allows me to mark a block as “do not include in the linked references” of a page if a parent block links to a page?

the situation I want to do this in is as follows: I am working on project A today and thus I am creating a new block in my journal tagged with #[[Project A]]. everything I do on that day/in that work session about the project we’ll become a sub block of this tagged journal block ( which I will call the root block). Now while working on project A I discover something that reminds me of project B or some problem with a setup. because that’s easiest for me I am simply creating another level of indentation which I can later minimize. Then it is still there but doesn’t distract me. The problem arises when I identify todos for project B or my setup and put them there - because then they show up in the todo query for project A even though they have nothing to do with it.
I would like to have a way to just say “these sub blocks do not belong to project A anymore”.

I see two hacky ways:

  1. putting the todo (or whole discussion) as a new root block with a block reference. Problem: that’s significantly more work for me and distracts me + then I can less easily rediscover my train of though
  2. Create [[Project A/Not relevant]] and make my todo queries filter them out. Problem: I would need to do this for every project so it would become quickly annoying.

Is there a way to do this already?
otherwise I would either change this to a feature request ( or make up a new topic that basically requests that feature, whatever is considered to be more clean in the context of the forum).

1 Like

Consider adding a special tag (e.g. #[[not in A]]), then filter it out in your custom queries.

1 Like

If they have nothing to do with it, they should not be there.
Aside from what @mentaloid proposes you might consider:

  • after being done, so not in the middle of work
  • grab the highest level still relevant to project A. And copy its reference
  • make that reference a new root block
  • put everything not relevant to project A that sits underneath that reference under the new root block

This accomplished two things
Or actually 3 really.

  1. The information no longer shows up under Project A.
  2. You can find your train of thought easily through the reference.
  3. You can even see on project A that there is another block related as the block that is referenced will have a little number on the right to indicate it is used elsewhere.
1 Like

How would this be effectively different than my 2. hack?

I see.

That is a bit of a problem for me. yes I can recover the train of thought, but it does not come as easy as I like it to be. Because to have a reference there is not to have the actual text there. And at least for me it is a bit distracting when I click on a block to see references and then to get back (as alt-back does not work from black to journal for me most of the times, maybe I should investigate that more). Tbh, it is not a huge issue though. I mainly wondered whether there is a better way.

1 Like

You don’t have to create the tag (i.e. to add it as a page), you just say it (i.e. type it as you think of it). If this is what you meant in first place, it isn’t a hack and it doesn’t sound annoying to me.

1 Like

Ah, sorry, I just meant typing with that. Though usually I use autocomplete so I would need to try out whether it already exists or not (which already distracts me a bit, not too much, but more than I would like it to be).
The bigger problem would be modifying my todo queries, as they are four almost identical queries but based on the priority. I guess I could make my work easier there with some advanced templates - but I am not knowledgeable about logseq yet to do that.
( more precisely what I would like to do is being able to put a page, e.g. [[Project A/Issue 1]] into a function and get the four queries that search for tasks of [[Project A/Issue 1]] and exclude everything with [[Project A/Issue 1/Exclude]])
But thinking about this: there would probably be some edge cases where this doesn’t work as I want to, but I can’t put it into words easily right now.

This is exactly the issue:

  • These are edge cases of an already edgy workflow.
  • The more difficult it is to express an edge case:
    • the less appropriate to implement as a standard feature of the application
    • the more appropriate to express as a query
      • granted not being easy, but still possible

And if you end up with a specific sequence of actions, Logseq provides some options for automating them.

1 Like

Since I do not have an idea of what is possible or not right now: should it be easily possible to write a template/plugin/whatever where I can say in a block “create a new root block in todays journal that references the current block”?

There is an API that (among other possibilities) makes it possible to create with code new blocks of whatever content and place them at any position. There is variety in both the options and their degree of difficulty. In any case, it all begins with a good description of what is desirable, preferably in small steps that are useful on their own. In other words, don’t aim directly for an ideal solution, but for small improvements. Chances are that, as the overall situation improves and the experience increases, both the workflow and the description will change a lot, making any initial plan irrelevant.