1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
-
-
-
-
|
# libfossil Notable TODOs
This page gives a high-level overview of the notable TODOs, or perceived TODOs, as well as non-TODOs (topics/APIs which are either out of scope or are way, way down the line).
# Core SCM (and closely adjacent) Features
In no particular order:
- **file rename/move** analog to fossil's `mv` command.
- **Double-check crosslinking of other types** and make sure that we are not missing newly-added features.
|
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
-
-
-
-
|
- **Stop using char as booleans**. This tree historically uses `char` type for booleans. Now that the tree is C99, we can switch to the `bool` type. This is ongoing.
- **f-vdiff**: port in [](fossil:3504672187af59f0) in order to be able to select the diff width based on the terminal size.
- **f-vdiff**/dibu: port the DELETE/INSERT collapsing from [](8752aca1b7187d39) into the ncurses unified diff view.
- **fsl_buffer**: add an (int errCode) member. If any operation fails, set that code. (Almost) any fsl_buffer_xyz() API calls should check that value and simply return
it if it's non-0. The benefit of this is that we can then perform any number of fsl_buffer API calls in a row and defer the error check until the end, greatly simplifying much
of the error checking related to that class (of which we have no small amount). This idea is adapted from the [sqlite3 string buffer API](https://sqlite.org/c3ref/str_append.html).
The error code would be sticky, preventing most buffer APIs from working, until it's explicitly reset to 0.
|
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
-
+
|
- This set of features hovers *right on the edge* of out-of-scope for the core libfossil. Rendering is necessarily output-format-specific and the library has no business defining such outputs. Also...
- The fossil implementations of these are not written with port-friendliness in mind, so a complete reimplementation would possibly be necessary.
- In order to support near-arbitrary applications the wiki parsers need to be implemented in such a way that clients can customize (via hooks/callbacks) how links/references are generated.
- The venerable Fossil Wiki format has the lowest priority. In practice markdown has easily taken the lead, and only old (pre-markdown) docs tend to be maintained in that format.
- The venerable Fossil Wiki format has the lowest priority. In practice markdown has easily taken the lead, and only old (pre-markdown) docs tend to be maintained in that format. However... checkin comments support a mime-type but several fossil(1) internals assume fossil-wiki format for those and we have 15+ years of checkin history in the wild which relies on that, so there is no real escaping from that format.
# Non-TODOs
- **Any and all UI-related elements**, including HTML, CSS, and JavaScript. The library will enable such applications but will not provide, e.g., an HTML framework beyond *perhaps* (maybe) diff and/or wiki rendering (the former being likely but the latter unlikely).
- **Scripting of tickets**. There are no current plans to 100% mimic fossil's TH1 scripting of tickets. Fossil's use of TH1 was one of convenience, not long-term practicality. The library itself will have no "official" scripting language, but is designed specifically to make tying it to scripting engines relatively straightforward. We have a standalone copy of TH1 which "could" be integrated with little work, but doing so would not be an ideal path to go down.
|