-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tags #125
Comments
StorageThree ideas. Number one. Store what hyphae have what tags in type TagStorageRecord struct {
Tag string
TaggedHyphae [] string
} Disadvantages include lack of git-driven sync and exclusion from history. Advantages include ease of implementation. Number two. Store tags of a hypha named foo in foo.mycotags. Tag operations become part of history and git, which is good. It's ugly though. Number three. Make tags a type of hypha (alongside media and textual, and, perhaps, possibly, hypothetical future user hyphae) and store what other hyphae are tagged with this tag in I find the third approach the most Mycorrhizal. |
InterfaceHTTP
UITwo ideas. Place tags in the main area or in a new sidebar placed to the left. Since the main area is already packed full, the second option seems to be better. We could place tags vertically there. If you have JS enabled, you should be able to modify tags without page reload and, perhaps, with auto-completion (how?). A possible arrangement:
|
See https://mycorrhiza.lesarbr.es/hypha/idea/tags to see the three tag proposals. We'll go with the third one. |
While writing some tag-related code, a revelation has come to me. This feature should be called categories, not tags.
|
Categories have been implemented, localized and documented and will be part of the April release |
Turns out, we need tags.
Tags should not be part of Mycomarkup. There will not be a
tags {}
element.The text was updated successfully, but these errors were encountered: