logseq13-full-house-plugin: Any way to render but keep the original block contents?

Looking for a quick way to insert a wiki link using the current page name, first I consider logseq-powerblocks-plugin then cannibalox in forum recommend this.Then I experience this powerful plugin, it deal with the variable such as page name perfectly.

But while I use it in page property block, I realize it renders after clearing the original content of the block. That means it can’t be use in a block that has any content. I think this would cause a big limit to its powerful feature.

So I think is it any way to add the template content but do not clear or replace the original content, just like logseq-powerblocks-plugin?

Discussion: https://discuss.logseq.com/t/any-way-to-get-variables-value-in-custom-commands/15994/1

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 17 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Does it mean full-house could completely replace native template entrance and use “/template” to call up, if the native templates syntax feature has implemented?

Sure 😎

The filter feature sounds … the most powerful, wouldn’t it a little complex though?

Technically — absolutely not complex. The main caveats here is product design of the feature. I guess I’ll come to community and users of Full House to get feedback, thoughts, usage cases, problems, etc.

inline templates: Easy to understand and use, but not so friendly for each time use?

They will be very similar to :commands from config.edn. But with full house of rendering abilities 😎

wow. Heard this I thought I could refer the template uuid in its block as a hidden property, then uuid will be preserved so I could del the template name and use uuid to specify. But practice proved it failed.🤣

I’ll check this case later 👌

@stdword Yes. I use it like this.

 ;; Add your own commands to speedup.
 ;; E.g. [["js" "Javascript"]]
 :commands
 [ 
   ["Wiki EN" "{{renderer :template, ((64287991-819d-4893-ae70-07edc3524ac3))}}"]
   ["Wiki EN Embed" "{{renderer :template, ((64287991-cf53-498d-a4cd-e4e7cfa66b72))}}”]
   ["Douban" "{{renderer :template, ((64287991-4619-4821-9360-325a2c9d347d))}}"]
   ["saying" "#saying"] 
 ]

My template blocks, no need to add properties to parent blocks now: image

@stdword Take me some time to test it. It works well now. Seems like while copying a block ref, Logseq will give a hidden block property id:: in file.

Take a while to notice that template:: and template-including-parent:: false become useless now, then I deleted all the properties of parent blocks and directly copied the ((uuid)) of template block(used to be child block) to my config.edn. Well done.

@stdword hi, again!

I’ll check this case later 👌

I promised to return to this point and now it fixed with the last version of 🏛 Full House Templates: just use copy command from context menu block and block uuid WILL be preserved.

Also note a new big feature — :template-view. With views you can create cool auto-rendering stuff like Daily Journal Templates or Folding page references

Are all macros “space sensitive”? I found if no space between a comma and an argument, the macro would not be rendered.

You’ve faced with known bug, one more time) I definitely stands on importance to be space-independent and user friendly as much as possible. Will fixed it after more important ones. You could watch the issue.

And it seems sensitive to the order of arguments. In my test, the first argument seems always be considered as a page name, even if I specified all the arguments using -.

This is true:

  • the first arg after :template is always the template name
  • the second one is always the page name — it was introduced to easily switch c.page context variable

As of for now page arg should be specified (with «—» to skip or in full page-ref form) every time you want to send an argument to template. But I don’t like this behaviour too. I will think on ways to get off the ambiguity. Also created an issue so you could subscribe to get updates.

PS and again — thank you so much for a feedback 🙏💜

@stdword WOW sounds great and exciting.

  1. Does it mean full-house could completely replace native template entrance and use “/template” to call up, if the native templates syntax feature has implemented?
  2. The filter feature sounds powerful. Prefix is for namespace? Related binding is for page or block properties(tags…)? Perhaps can consider a build-in property-value filter, so that can specify in a template’s property — it can be retrieved in which pages with which property and what value. It sounds is the most powerful, wouldn’t it a little complex though?
  3. Easy to understand and use, but not so friendly for each time use?
  4. wow. Heard this I thought I could refer the template uuid in its block as a hidden property, then uuid will be preserved so I could del the template name and use uuid to specify. But practice proved it failed.🤣

@stdword Cool! Thanks for the work! I already tested it, it works well now, also with macros.

Another question: Is it possible or a good idea to hide it in Logseq template menu? A setting to switch, or use different property name like “template+” or something like that, to avoid it showing in sys-template menu?

Because of the variables, these “enhanced templates" almost won’t be used in sys-template menu. With time passed, a predictable situation is, normal templates will mix up with them and hard to be pick out.

Now it works as you expect: <video width="40%" src="https://user-images.githubusercontent.com/1984175/226592634-e1967483-6a27-43ec-a67b-f64d7a315a8a.mp4"/>

⚠️ I’ll check your exact case with inserting code inside macro later today.

Hello! Thank you for response and feedback! It is really important to me.

Quick response: It is a bug I’m aware of and will be fixed at the very next version.