1 #+TITLE: Development notes/ideas
2 #+TODO: OPEN(o!) | CLOSED(c!) INVALID(i@)
9 ** CLOSED Org mode faces are not present in recent emacs versions
10 Even 26.1 doesn't seem to have these. This means that, for many
11 users, elpher doesn't show any difference between any of the
12 item types. Not a major problem at all, but the faces we inherit
13 from should definitely be ones which have been present for much
14 longer. Perhaps the font lock mode faces are the way to go after
17 Update: changed all default faces to inherit from font-lock and basic faces.
19 ** CLOSED URL-centric addressing breaks bookmark file compatibility
21 Need a way to allow people to rescue their old bookmark files
22 following this update.
24 ** CLOSED History loops <2019-11-08 Fri>
26 Occasionally elpher gets stuck in a "history loop" where a
27 node is its own grandparent. Obviously this sucks, as history
28 is elpher's main mechanism for making gopherspace exploration
31 I suspect the problem is in either ~elpher-visit-node~ or
32 ~elpher-visit-parent~.
34 Follow-up: this has been fixed by the new stack-based history system
38 ** CLOSED Redirects do not rewrite current address
40 This is a bug, as gemini://blah.com/hi may get redirected
41 to gemini://blah.com/hi/, at which point link lines
42 of the form "=> there" should be interpreted as pointing
43 at gemini://blah.com/hi/there, while currently they are
44 interpreted as pointing at gemini://blah.com/there.
46 ** CLOSED History inconsistency when restarting elpher <2020-05-26 Tue>
49 1. open elpher and follow a few links until you're a handful of links below
51 2. kill the elpher buffer with C-x k
52 3. Open elpher again, which will show the start page.
53 4. Press 'u' to go up. Elpher wiill respond stating that there is no previous page.
54 5. Press 'u' again. Elpher will then jump to the page that was open when
55 the buffer was originally killed.
57 Expected behaviour: elpher should be once again at the bottom of the history
58 stack and should not remember the previous history.
60 Observed behaviour: elpher _does_ remember the previous history.
62 *** update <2020-05-27 Wed>
63 Turns out this was just because the `elpher` function was merely setting
64 the `elpher-current-page` variable to nil, then using `elpher-visit-page`
65 to visit the start page, resulting in the nil being pushed onto the existing
66 history stack. Because `elpher-visit-previous-page` always trys to pop from
67 this stack and tests whether the result is nil (which it is when the stack is empty),
68 the first "u" would result in the "no previous page" message but would still
69 pop the stack, meaning that subsequent "u" commands would succeed.
71 The fix is just to zero out the history list in the `elpher` function just as
72 `elpher-current-page` is cleared.
76 ** OPEN Allow multiple elpher buffers [33%]
78 Shouldn't be too hard, just need elpher-current-node to be
79 buffer-local and allow various buffer-switching procedures to
80 do something sensible.
82 Here are the things that need to be implemented before
84 - [X] shift history out of node tree and into separate stack
85 - [ ] make history stack variables buffer-local
86 - [ ] have elpher-with-clean-buffer select appropriate buffer
88 ** OPEN Replace support for user-specified starting pages
89 This used to be available, but was removed during a refactor.
91 ** OPEN Allow for grouping of bookmarks
92 To support this I'd like to add a bookmark page specific
93 set of keybindings. Currently all bindings available on
94 the bookmark page are available everywhere else. But
95 expanding and collapsing bookmark groups sounds like it
96 might need more specific bindings.
98 *** Priority bump <2020-05-31 Sun>
100 As bookmark lists grow, some sort of grouping is becoming more and more
101 important. Furthermore, with this in place it would become feasible
102 (and I really suspect almost trivial) to implement an update-checking
103 system for chosen groups of bookmarks.
105 For instance, we could prefetch content for each of the addresses within
106 a chosen group, indicating which had been changed since the last fetch.
107 (We could just store hashes of earlier content to detect changes.)
109 The difficult thing to decide is how the UI for the new bookmark page
110 will work. It already has its own renderer, and we could easily stop
111 using the gopher directory line renderer in favour of something more
112 amenable to displaying the group information. Thus we're very free to
113 do whatever we like once we also have a special key map in place as well.
115 I guess I need to look into what native widgets Emacs has for displaying
116 collapsable hierarchies.
118 ** OPEN Implement Gemini support [88%]
120 Here is the checklist of features required before release:
121 - [X] basic genimi transactions
122 - [ ] gemini transactions requiring client certificates
123 - [X] gemini input handling
124 - [X] gemini map files (text/gemini)
125 - [X] Support for plain text responses (text/*)
126 - [X] Support for image responses (text/image)
127 - [X] Support for mime-specified character encodeing
128 - [X] Saving responses to disk
129 - [X] Viewing raw responses
131 The last few will be made infinitely easier if we factor the
132 gopher "getter" code differently.
134 ** OPEN Add history browsing
136 * Closed Enhancements
138 ** CLOSED Turn on lexical scoping
140 A branch exists for this, but there are some compilation kinks
144 ** CLOSED Implement support for telnet entries
146 Similar to http entries, telnet entries will be handled by code
147 external to elpher. However it seems I made http entry handling a
148 special case, and I don't want another! So the only option is to
149 bring both http and telnet entries back into the fold by representing
150 them both as standard nodes and having the grunt work done by getter
153 ** CLOSED Allow users to access selected and current node details.
155 ** CLOSED Implement bookmark system
157 Currently the bookmark page replaces the current page, and it
158 does so silently (i.e. it doesn't become part of the link hierarchy).
159 I think this is a mistake, as it results in confusing behaviour when
160 traversing the link hierarchy after visiting one of the bookmarked links.
162 Instead, I think I should
163 1. Make the bookmark page part of the hierarchy, and
164 2. Reinstate the visited node hash table to avoid excess link hierarchy pollution.
166 In order to accomplish 1. it will be necessary to make the bookmark page renderer
167 a proper getter function, and one that never caches the contents of the buffer.
169 Actually, I might have to think about that a bit more. I don't know
170 how to answer the question of what the best thing to do with node
171 parent links when using a cached node in place of a new node. (Maybe
172 I always update node.parent unless parent is already an ancestor of
176 ** CLOSED Support character encoding diversity
178 ** CLOSED Make URLs the basic address type.
179 Currently I waste a lot of effort converting between
180 URL and non-URL representations. This is unnecessary, and
181 actually makes lots of things uglier.
183 For example, the bookmarks file contains addresses in Elpher's
184 internal representation, whereas I expect users would prefer
187 So the idea would be for (elpher-node-address node) to be
188 a either a string or a symbol, with symbols used for "special"
189 pages (bookmarks, start page, etc). The getter functions
190 `elpher-address-selector' etc will still do what they currently
191 do, but will process the URL to do it.
193 This also means that non-gopher URLs will be explicitly represented
194 as such: no more abusing the "h" type for these.
196 ** INVALID Remove "redraw" command
197 This is only necessary for returning from displaying the raw
198 server response. If I can provide a better way of doing that
199 then we can get rid of redraw entirely.
201 Actually, this command can be useful to correct rendering issues that
202 occasionally pop up in termal windows. Lets leave it for now.
204 ** CLOSED Implement Finger support
206 ** CLOSED Improve download performance
207 This is actually easy to fix - the major problem at the moment is
208 the braindead way the incrementally-retrieved data is recorded:
209 (setq result-string (concat result-string next-bit)).
210 This is O(N^2). Yuck!
212 Okay, replacing this really does improve things. Large gemini
213 downloads now seem occur at rates I'd expect.
215 ** CLOSED Download/rendering progress feedback
216 Particularly for large files or complicated pages, elpher can
217 take a few seconds or more to generate a response. Thhis is
218 frustrating for users, who are left staring at a blinking
221 A small amount of feedback could help with this.