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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
# TODO
Make it perphekd!
## Do these
FIXME: If there's a single word and period at the beginning of a line, it gets turned into a list, or list item by lunamark at the final Parse stage.
Automate symlinks.
- any .md.md file should be linked along with it's matching .md file if it's outside of Foswiki/ and PmWiki/.
Other colour shenanigans.
TOC
- Maybe have it on the left, as the sub menu of the current page's menu item, automatically generated from the $body$ headings.
- Sub headings get sub menus etc.
Check the timestamps on the files, only update if source is newer than destination. Meh, it's already 600 times faster than the pandoc version.
- One quirk to watch for is if a URL path changes, the docs that have that URL need to be redone.
- pandoc is a lot slower though, so do this for sure when dealing with that.
- When scraping the web sites, they tend to be dynamically generated with no useful timestamp on them.
- The web site scrape happens locally anyway, I can compare source file timestamps.
Add atom feed for single page. Alas cgit only seems to have ATOM feed on the whole repo, not individual files.
- git.devuan.org might have usable per page history.
- However, once timestamps are sorted, I can use that code to generate (static?) RSS and ATOM feeds, and create page histories using diffs.
Deal with complex directory trees.
- /testing/even should display as even/deeper on the testing page, coz even/ has no files, but even/deeper does.
- On the other hand, I could just create an empty page with the sub directories shown as usual.
- Scanning /usr/share/doc on my super desktop with looots of software installed will be fun.
- On the gripping hand, this is where we want empty directories to vanish.
- SOOOOOOO don't show empty directories, but show their subs that have content, even if that sub is deep, but as per usual stop once we find a sub on that branch. EEEEW branches.
## Some ideas
Mostly from something chomwitt deleted.
- A toolbar is mentioned, which is what I'm half way through creating with those hamburger / sunglasses icons, they are a bar of tools.
- Maybe tabs as well as a toolbar, for the list of sub directories.
- Syntax highlighting in code blocks.
- Allow default.template files in sub directories.
- Might be useful to automatically convert anything looking like a URL into a linky.
- "collapsing headings" I guess that means click on a heading to hide / show the content under that heading.
- + Should do that for the main content and the menu TOC.
- "validation", not sure exactly what that would validate.
- I'll just quote the entire rest -
~~~
!!! co-editing
The toolbar should contain tools that facilitate :
* intergration (to other workflows)
** for example search-completion to other workflows names-tags.
~~~
## Try out
htmx
cgit has Lua
## User system
Reuse the user system from SledjChisl.
levels -
- everyone
- banned
- reader
- member
- moderator
- editor
- admin
- shell
- root
Everyone can read the pages, no need for an account.
Banned people can't do squat, except maybe pester an admin once to start the unbanning process.
When first registered, accounts are set to reader level.
Initial verification by email.
Readers can only edit their own profile.
If an existing member vouches for a reader, they get promoted to member.
Some invite system would count is vouching, but need to get secure invite credentials to someone outside the system.
Members can chat, and create their own sandboxes that might get promoted by editors / moderators to proper content.
Moderators can move things around, including to a spam/trash place. They can ban readers and members.
Editors can edit any content, and move things around. They can't edit the site elements itself.
So they can edit the site menu and structure of the content, but not the footer?
Certainly can't edit any admin stuff.
Admins are set by other admins.
Admins can promote / demote people and content at any time.
Admins can edit anything, including web editing of config files, and managing of modules.
shell level means you have direct access to the files that are the web
site, including configuration and modules. Likely this is the person
that set the system up in the first place.
Admin should have access to everything that shell level has, but there's always things need tweaking at some lower level.
Built in file browser might do the trick. Would be useful for content creators to to organise the content. Naturally should obey the permissions.
root level is whoever controls the server things are running on. They can do anything at all.
|
