You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to be able to have a directory or directories related to topics. They would be empty by default like "/repos." The repo.md for a particular repo would have links in to topics that are tagged for the project.
Some thought needs to go into how to handle paging. A topic could be a single file or a directory with files in it.
With a single file, it could be infinitely scrolling but then most text editors probably won't handle it well even if a pager or the plan9 command line might. The file could be writable, which would provide the trigger for the next page, but there are no universal reload semantics.
A topic could be two files. One for the content and another "control" file to expand its size. The workflow wouldn't be too dissimilar from the issue filters workflow with the issues file. The user needs to know to reload the content file after touching the control file.
Alternatively, a topic could be a directory with a control file exactly like the issue.
Another option is to divide pages for a topic among different incrementing page files. Open the first "001.md" and it shows the first page, "002.md" for the second, etc. "cat *.md | more" on the directory will give you a single page. Editors open one at a time with a link to the next at the bottom.
The text was updated successfully, but these errors were encountered:
It would be great to be able to have a directory or directories related to topics. They would be empty by default like "/repos." The repo.md for a particular repo would have links in to topics that are tagged for the project.
Some thought needs to go into how to handle paging. A topic could be a single file or a directory with files in it.
With a single file, it could be infinitely scrolling but then most text editors probably won't handle it well even if a pager or the plan9 command line might. The file could be writable, which would provide the trigger for the next page, but there are no universal reload semantics.
A topic could be two files. One for the content and another "control" file to expand its size. The workflow wouldn't be too dissimilar from the issue filters workflow with the issues file. The user needs to know to reload the content file after touching the control file.
Alternatively, a topic could be a directory with a control file exactly like the issue.
Another option is to divide pages for a topic among different incrementing page files. Open the first "001.md" and it shows the first page, "002.md" for the second, etc. "cat *.md | more" on the directory will give you a single page. Editors open one at a time with a link to the next at the bottom.
The text was updated successfully, but these errors were encountered: