1 #+TITLE: Issues and Dev Notes
2 #+TODO: OPEN(o!) | CLOSED(c!) INVALID(i@)
7 ** OPEN Sanitize certificate names
9 - State "OPEN" from [2020-06-22 Mon 10:32]
12 Currently things will break in undefined ways if a name is specified
13 that contains path separators and probably other characters that I
14 haven't thought of. This is dangerously unacceptable and needs to be
17 ** OPEN Set timer after creating network process
19 While the current order is necessary for synchronous socks
20 connections, it is unecessary for regular connections which have the
21 no-wait flag set. Furthermore, for these connections, having the
22 timer fire up early means that it interferes with requests for
23 user interaction that may appear during the initial connection setup.
24 E.g., asking for approval of uknown TLS certificates.
28 ** CLOSED Relative Gemini links processed improperly
30 - State "CLOSED" from "OPEN" [2021-08-04 Wed 15:54]
31 - State "OPEN" from [2021-08-04 Wed 13:53]
34 Skyjake's gemlog at gemini://skyjake.fi/gemlog/ demonstrate's the
35 issue. The link back to the root selector in the footer of that page
36 is a relative link to the parent directory, i.e. "..". For some
37 reason elpher combines this with the current URL and produces
38 "gemini://skyjake.fi" as the destination of the link. Such URLs
39 (i.e. without a filename) are allowed as input, but are assumed
40 to not appear internally.
42 To see why the internal distinction is important, consider a page
43 where the current URL is gemini://example.com/a_page. The current
44 directory in this case is "/", meaning a relative link to
45 "another_page" results in a destination link of
46 "gemini://example.com/another_page. On the other hand, if the current
47 URL is gemini://example.com/a_page/, the same relative link is
48 interpreted as refering to gemini://example.com/a_page/another_page.
50 The fix will be to ensure gemini://skyjake.fi/gemlog/.. collapses to
51 gemini://skyjake.fi/ rather than gemini://skyjake.fi.
55 ** CLOSED Org mode faces are not present in recent emacs versions
56 Even 26.1 doesn't seem to have these. This means that, for many
57 users, elpher doesn't show any difference between any of the
58 item types. Not a major problem at all, but the faces we inherit
59 from should definitely be ones which have been present for much
60 longer. Perhaps the font lock mode faces are the way to go after
63 Update: changed all default faces to inherit from font-lock and basic faces.
65 ** CLOSED URL-centric addressing breaks bookmark file compatibility
67 Need a way to allow people to rescue their old bookmark files
68 following this update.
70 ** CLOSED History loops <2019-11-08 Fri>
72 Occasionally elpher gets stuck in a "history loop" where a
73 node is its own grandparent. Obviously this sucks, as history
74 is elpher's main mechanism for making gopherspace exploration
77 I suspect the problem is in either ~elpher-visit-node~ or
78 ~elpher-visit-parent~.
80 Follow-up: this has been fixed by the new stack-based history system
84 ** CLOSED Redirects do not rewrite current address
86 This is a bug, as gemini://blah.com/hi may get redirected
87 to gemini://blah.com/hi/, at which point link lines
88 of the form "=> there" should be interpreted as pointing
89 at gemini://blah.com/hi/there, while currently they are
90 interpreted as pointing at gemini://blah.com/there.
92 ** CLOSED History inconsistency when restarting elpher <2020-05-26 Tue>
95 1. open elpher and follow a few links until you're a handful of links below
97 2. kill the elpher buffer with C-x k
98 3. Open elpher again, which will show the start page.
99 4. Press 'u' to go up. Elpher wiill respond stating that there is no previous page.
100 5. Press 'u' again. Elpher will then jump to the page that was open when
101 the buffer was originally killed.
103 Expected behaviour: elpher should be once again at the bottom of the history
104 stack and should not remember the previous history.
106 Observed behaviour: elpher _does_ remember the previous history.
108 *** update <2020-05-27 Wed>
109 Turns out this was just because the `elpher` function was merely setting
110 the `elpher-current-page` variable to nil, then using `elpher-visit-page`
111 to visit the start page, resulting in the nil being pushed onto the existing
112 history stack. Because `elpher-visit-previous-page` always trys to pop from
113 this stack and tests whether the result is nil (which it is when the stack is empty),
114 the first "u" would result in the "no previous page" message but would still
115 pop the stack, meaning that subsequent "u" commands would succeed.
117 The fix is just to zero out the history list in the `elpher` function just as
118 `elpher-current-page` is cleared.
122 ** OPEN Allow multiple elpher buffers [33%]
124 Shouldn't be too hard, just need elpher-current-node to be
125 buffer-local and allow various buffer-switching procedures to
126 do something sensible.
128 Here are the things that need to be implemented before
130 - [X] shift history out of node tree and into separate stack
131 - [ ] make history stack variables buffer-local
132 - [ ] have elpher-with-clean-buffer select appropriate buffer
134 ** OPEN Replace support for user-specified starting pages
135 This used to be available, but was removed during a refactor.
137 ** OPEN Make installing existing certificates easier
139 - State "OPEN" from "CLOSED" [2020-06-22 Mon 10:34]
142 It's naive to think that people don't have client certificates created
143 outside of elpher. Thus we need some easy way to "install" these
144 certificates, either by copying them or by referencing them in some
147 * Closed Enhancements
149 ** CLOSED Turn on lexical scoping
151 A branch exists for this, but there are some compilation kinks
155 ** CLOSED Implement support for telnet entries
157 Similar to http entries, telnet entries will be handled by code
158 external to elpher. However it seems I made http entry handling a
159 special case, and I don't want another! So the only option is to
160 bring both http and telnet entries back into the fold by representing
161 them both as standard nodes and having the grunt work done by getter
164 ** CLOSED Allow users to access selected and current node details.
166 ** CLOSED Implement bookmark system
168 Currently the bookmark page replaces the current page, and it
169 does so silently (i.e. it doesn't become part of the link hierarchy).
170 I think this is a mistake, as it results in confusing behaviour when
171 traversing the link hierarchy after visiting one of the bookmarked links.
173 Instead, I think I should
174 1. Make the bookmark page part of the hierarchy, and
175 2. Reinstate the visited node hash table to avoid excess link hierarchy pollution.
177 In order to accomplish 1. it will be necessary to make the bookmark page renderer
178 a proper getter function, and one that never caches the contents of the buffer.
180 Actually, I might have to think about that a bit more. I don't know
181 how to answer the question of what the best thing to do with node
182 parent links when using a cached node in place of a new node. (Maybe
183 I always update node.parent unless parent is already an ancestor of
187 ** CLOSED Support character encoding diversity
189 ** CLOSED Make URLs the basic address type.
190 Currently I waste a lot of effort converting between
191 URL and non-URL representations. This is unnecessary, and
192 actually makes lots of things uglier.
194 For example, the bookmarks file contains addresses in Elpher's
195 internal representation, whereas I expect users would prefer
198 So the idea would be for (elpher-node-address node) to be
199 a either a string or a symbol, with symbols used for "special"
200 pages (bookmarks, start page, etc). The getter functions
201 `elpher-address-selector' etc will still do what they currently
202 do, but will process the URL to do it.
204 This also means that non-gopher URLs will be explicitly represented
205 as such: no more abusing the "h" type for these.
207 ** INVALID Remove "redraw" command
208 This is only necessary for returning from displaying the raw
209 server response. If I can provide a better way of doing that
210 then we can get rid of redraw entirely.
212 Actually, this command can be useful to correct rendering issues that
213 occasionally pop up in termal windows. Lets leave it for now.
215 ** CLOSED Implement Finger support
217 ** CLOSED Improve download performance
218 This is actually easy to fix - the major problem at the moment is
219 the braindead way the incrementally-retrieved data is recorded:
220 (setq result-string (concat result-string next-bit)).
221 This is O(N^2). Yuck!
223 Okay, replacing this really does improve things. Large gemini
224 downloads now seem occur at rates I'd expect.
226 ** CLOSED Download/rendering progress feedback
227 Particularly for large files or complicated pages, elpher can
228 take a few seconds or more to generate a response. Thhis is
229 frustrating for users, who are left staring at a blinking
232 A small amount of feedback could help with this.
234 ** CLOSED Implement Gemini support [100%]
236 - State "CLOSED" from "OPEN" [2020-06-20 Sat 22:32]
239 Here is the checklist of features required before release:
240 - [X] basic genimi transactions
241 - [X] gemini transactions requiring client certificates
242 - [X] gemini input handling
243 - [X] gemini map files (text/gemini)
244 - [X] Support for plain text responses (text/*)
245 - [X] Support for image responses (text/image)
246 - [X] Support for mime-specified character encodeing
247 - [X] Saving responses to disk
248 - [X] Viewing raw responses
250 The last few will be made infinitely easier if we factor the
251 gopher "getter" code differently.
254 ** INVALID Allow for grouping of bookmarks
256 - State "INVALID" from [2021-07-23 Fri 10:10] \\
257 Since switching to Emacs native bookmarks, this is no longer our concern.
259 To support this I'd like to add a bookmark page specific
260 set of keybindings. Currently all bindings available on
261 the bookmark page are available everywhere else. But
262 expanding and collapsing bookmark groups sounds like it
263 might need more specific bindings.
265 *** Priority bump <2020-05-31 Sun>
267 As bookmark lists grow, some sort of grouping is becoming more and more
268 important. Furthermore, with this in place it would become feasible
269 (and I really suspect almost trivial) to implement an update-checking
270 system for chosen groups of bookmarks.
272 For instance, we could prefetch content for each of the addresses within
273 a chosen group, indicating which had been changed since the last fetch.
274 (We could just store hashes of earlier content to detect changes.)
276 The difficult thing to decide is how the UI for the new bookmark page
277 will work. It already has its own renderer, and we could easily stop
278 using the gopher directory line renderer in favour of something more
279 amenable to displaying the group information. Thus we're very free to
280 do whatever we like once we also have a special key map in place as well.
282 I guess I need to look into what native widgets Emacs has for displaying
283 collapsable hierarchies.
286 ** CLOSED Add history browsing
288 - State "CLOSED" from "OPEN" [2021-07-23 Fri 10:09]
291 ** CLOSED Improve gemeini rendering speed
293 - State "CLOSED" from "OPEN" [2021-07-31 Sat 00:18]
296 Currently pages with many links render extremely slowly.
298 Example (>2000 links, 15s): gemini://rawtext.club/~sloum/geminilist/
300 It turns out that by far the main contributor to this is the use of
301 (url-port) in elpher-address-from-gemini-url. I encountered this
302 problem once before in elpher-remove-redundant-ports. This function
303 call is just incredibly slow for some bizarre reason. Happily,
304 (url-portspec) is functionally equivalent and is orders of magnitude
305 faster. With this replacement, loading the above page takes ~2s
306 and there aren't any other hotspots.