X-Git-Url: https://thelambdalab.xyz/gitweb/index.cgi?p=elpher.git;a=blobdiff_plain;f=ISSUES.org;h=6a9d6669d0375dd2bafaeec464860ea4af61310d;hp=462478632c4e2bdc72efce37a66cdb27ca73ed72;hb=14dbac775058d49adb12cb4ad093d567ea80394b;hpb=a29c98cf4d17b09060d923f2e9e2510563027c7a diff --git a/ISSUES.org b/ISSUES.org index 4624786..6a9d666 100644 --- a/ISSUES.org +++ b/ISSUES.org @@ -1,7 +1,77 @@ #+TITLE: Development notes/ideas -#+TODO: OPEN | CLOSED INVALID +#+TODO: OPEN(o!) | CLOSED(c!) INVALID(i@) +#+STARTUP: logdrawer + +* Open Bugs + +* Closed Bugs + +** CLOSED Org mode faces are not present in recent emacs versions +Even 26.1 doesn't seem to have these. This means that, for many +users, elpher doesn't show any difference between any of the +item types. Not a major problem at all, but the faces we inherit +from should definitely be ones which have been present for much +longer. Perhaps the font lock mode faces are the way to go after +all. + +Update: changed all default faces to inherit from font-lock and basic faces. + +** CLOSED URL-centric addressing breaks bookmark file compatibility + +Need a way to allow people to rescue their old bookmark files +following this update. + +** CLOSED History loops <2019-11-08 Fri> + +Occasionally elpher gets stuck in a "history loop" where a +node is its own grandparent. Obviously this sucks, as history +is elpher's main mechanism for making gopherspace exploration +painless. + +I suspect the problem is in either ~elpher-visit-node~ or +~elpher-visit-parent~. + +Follow-up: this has been fixed by the new stack-based history system +in 2.5. + + +** CLOSED Redirects do not rewrite current address + +This is a bug, as gemini://blah.com/hi may get redirected +to gemini://blah.com/hi/, at which point link lines +of the form "=> there" should be interpreted as pointing +at gemini://blah.com/hi/there, while currently they are +interpreted as pointing at gemini://blah.com/there. + +** CLOSED History inconsistency when restarting elpher <2020-05-26 Tue> + +To reproduce: +1. open elpher and follow a few links until you're a handful of links below + the start page. +2. kill the elpher buffer with C-x k +3. Open elpher again, which will show the start page. +4. Press 'u' to go up. Elpher wiill respond stating that there is no previous page. +5. Press 'u' again. Elpher will then jump to the page that was open when + the buffer was originally killed. + +Expected behaviour: elpher should be once again at the bottom of the history +stack and should not remember the previous history. + +Observed behaviour: elpher _does_ remember the previous history. + +*** update <2020-05-27 Wed> +Turns out this was just because the `elpher` function was merely setting +the `elpher-current-page` variable to nil, then using `elpher-visit-page` +to visit the start page, resulting in the nil being pushed onto the existing +history stack. Because `elpher-visit-previous-page` always trys to pop from +this stack and tests whether the result is nil (which it is when the stack is empty), +the first "u" would result in the "no previous page" message but would still +pop the stack, meaning that subsequent "u" commands would succeed. -* Enhancements +The fix is just to zero out the history list in the `elpher` function just as +`elpher-current-page` is cleared. + +* Open Enhancements ** OPEN Allow multiple elpher buffers [33%] @@ -25,6 +95,26 @@ the bookmark page are available everywhere else. But expanding and collapsing bookmark groups sounds like it might need more specific bindings. +*** Priority bump <2020-05-31 Sun> + +As bookmark lists grow, some sort of grouping is becoming more and more +important. Furthermore, with this in place it would become feasible +(and I really suspect almost trivial) to implement an update-checking +system for chosen groups of bookmarks. + +For instance, we could prefetch content for each of the addresses within +a chosen group, indicating which had been changed since the last fetch. +(We could just store hashes of earlier content to detect changes.) + +The difficult thing to decide is how the UI for the new bookmark page +will work. It already has its own renderer, and we could easily stop +using the gopher directory line renderer in favour of something more +amenable to displaying the group information. Thus we're very free to +do whatever we like once we also have a special key map in place as well. + +I guess I need to look into what native widgets Emacs has for displaying +collapsable hierarchies. + ** OPEN Implement Gemini support [88%] Here is the checklist of features required before release: @@ -41,13 +131,9 @@ Here is the checklist of features required before release: The last few will be made infinitely easier if we factor the gopher "getter" code differently. -** OPEN Implement Finger support - ** OPEN Add history browsing -* Bugs - -* Completed improvements +* Closed Enhancements ** CLOSED Turn on lexical scoping @@ -115,33 +201,21 @@ then we can get rid of redraw entirely. Actually, this command can be useful to correct rendering issues that occasionally pop up in termal windows. Lets leave it for now. -* Closed issues - -** CLOSED Org mode faces are not present in recent emacs versions -Even 26.1 doesn't seem to have these. This means that, for many -users, elpher doesn't show any difference between any of the -item types. Not a major problem at all, but the faces we inherit -from should definitely be ones which have been present for much -longer. Perhaps the font lock mode faces are the way to go after -all. - -Update: changed all default faces to inherit from font-lock and basic faces. - -** CLOSED URL-centric addressing breaks bookmark file compatibility +** CLOSED Implement Finger support -Need a way to allow people to rescue their old bookmark files -following this update. - -** CLOSED History loops <2019-11-08 Fri> - -Occasionally elpher gets stuck in a "history loop" where a -node is its own grandparent. Obviously this sucks, as history -is elpher's main mechanism for making gopherspace exploration -painless. - -I suspect the problem is in either ~elpher-visit-node~ or -~elpher-visit-parent~. - -Follow-up: this has been fixed by the new stack-based history system -in 2.5. +** CLOSED Improve download performance + This is actually easy to fix - the major problem at the moment is + the braindead way the incrementally-retrieved data is recorded: + (setq result-string (concat result-string next-bit)). + This is O(N^2). Yuck! + + Okay, replacing this really does improve things. Large gemini + downloads now seem occur at rates I'd expect. + +** CLOSED Download/rendering progress feedback + Particularly for large files or complicated pages, elpher can + take a few seconds or more to generate a response. Thhis is + frustrating for users, who are left staring at a blinking + cursor. + A small amount of feedback could help with this.