Speed up rendering of large gemini pages.
[elpher.git] / ISSUES.org
index 6a9d666..9923820 100644 (file)
@@ -1,9 +1,28 @@
-#+TITLE: Development notes/ideas
+#+TITLE: Issues and Dev Notes
 #+TODO: OPEN(o!) | CLOSED(c!) INVALID(i@)
 #+STARTUP: logdrawer
    
 * Open Bugs
 
+** OPEN Sanitize certificate names
+   :LOGBOOK:
+   - State "OPEN"       from              [2020-06-22 Mon 10:32]
+   :END:
+   
+Currently things will break in undefined ways if a name is specified
+that contains path separators and probably other characters that I
+haven't thought of.  This is dangerously unacceptable and needs to be
+fixed right away.
+
+** OPEN Set timer after creating network process
+
+While the current order is necessary for synchronous socks
+connections, it is unecessary for regular connections which have the
+no-wait flag set.  Furthermore, for these connections, having the
+timer fire up early means that it interferes with requests for
+user interaction that may appear during the initial connection setup.
+E.g., asking for approval of uknown TLS certificates.
+
 * Closed Bugs
   
 ** CLOSED Org mode faces are not present in recent emacs versions
@@ -87,51 +106,16 @@ this can happen:
 
 ** OPEN Replace support for user-specified starting pages
 This used to be available, but was removed during a refactor.
-
-** OPEN Allow for grouping of bookmarks
-To support this I'd like to add a bookmark page specific
-set of keybindings.  Currently all bindings available on
-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:
-- [X] basic genimi transactions
-- [ ] gemini transactions requiring client certificates
-- [X] gemini input handling
-- [X] gemini map files (text/gemini)
-- [X] Support for plain text responses (text/*)
-- [X] Support for image responses (text/image)
-- [X] Support for mime-specified character encodeing
-- [X] Saving responses to disk
-- [X] Viewing raw responses
-  
-The last few will be made infinitely easier if we factor the
-gopher "getter" code differently.
+** OPEN Make installing existing certificates easier
+   :LOGBOOK:
+   - State "OPEN"       from "CLOSED"     [2020-06-22 Mon 10:34]
+   :END:
 
-** OPEN Add history browsing
+It's naive to think that people don't have client certificates created
+outside of elpher. Thus we need some easy way to "install" these
+certificates, either by copying them or by referencing them in some
+way.
 
 * Closed Enhancements
   
@@ -219,3 +203,77 @@ occasionally pop up in termal windows.  Lets leave it for now.
    cursor.
 
    A small amount of feedback could help with this.
+
+** CLOSED Implement Gemini support [100%]
+   :LOGBOOK:
+   - State "CLOSED"     from "OPEN"       [2020-06-20 Sat 22:32]
+   :END:
+   
+Here is the checklist of features required before release:
+- [X] basic genimi transactions
+- [X] gemini transactions requiring client certificates
+- [X] gemini input handling
+- [X] gemini map files (text/gemini)
+- [X] Support for plain text responses (text/*)
+- [X] Support for image responses (text/image)
+- [X] Support for mime-specified character encodeing
+- [X] Saving responses to disk
+- [X] Viewing raw responses
+  
+The last few will be made infinitely easier if we factor the
+gopher "getter" code differently.
+
+
+** INVALID Allow for grouping of bookmarks
+:LOGBOOK:
+- State "INVALID"    from              [2021-07-23 Fri 10:10] \\
+  Since switching to Emacs native bookmarks, this is no longer our concern.
+:END:
+To support this I'd like to add a bookmark page specific
+set of keybindings.  Currently all bindings available on
+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.
+
+
+** CLOSED Add history browsing
+:LOGBOOK:
+- State "CLOSED"     from "OPEN"       [2021-07-23 Fri 10:09]
+:END:
+
+** CLOSED Improve gemeini rendering speed
+:LOGBOOK:
+- State "CLOSED"     from "OPEN"       [2021-07-31 Sat 00:18]
+:END:
+
+Currently pages with many links render extremely slowly.
+
+Example (>2000 links, 15s): gemini://rawtext.club/~sloum/geminilist/
+
+It turns out that by far the main contributor to this is the use of
+(url-port) in elpher-address-from-gemini-url.  I encountered this
+problem once before in elpher-remove-redundant-ports.  This function
+call is just incredibly slow for some bizarre reason.  Happily,
+(url-portspec) is functionally equivalent and is orders of magnitude
+faster.  With this replacement, loading the above page takes ~2s
+and there aren't any other hotspots.