UI: autocomplete-for-tags

[thseiler]

This PR generalises the autocomplete feature to work for "Tag" fields (#2230)

The autocomplete options are collected from the contents of all the same fields of the current document.
I wonder whether we should also allow specifying optional default values in the grammar:

  - TITLE: TAGS
    TYPE: Tag
    REQUIRED: False 

  - TITLE: TAGS_WITH_DEFAULTS
    TYPE: Tag(Derived, Safety-relevant, Security-relevant)
    REQUIRED: False 

It could help with consistency. Let me know what you think...

[stanislaw]

Hi @thseiler, I will be reviewing this during the day.

Just a note regarding the TAGs: it looks like their handling is similar to that of MultipleChoice. To be honest, the tags feature was never developed to something that makes it a standalone feature. Could you describe how do you see the Tags work differently compared to MultipleChoice? Is there an opportunity for removing Tags altogether and moving forward with just MultipleChoice? I am curious to hear about your perspective. Understanding this would give an idea of whether the Tags are actually a mechanism of its own scope and value. Thanks.

[thseiler]

I would like to better understand how others use the "Tag" type as well.

The main difference for me is whether the users are allowed to add (invent) new values on the fly:

• MultipleChoice: No, the allowed values are constrained by the Grammar. Autocomplete collects possible values from Grammar.
• Tags: Yes, the users can add new values while editing. Autocomplete collects possible values from other nodes in the Document.

I can see a use case for both, i.e. :

• Multiple Choice: useful for STATUS or similar fields which are rigidly tied to some higher-up process.
• Tags: mainly useful for me as author. I can leave "spontaneous little bits of information" for myself, i.e. hints at things that still need fixing, like "todo_safety", or "todo_testcase" there. I don't want to change the grammar for this.

One could potentially merge the two behaviours into just "MultipleChoice" by adding a property on whether the choices are to be constrained. If the property is if omitted, then the field would be contained by default to keep compatibility to MultipleChoice() as it is today.

Even then it could make sense to keep "Tag" alive as something separate to allow distinct visual styling. For example, the "Tag" type could imply a pill/chip visualisation of the values (in the future).

[stanislaw]

Your answer about MultipleChoice vs Tag makes sense. Let's maintain it like that. I have added a note to the documentation train to explain this like you suggested: #2067.

I would like to better understand how others use the "Tag" type as well.

I created tags with a similar idea like you explained, but we never pushed it to be displayed with UI in any nice way. I could imagine that the search query and UI would be extended to support filtering by tags, and the project statistics would show the Tag-breakdown for each document. Doing Document-level stats breakdown on Project Statistics is a related work item which does not have a ticket yet.

StrictDoc's own documentation does not use any tags, but I saw tags used very heavily in one project where multiple teams (electrical, SW, RAMS, etc.) worked on one big spec, and the tags were used to highlight specific areas of attention. This was very useful.

@mplum and @pasrom contributed PRs related to Tags. Maybe they could share their thoughts here.

The autocomplete options are collected from the contents of all the same fields of the current document.
I wonder whether we should also allow specifying optional default values in the grammar:

  - TITLE: TAGS_WITH_DEFAULTS
    TYPE: Tag(Derived, Safety-relevant, Security-relevant)
    REQUIRED: False 

I don't consider this a major need given the other priorities but if you feel it would simplify your workflows, please suggest a PR.

Thanks again for contributing this.