Bumped priority of bookmark grouping.

diff --git a/ISSUES.org b/ISSUES.org
index a4e9f6e..6a9d666 100644 (file)
--- a/ISSUES.org
+++ b/ISSUES.org
@@ -1,5 +1,6 @@
 #+TITLE: Development notes/ideas
 #+TITLE: Development notes/ideas

-#+TODO: OPEN | CLOSED INVALID
+#+TODO: OPEN(o!) | CLOSED(c!) INVALID(i@)
+#+STARTUP: logdrawer

    
 * Open Bugs
 
    
 * Open Bugs
 


@@ -94,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: