1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
# A linter for gnbug
## Tags
* type: feature-request
* keywords: gnbug, linter, tissue
* assigned: ??
* priority: low
* status: under discussion
## Description
Should gnbug have a linter?
For example, If a user forgets to add a tag or some other syntax that we want them
to add then the linter reminds them to add more info, tags, etc.
Or, maybe we want to check that the user does not add a tag that we don't want to
support.
I am not sure. Pjotr is of the philosophy that we should keep the text as unstructured and unrestrictive as possible, and I agree with this philosophy. Linters are likely to annoy users more than help them. They might discourage casual use of the issue tracker. Especially with tags, we don't really want to restrict the user from coming up with new tags.
WDYT? Am I missing some scenario where the linter could be essential?
Nope, it was just something I thought could be convenient if we wanted to restrict
the format for tags, etc...
If we'd like to "keep the text as unstructured and unrestrictive as possible" I'm
fine with that too.
I was just worried about using "invalid" tags. Now, I know it's ok :)
### 2022-03-14
I am thinking tissue (formerly gnbug) should deal with a list of tags of the form:
```
* key: value[, value, ...]
```
and each instance of the issue tracker can have some config file that defines, among other things:
* what tags to display
* colouring of said tags
* maybe what tags to allow (for those that need to restrict allowed tags)
The tags could be parsed into a hashmap or an associative list, or any other similarly useful datatype, from which the values would be read for display.
Tissue could determine what the context is (CLI, web, etc) and using the config, figure out what tags to display and how
## Closing
We don't have tag restrictions for now. And, tag restrictions probably go against the "unstructured and unrestrictive" aesthetic that we are aiming for. In the web UI, we can color tags using the provided CSS classes. In the CLI, we have a fixed blue color for all tags. Short of supporting full-fledged CLI color theming, it might be counterproductive to allow changing colors of specific tags in the CLI. If filtering based on tags is the objective, we now also have a powerful xapian-powered search interface.
* closed
|
