Support Scopes

[pajoma]

See issue #18 for discussion to this point.

I thought about some sort of scoping (in the sense of free tagging), but I am still not sure how to approach this. My notes typically follow this structure

# Tuesday, June 13th 
* Some memo for project b

*Tasks*
 [ ] Some task in project a

## Some meeting notes of project a
...

One idea would be to tag the various structures (headings, memos, todos) if it belongs to a project, e.g. ## Some meeting notes of !ProjectA!. Special view pages could then aggregate all notes marked with the same tag. I am still not sure which notation to use (# is already used for headers, @ typically denotes mentioning), but maybe this approach is nonsense anyways.

[jvlad]

# seems to be standard de-facto. In header there is space after #:
# New Topic

In tag, there should be not:
#projectA

VSCode and GitHub Markdown parsers distinguish header like # Header from literal like #tag even if you write #tag at the beginning of new line:

Sample Title

vs

SampleTag

So, my suggestion is to follow the standard if it is possible.

---

---

As alternative, I may suggest :: after tag_name:

## Some meeting notes of ProjectA::

Before tag_name is also an option:

## Some meeting notes of ::ProjectA

But the first option seems to be more readable.

[cstuder]

I support the choice of #hashtags, it feels most natural.

According to the Common Mark definition of Markdown used by VSCode, a hashtag immediatly followed by characters (No spaces in between) is not considered a heading and doesn't have any syntactical function. (https://spec.commonmark.org/0.28/#example-33)

[cstuder]

After using the journal for over a year now I still love it. I miss however an easy way to see all entries over time related to a given subject. A timeline view if you wish.

I don't use tags, but instead have valid markdown files with the subject name in a second level heading (## Title).

I am thinking about implementing the following features:

1. Clicking a second level heading (Or alternatively the tags proposed here) takes you to a read-only view with all lines/paragraphs related to this subject, sorted chronologically, reversed in time.

2. When entering notes, use an index to autosuggest past subjects in headings or tags.

There are a lot of subtleties involved in these features, therefore a question to everyone reading in this issue: How do you use the journal? How do your daily entries look?

If you can, post a sample entry in the comments. Here's mine:

# Wednesday, 13. February 2019

## Project 1

- Slack-Webhook switched to channel #notifications.
- Phone call with A.: Agreed to changes, need to send a screenshot of the new interface when done.

## Security

- Changed password on these sites:...

## Project 3

- Updated info page.
- Informed manager about changes on the page.
- Started new branch and deployed to staging, not yet live.

## Python

- Learned about feature x, see docs here: <..>
- Nice tutorial here: <...>

[pajoma]

After using the journal for over a year now I still love it.

Thanks ;)

Here's an example for my daily entries (now going back to 2014) following your layout.

# Wednesday, 13. February 2019

## Tasks
.. list of tasks

## Notes
.. links to notes 

## Time
.. time tracking

## #python snippets

## OAuth problems #security

## Planning #project3

Using tags or headlines as filters for search (using the input and having suggestions or having them as clickable links which open the timeline) needs some sort of internal index. I thought about defining indexed tags in the settings, there you could also include predefined headings. You could then implement a decorator which scans the open file for predefined tags and headers and associate them with links.

[cstuder]

Thanks for the sample.

Yeah, having to maintain an index is gonna be the tricky part I think. I'll have a look around how other extensions are doing this.

[donaldtone]

vsnotes extension, it uses tags to identify files. It uses gray-matter to parse yaml tags.

[JekRock]

I think that finding a note is more important than just taking it. Are you familiar with Roam Research and their approach to taking totes? It would be great to have a tagging system similar to what they have. Here is one code editor extension that has already implemented it. The main idea is to have a search by tags and their combination and to group notes dynamically by tags. For example, you open a note that contains tags, click on a tag will open a list of notes that have the same tag. @pajoma do you think it's possible to add such tagging system to the extension?

[JekRock]

@pajoma one more question. Do you consider a tagging system as a part of the extension or as a part of other extensions like vscode-journal-view ?

[cstuder]

FYI: I'm still (slowly) working on my timeline view as mentioned above.

Not exactly like Roam though.

[pajoma]

@JekRock Tagging is a crucial feature and should be part of the extension. Thanks for the link to Roam Research, interesting piece of software.

@cstuder Looking forward to it ;)

[mameen]

I need to understand some terminology. I can't get the scope system to work for me.. but I like to understand the relationship between the journal, the scope, the note and journal entry.. let me put out my understanding..

Term	Description
Journal	the base folder that holds the subdirectories of journal entries.. e.g. {base}/<YYYY>/<MM>/<DD>/ or base/<YYYY>/<MM>/<DD>.md
Journal Entry	One day in the Journal
Note	some mark down file, that is referenced through some tagging to make it easy to find and open
Scope	The closes thing I can think of is that it is like a project or workspace?

Now, here is how I use / think about the extension..

• I have multiple projects, or bases that I like to switch between..
• I use one journal file (entry) / day
• If I have extra notes, I simply store them in separate folder possibly under version control.. since these could be live documents.. and simple link to them as I would from any root level RADME to external link. This is the concern of the md support in VSCode and not the extension in my point of view..
• I like to switch between projects in a simple way.. here are some possibilities
  • I Personally prefer to reuse the existing worspace feature of VSCode.. and when I switch projects or "scopes" simple switch workspaces!
  • Have a command to switch instead of changing the settings and reloading (that is what i do now unless there is an easier way)!
  • I don't know about scopes, but potentially may be used?

Generally simplifying the extensions and reusing the existing support:

• markdown templated; just use existing snippet support for addind markdown snippets.. maybe create a separate project for them
• opening links, preview, copy / paste... there are many existing good extensions for that
• Just have the Journal extension focus on that it does best.. understand and manage a simple structure for a daily markdown files (or folders!)

[pajoma]

I agree that the vscode workspaces are the way to go. I think we have to distinguish between the following workflows:

• switching between projects
• adding notes and memos while working in a different project

The support for the latter was in my mind while drafting the solution using the tags. You are working in your project (let's say "website_A") and stumble upon an issue which could be interesting for another project "website_b". You could switch the workspace, but that would break your flow. With tags, you simply enter "#website_b Fix for issue", add your thoughts, and that's it. The new file is stored in the notes folder of website_b, and you continue with website_a.

Scopes are identified by tags and can also be added to tasks and memos. But journal entries should be global and span across scopes, I think the whole workflow breaks if we have multiple journals.

Regarding switching between projects: Assuming we have the default scope and website_a. When you open the project "website_a", we could try to infer that you are in a project which is also a defined scope in the journal (through workspaceFolder variable). We could then automatically add the tag #website_a in the input box (and hence making sure that new notes are stored within the current project's note folder). You can still delete the tag, which means the note is stored in the default location.

[pajoma]

Filterting by tags is tracked in #122