1 #+TITLE: Development notes/ideas
2 #+TODO: OPEN | CLOSED INVALID
6 ** OPEN Allow multiple elpher buffers [33%]
8 Shouldn't be too hard, just need elpher-current-node to be
9 buffer-local and allow various buffer-switching procedures to
10 do something sensible.
12 Here are the things that need to be implemented before
14 - [X] shift history out of node tree and into separate stack
15 - [ ] make history stack variables buffer-local
16 - [ ] have elpher-with-clean-buffer select appropriate buffer
18 ** OPEN Replace support for user-specified starting pages
19 This used to be available, but was removed during a refactor.
21 ** OPEN Allow for grouping of bookmarks
22 To support this I'd like to add a bookmark page specific
23 set of keybindings. Currently all bindings available on
24 the bookmark page are available everywhere else. But
25 expanding and collapsing bookmark groups sounds like it
26 might need more specific bindings.
28 ** OPEN Implement Gemini support [88%]
30 Here is the checklist of features required before release:
31 - [X] basic genimi transactions
32 - [ ] gemini transactions requiring client certificates
33 - [X] gemini input handling
34 - [X] gemini map files (text/gemini)
35 - [X] Support for plain text responses (text/*)
36 - [X] Support for image responses (text/image)
37 - [X] Support for mime-specified character encodeing
38 - [X] Saving responses to disk
39 - [X] Viewing raw responses
41 The last few will be made infinitely easier if we factor the
42 gopher "getter" code differently.
45 ** OPEN Add history browsing
47 ** OPEN Download/rendering progress feedback
48 Particularly for large files or complicated pages, elpher can
49 take a few seconds or more to generate a response. Thhis is
50 frustrating for users, who are left staring at a blinking
53 A small amount of feedback could help with this.
57 * Completed improvements
59 ** CLOSED Turn on lexical scoping
61 A branch exists for this, but there are some compilation kinks
65 ** CLOSED Implement support for telnet entries
67 Similar to http entries, telnet entries will be handled by code
68 external to elpher. However it seems I made http entry handling a
69 special case, and I don't want another! So the only option is to
70 bring both http and telnet entries back into the fold by representing
71 them both as standard nodes and having the grunt work done by getter
74 ** CLOSED Allow users to access selected and current node details.
76 ** CLOSED Implement bookmark system
78 Currently the bookmark page replaces the current page, and it
79 does so silently (i.e. it doesn't become part of the link hierarchy).
80 I think this is a mistake, as it results in confusing behaviour when
81 traversing the link hierarchy after visiting one of the bookmarked links.
83 Instead, I think I should
84 1. Make the bookmark page part of the hierarchy, and
85 2. Reinstate the visited node hash table to avoid excess link hierarchy pollution.
87 In order to accomplish 1. it will be necessary to make the bookmark page renderer
88 a proper getter function, and one that never caches the contents of the buffer.
90 Actually, I might have to think about that a bit more. I don't know
91 how to answer the question of what the best thing to do with node
92 parent links when using a cached node in place of a new node. (Maybe
93 I always update node.parent unless parent is already an ancestor of
97 ** CLOSED Support character encoding diversity
99 ** CLOSED Make URLs the basic address type.
100 Currently I waste a lot of effort converting between
101 URL and non-URL representations. This is unnecessary, and
102 actually makes lots of things uglier.
104 For example, the bookmarks file contains addresses in Elpher's
105 internal representation, whereas I expect users would prefer
108 So the idea would be for (elpher-node-address node) to be
109 a either a string or a symbol, with symbols used for "special"
110 pages (bookmarks, start page, etc). The getter functions
111 `elpher-address-selector' etc will still do what they currently
112 do, but will process the URL to do it.
114 This also means that non-gopher URLs will be explicitly represented
115 as such: no more abusing the "h" type for these.
117 ** INVALID Remove "redraw" command
118 This is only necessary for returning from displaying the raw
119 server response. If I can provide a better way of doing that
120 then we can get rid of redraw entirely.
122 Actually, this command can be useful to correct rendering issues that
123 occasionally pop up in termal windows. Lets leave it for now.
125 ** CLOSED Implement Finger support
127 ** CLOSED Improve download performance
128 This is actually easy to fix - the major problem at the moment is
129 the braindead way the incrementally-retrieved data is recorded:
130 (setq result-string (concat result-string next-bit)).
131 This is O(N^2). Yuck!
133 Okay, replacing this really does improve things. Large gemini
134 downloads now seem occur at rates I'd expect.
138 ** CLOSED Org mode faces are not present in recent emacs versions
139 Even 26.1 doesn't seem to have these. This means that, for many
140 users, elpher doesn't show any difference between any of the
141 item types. Not a major problem at all, but the faces we inherit
142 from should definitely be ones which have been present for much
143 longer. Perhaps the font lock mode faces are the way to go after
146 Update: changed all default faces to inherit from font-lock and basic faces.
148 ** CLOSED URL-centric addressing breaks bookmark file compatibility
150 Need a way to allow people to rescue their old bookmark files
151 following this update.
153 ** CLOSED History loops <2019-11-08 Fri>
155 Occasionally elpher gets stuck in a "history loop" where a
156 node is its own grandparent. Obviously this sucks, as history
157 is elpher's main mechanism for making gopherspace exploration
160 I suspect the problem is in either ~elpher-visit-node~ or
161 ~elpher-visit-parent~.
163 Follow-up: this has been fixed by the new stack-based history system
167 ** CLOSED Redirects do not rewrite current address
169 This is a bug, as gemini://blah.com/hi may get redirected
170 to gemini://blah.com/hi/, at which point link lines
171 of the form "=> there" should be interpreted as pointing
172 at gemini://blah.com/hi/there, while currently they are
173 interpreted as pointing at gemini://blah.com/there.