Specifying note title and tags in templates

nishantwrp · 2021-08-11T16:52:15.586Z

laurent:

Wouldn't it be possible to use the template note title as the new note title?

We can do it, but now with this feature the user can cutsomize the title. So, I think that this is better than using the same title.

laurent · 2021-08-11T16:54:38.132Z

nishantwrp:

We can do it, but now with this feature the user can cutsomize the title.

I might be missing something but why can't they customise the title if it's the actual template title?

nishantwrp · 2021-08-11T17:00:07.349Z

laurent:

I might be missing something but why can't they customise the title if it's the actual template title?

For example, They want to have the minutes for a meeting. They currently have two projects, Proejct 1 and Project 2. With this feature, they'll be able to use variables in the title and it could be dynamic.

For example,

---
project: enum(Project 1, Project 2)
note_title: Meeting Minutes - <% project %> - <% date %>

---

## Meeting Minutes
*Write notes here*

Now, when we create a new note with this template and select Project 2 say in the selector. The title would automatically become Meeting Minutes - Project 2 - 11/08/2021.

laurent · 2021-08-11T17:17:00.318Z

Thank for clarifying. But what if the template title is Meeting Minutes - <% project %> - <% date %>? I guess the title is not currently being processed by Handlebar but maybe it could?

nishantwrp · 2021-08-11T17:21:52.147Z

Ah, that's a nice idea! But we want to do a similar thing for tags too. How do you think we do that without creating a variable?

IMO, creating tags with titles like <% project %> would be a bit weird. What do you think?

Btw, I like this approach you suggested. In this way we'll be able to avoid using <% %> brackets and use the same handlebars style brackets i.e. {{ }}.

JackGruber · 2021-08-11T17:29:48.044Z

Is the problem with { } a error like All collection items must start at the same column?

nishantwrp · 2021-08-11T17:33:05.201Z

In the YAML parser? It actually, assumes the value as null. For. eg.

name: text
note_title: {{ name }}

The parser reads the value something like

{
  "name": "text",
  "note_title": null
}

JackGruber · 2021-08-11T17:37:29.487Z

Yes in the YAML.

I think you need to write it like:

name: text
note_title: "{{ name }}"

or

name: text
note_title: Project {{ name }} meeting

because when the value of the option starts with an { and ends with an } I mean they think this is an Object on parsing and make the following:

{
  "name": "text",
  "note_title" {
      "name": null
  }
}

nishantwrp · 2021-08-11T17:43:41.450Z

Oh, ok. Didn't know that. Thanks for this. I'll try and see if this works.

UPDATE - It works! We can use the same {{ }} brackets.

nishantwrp · 2021-08-11T19:02:46.327Z

According to me there are two points that need to be discussed before implementing this feature.

Using template_title and template_tags instead of note_title and note_tags and informing users that they should avoid using template_ variable names as they may become special variables in the future.
Should we use the actual template tags and title instead of special variables?

JackGruber · 2021-08-11T19:08:32.942Z

nishantwrp:

Using template_title and template_tags

I think the naming template_ for special variables of the plugin is a good choice.

nishantwrp:

Should we use the actual template tags and title instead of special variables?

Not for tags, because they can no longer be made dynamic.
For the title possible, but could look a bit confused in the overview, but to make it consistent I would also put it in the YAML area and at most if none is defined use the title of the template.

tessus · 2021-08-11T19:16:54.026Z

Will something like this work now?

note_title: Sprint {{bowm}}

nishantwrp · 2021-08-11T19:21:14.399Z

By now, do you mean when this feature is implemented? If yes, then yes.

codyburleson · 2021-08-13T14:31:26.175Z

Maybe I don't fully understand, but this seems a little overengineered to me. Why not just allow variables in titles and be done with it? By simply allowing template variables (one to many) in titles, you effectively accomplish the same thing without the need for special reserved variables.

nishantwrp · 2021-08-13T14:58:40.351Z

Actually, we have to do the same tags and maybe in the future for target notebooks (you can read this). If we want to do it for title only then using the template note title seems good.

uxamanda · 2021-08-13T17:14:28.863Z

JackGruber:

For the title possible, but could look a bit confused in the overview, but to make it consistent I would also put it in the YAML area and at most if none is defined use the title of the template.

I like this as a solve - if the user doesn't have a template_title or template_tags in their yaml, it uses the one from the template itself, otherwise the yaml overrides. Although I am guessing the "template" tag itself would not be inherited

JackGruber · 2021-08-14T13:56:54.999Z

codyburleson:

Why not just allow variables in titles and be done with it?

I don't like it when all the variables appear in the template selection.
In addition, I would find it great if the templates are called differently than the created note then, especially for the dropdown selection are speaking names more meaningful.

Project meeting
Project ToDo
...

and not

Standup {{bowm}}
Meeting {{project}} on {{date}}
{{project}} - {{taskdescription}}

Maybe you should consider to put the note options and the variables in their own section, so that there are no name overlaps?

variables:
  name: text
  project: enum(Project 1, Project 2)
  notebook: text
  tags: text
  test:
    label: Text for the input mask
    type: text
    ...
note:
  tags: daily, {{tags}}
  title: Meeting project {{project}} on {{date}}
  notebook: {{project}}
  ...

nishantwrp · 2021-08-26T18:33:42.354Z

Template Plugin Template Plugin

Release v2.0.0 Features add support for adding labels for custom variables (b138110), closes #30 allow specifying title and tags in templates (c36dea0) use dropdown instead of enum for better user experience (c009fc9), closes #7 Bug Fixes auto wrap special variable values in double quotes (720eea2) ignore eslint errors for \S (dd98f44) parser: update the regex used to find special variables (cb3d677) For reporting bugs/feature-requests or to know more about the plugin visit the Git…

joeldebruijn · 2021-09-02T18:58:01.505Z

I was looking for a way to batch/bulk create notes and read all the plugin suggestions.

Then I thought maybe if the template plugin could create a note for all permutations of a variable? For example "Day of the Week Number" creates 7 notes. Or for a range, for example "Week Number 23 to 28" creates 6 notes.

("Proceding with caution" caveats etc because it could spawn 100 notes if done wrong)

Could come in handy for this also:

Managing a daily/master todo list Support

I could use some ideas on how to better manage the following! I maintain one "master" todo list that I consult every morning to determine what todos I want to work on that day. Many of the todos are just plain text because there's not much detail I need written out (no dependencies that need to be done beforehand, I have all the necessary details in my head). The more involved todos will be links to notes that contain the necessary details/reference material. Because this is a very long list o…

nishantwrp · 2021-09-02T22:39:52.193Z

That’s a nice use case. But I am unable to think of a good way to implement this. I think it will be too confusing for a large number of users and yes as you mentioned it will be frustrating if it doesn’t behave the way they expected it to because it could create 100s of wrong notes.

But maybe, we can create a new plugin that works with template plugin to do batch creation. I am not sure if the commands registered by template plugin can be used by other plugins.