Version bump.

[elpher.git] / ISSUES.org

diff --git a/ISSUES.org b/ISSUES.org
index 2b637c0..6a9d666 100644 (file)
--- a/ISSUES.org
+++ b/ISSUES.org
@@ -1,7 +1,77 @@
 #+TITLE: Development notes/ideas
 #+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.
+
+The fix is just to zero out the history list in the `elpher` function just as
+`elpher-current-page` is cleared.

 
 

-* Enhancements
+* Open Enhancements

 
 ** OPEN Allow multiple elpher buffers [33%]
 
 
 ** OPEN Allow multiple elpher buffers [33%]
 


@@ -14,11 +84,6 @@ this can happen:
 - [X] shift history out of node tree and into separate stack
 - [ ] make history stack variables buffer-local
 - [ ] have elpher-with-clean-buffer select appropriate buffer 
 - [X] shift history out of node tree and into separate stack
 - [ ] make history stack variables buffer-local
 - [ ] have elpher-with-clean-buffer select appropriate buffer 

-   
-** OPEN Remove "redraw" command
-This is only necessary for returning from displaying the raw
-server response.  If I can provide a better way of doing that
-then we can get rid of redraw entirely.

 
 ** OPEN Replace support for user-specified starting pages
 This used to be available, but was removed during a refactor.
 
 ** OPEN Replace support for user-specified starting pages
 This used to be available, but was removed during a refactor.


@@ -30,6 +95,26 @@ the bookmark page are available everywhere else.  But
 expanding and collapsing bookmark groups sounds like it
 might need more specific bindings.
 
 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:
 ** OPEN Implement Gemini support [88%]
    
 Here is the checklist of features required before release:


@@ -46,9 +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.
 
 The last few will be made infinitely easier if we factor the
 gopher "getter" code differently.
 

-* Bugs
+** OPEN Add history browsing

 
 

-* Completed improvements
+* Closed Enhancements

   
 ** CLOSED Turn on lexical scoping
 
   
 ** CLOSED Turn on lexical scoping
 


@@ -108,33 +193,29 @@ do, but will process the URL to do it.
 This also means that non-gopher URLs will be explicitly represented
 as such: no more abusing the "h" type for these.
 
 This also means that non-gopher URLs will be explicitly represented
 as such: no more abusing the "h" type for these.
 

-* 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.
+** INVALID Remove "redraw" command
+This is only necessary for returning from displaying the raw
+server response.  If I can provide a better way of doing that
+then we can get rid of redraw entirely.

 
 

-Update: changed all default faces to inherit from font-lock and basic faces.
+Actually, this command can be useful to correct rendering issues that
+occasionally pop up in termal windows.  Lets leave it for now.

 
 

-** 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.