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