Sorry, I missed this message. I will read it and respond later this week. Thanks for the ideas. -- Bob
On Thu, Jan 30, 2020 at 3:35 PM <gravityp...@posteo.de> wrote: > Glad it wasn't just me! Cool, glad I could help out! > > Looking back at the user group, you also asked for feature requests, and > I had a couple -- though I'm not sure how feasible any of them are. > > Feature Idea #1: `jump-to-next-button` Command > ============================================== > > This is something that would be nice to have rather than a missing > feature, but > I've often wished there were a command I could bind to a key that would > jump to > the next explicit button in a file -- sort of like how you can tab > between > fields in the Customize interface. I created a macro to do this using > regexes, > but it was kinda... janky. > > Feature Idea #2: Honor styling markup from other modes in Koutline Files > ======================================================================== > > I use the Markdown and Org styling stuff reflexively in other documents > -- it would > probably increase usage if some of those styling options were available > in KOTL > files. Ideally Koutliner could draw the markup handling from an existing > mode > rather than re-implementing every possible markup language -- but that > actually > brings me to... > > Feature Idea #3: Treat Koutliner cells as containers for other content > ====================================================================== > > I haven't used a lot of Koutliner -- despite loving the Augment-style > numbering > -- primarily because it doesn't appear to be compatible with the > document > systems I'm already heavily bought into, like Org and Markdown. Now, it > can > export outlines to Org and Html, and from there I can get it into > something > more familiar, but it feels like there's more opportunity here. > > One of the hugely cool things about Koutliner, and which is missing from > Org, > is the Cell concept. I like the idea of addressable cells that I can > work with > rather than the more loosey-goosey "just add custom ids to each > headline" > approach that Org takes. > > I don't know how feasible this is, but it would be kinda amazing to be > able to > treat Koutliner as kind of an overlay for Org content. So, for example, > I might > have a cell: > > > 2a. Table of Material for Review > > > > %ORGBLOCK_START% > > > > | Date Due | Item ID | > > |----------+---------| > > | 1/29 | 21515 | > > | 2/20 | 25155 | > > | 3/19 | 29901 | > > | 4/22 | 31555 | > > > > %ORGBLOCK_END% > > And have Koutliner recognize the block start/end tags and let Org do the > formatting in those places. You could then create formally structured > Koutliner > files that also include org-style headings and formatting and whatnot. I > think > that'd be awesome. > > To go one step further -- some folks are working on adding Transclusion > fucionality to Org. It would be *even cooler* to be able to just include > a > chunk of another file in a Koutliner document, and truly amazing to > transclude > a block from any file into a Koutliner doc so the changes don't have to > be > tracked -- they just happen. > > This would then give me all the benefits of a more rigid document type > and all > the flexibility and styling options of a system like org -- plus crazy > hypertext stuff that even the Web doesn't have. > > It's also, like, the most pie-in-the-sky feature request in the > universe, haha. > > Feature Idea #4: Embeddable Global Buttons > ========================================== > > I'm guessing this might become prohibitive from a performance > perspective if > you have a very large global button file, but -- it would be awesome if > I could > use the button file as a persistent list of buttons that I could add to > any > file. Or, more ambitiously, to combine the explicit buttons, and the > global > buttons, into a single table/database that I could then draw on to embed > buttons into my documents anywhere. > > Say, for instance, that I've got a global button that jumps to a file > where I > collect extracts from the reading I do -- <(Extracts File)>. I can think > of a > number of occasions where it would be cool to drop that button into my > notes. > > I also think it would be a handy way to interlink, say, a > zettelkasten-style notes > system: I would have collection of global buttons that point to the > entries in the > zettelkasten -- and I could then drop them into other notes and other > files as > appropriate. For this use case, someone will surely say: "But you can > just use > Org links for that!" But what if my notes aren't all in Org? Some are in > markdown, some are in plain text. What if I wanted to reference a Zettel > entry > in some code I'm working on? The thing that's awesome about Hyperbole is > it > works everywhere -- and unifying or globalizing the button functionality > would > be another way to have Hyperbole act as the hypertext layer for Emacs. > > At any rate -- looking forward to the final release of 7.0.8! > > On 30.01.2020 06:58, Robert Weiner wrote: > > #2 was a change we made to the button flash time handling that did not > > account for the persistence of customizable variables. It left you > > with a flash time of 1000 seconds that would timeout when you pressed > > an additional key. That has been reverted in the latest git repo > > master if you ‘git pull’ in the Hyperbole source directory and then > > restart Hyperbole/emacs. Buttons should work properly then. > > > > We have replicated #3 and should have that fixed in another day. > > > > Good catches. > > > > -- Bob > > > >> On Jan 29, 2020, at 4:16 PM, gravityp...@posteo.de wrote: > >> > >> Good afternoon, > >> > >> As recommended, I'm submitting my feedback on the 7.0.8 Test Release > >> here -- hopefully I'm doing this correctly. > >> > >> --------------------------------------------- > >> > >> OS: Windows 10 Home, Version 1909, Build 18363.592 > >> > >> GNU Emacs 26.3 (build 1, x86_64-w64-mingw32) of 2019-08-29 > >> > >> Hyperbole Built following the instructions on this Reddit post: > >> > >> > https://www.reddit.com/r/emacs/comments/euzxmx/gnu_hyperbole_708_test_release_with_patches/ > >> > >> Hyperbole Config: > >> > >> > ;; hyperbole > >> > (require 'hyperbole) > >> > (load "hyperbole-autoloads") > >> > (load "hyperbole") > >> > >> > >> --------------------------------------------- > >> > >> Feedback #1: Implicit Buttons are Much Improved! Action buttons are > >> great! > >> ====================================================== > >> > >> I wanna say, first, that the implicit buttons are much improved in > >> this release -- both in their ability to find the buttons, and in the > >> options for labeling and linking. Likewise, the new Action Button > >> syntax is cool! I'm super excited for the final build. > >> > >> Feedback #2: Possible Bug Causing Implicit Buttons Require Additional > >> User Input to Activate > >> =================================================================== > >> > >> Consider line 33 of the Hyperbole Demo document. It reads: > >> > >>> Hyperbole displays that file when you press {C-h h d a}. Hyperbole > >>> assumes > >> > >> If I want to invoke the key-sequence implicit button, I move the > >> cursor there, and hit M-RET or click with the mouse action button. > >> > >> The expected behavior is, obviously, that the button flashes, then > >> activates. For me, though, activating the button causes the button to > >> highlight persistently -- and no action occurs until I make another > >> keypress. Any keypress that doesn't insert text works: ESC, > >> Right-Arrow, etc. > >> > >> Most of the time when I press the extra key, the button then just > >> activates as normal, and works as expected. Sometimes when I press a > >> key, I get an error like: > >> > >>> apply: Wrong type argument: commandp, (keymap (keymap (9 . > >>> backward-button)) ESC-prefix) > >> > >> The debugger output: > >> > >>> Debugger entered--Lisp error: (wrong-type-argument commandp (keymap > >>> (keymap (9 . backward-button)) ESC-prefix)) > >>> #<subr call-interactively>((keymap (keymap (9 . backward-button)) > >>> ESC-prefix)) > >>> apply(#<subr call-interactively> (keymap (keymap (9 . > >>> backward-button)) ESC-prefix) nil) > >>> call-interactively@ido-cr+-record-current-command(#<subr > >>> call-interactively> (keymap (keymap (9 . backward-button)) > >>> ESC-prefix)) > >>> apply(call-interactively@ido-cr+-record-current-command #<subr > >>> call-interactively> (keymap (keymap (9 . backward-button)) > >>> ESC-prefix)) > >>> call-interactively((keymap (keymap (9 . backward-button)) > >>> ESC-prefix)) > >>> (cond ((null binding) (if (kbd-key:special-sequence-p key-series) > >>> (progn (setq unread-command-events (nconc unread-command-events > >>> (mapcar (quote identity) key-series))) t))) ((memq binding (quote > >>> (action-key action-mouse-key hkey-either))) (beep) (message > >>> "(kbd-key:act): This key does what the Action Key does.") t) (t > >>> (call-interactively binding) t)) > >>> (let ((binding (key-binding key-series))) (cond ((null binding) > >>> (if (kbd-key:special-sequence-p key-series) (progn (setq > >>> unread-command-events (nconc unread-command-events (mapcar ... > >>> key-series))) t))) ((memq binding (quote (action-key action-mouse-key > >>> hkey-either))) (beep) (message "(kbd-key:act): This key does what the > >>> Action Key does.") t) (t (call-interactively binding) t))) > >>> kbd-key:act("\033") > >>> actypes::kbd-key("\033") > >>> apply(actypes::kbd-key "\033") > >>> eval((apply action args)) > >>> (if (or (symbolp action) (listp action) (hypb:emacs-byte-code-p > >>> action) (and (stringp action) (not (integerp action)) (setq action > >>> (key-binding action)))) (eval act) (eval action)) > >>> (or (if (or (symbolp action) (listp action) > >>> (hypb:emacs-byte-code-p action) (and (stringp action) (not (integerp > >>> action)) (setq action (key-binding action)))) (eval act) (eval > >>> action)) t) > >>> (prog1 (or (if (or (symbolp action) (listp action) > >>> (hypb:emacs-byte-code-p action) (and (stringp action) (not (integerp > >>> action)) (setq action (key-binding action)))) (eval act) (eval > >>> action)) t) (hhist:add hist-elt)) > >>> (let ((hist-elt (hhist:element))) (run-hooks (quote > >>> action-act-hook)) (prog1 (or (if (or (symbolp action) (listp action) > >>> (hypb:emacs-byte-code-p action) (and (stringp action) (not (integerp > >>> action)) (setq action (key-binding action)))) (eval act) (eval > >>> action)) t) (hhist:add hist-elt))) > >>> (if (null action) (error "(actype:act): Null action for: `%s'" > >>> actype) (and (symbolp action) (symtable:actype-p action) (setq args > >>> (action:path-args-abs args))) (let ((hist-elt (hhist:element))) > >>> (run-hooks (quote action-act-hook)) (prog1 (or (if (or (symbolp > >>> action) (listp action) (hypb:emacs-byte-code-p action) (and (stringp > >>> action) (not ...) (setq action ...))) (eval act) (eval action)) t) > >>> (hhist:add hist-elt)))) > >>> (let ((prefix-arg current-prefix-arg) (action (actype:action > >>> actype)) (act (quote (apply action args)))) (if (null action) (error > >>> "(actype:act): Null action for: `%s'" actype) (and (symbolp action) > >>> (symtable:actype-p action) (setq args (action:path-args-abs args))) > >>> (let ((hist-elt (hhist:element))) (run-hooks (quote action-act-hook)) > >>> (prog1 (or (if (or (symbolp action) (listp action) > >>> (hypb:emacs-byte-code-p action) (and ... ... ...)) (eval act) (eval > >>> action)) t) (hhist:add hist-elt))))) > >>> actype:act(actypes::kbd-key "\033\015") > >>> apply(actype:act actypes::kbd-key "\033\015") > >>> (if hbut (apply hrule:action (hattr:get hbut (quote actype)) > >>> (hattr:get hbut (quote args)))) > >>> hbut:act(hbut:current) > >>> funcall(hbut:act hbut:current) > >>> (cond ((and (called-interactively-p (quote interactive)) (null > >>> but)) (hypb:error "(hbut-operate): No current button to operate > >>> upon")) ((not (hbut:is-p but)) (hypb:error "(hbut-operate): Button is > >>> invalid; it has no attributes")) (t (or but (setq but (quote > >>> hbut:current))) (hui:but-flash) (funcall operation but))) > >>> hui:hbut-operate(hbut:act "execute" hbut:current) > >>> hui:hbut-act(hbut:current) > >>> eval((hui:hbut-act (quote hbut:current))) > >>> (progn (if hkey-debug (hkey-debug)) (eval hkey-action)) > >>> (if (setq hkey-action (if assist-flag (cdr (cdr hkey-form)) (car > >>> (cdr hkey-form))) pred (car hkey-form) pred-value (eval pred)) (progn > >>> (if hkey-debug (hkey-debug)) (eval hkey-action)) (setq hkey-forms > >>> (cdr hkey-forms))) > >>> (while (and (null pred-value) (setq hkey-form (car hkey-forms))) > >>> (if (setq hkey-action (if assist-flag (cdr (cdr hkey-form)) (car (cdr > >>> hkey-form))) pred (car hkey-form) pred-value (eval pred)) (progn (if > >>> hkey-debug (hkey-debug)) (eval hkey-action)) (setq hkey-forms (cdr > >>> hkey-forms)))) > >>> (let ((hkey-forms hkey-alist) (pred-value) (hkey-action) hkey-form > >>> pred) (while (and (null pred-value) (setq hkey-form (car > >>> hkey-forms))) (if (setq hkey-action (if assist-flag (cdr (cdr > >>> hkey-form)) (car (cdr hkey-form))) pred (car hkey-form) pred-value > >>> (eval pred)) (progn (if hkey-debug (hkey-debug)) (eval hkey-action)) > >>> (setq hkey-forms (cdr hkey-forms)))) pred-value) > >>> hkey-execute(nil) > >>> (or (hkey-execute nil) (if (fboundp action-key-default-function) > >>> (progn (funcall action-key-default-function) t))) > >>> action-key-internal() > >>> (prog1 (action-key-internal) (run-hooks (quote > >>> action-key-depress-hook) (quote action-key-release-hook))) > >>> action-key() > >>> (if arg (assist-key) (action-key)) > >>> hkey-either(nil) > >>> funcall-interactively(hkey-either nil) > >>> #<subr call-interactively>(hkey-either nil nil) > >>> apply(#<subr call-interactively> hkey-either (nil nil)) > >>> call-interactively@ido-cr+-record-current-command(#<subr > >>> call-interactively> hkey-either nil nil) > >>> apply(call-interactively@ido-cr+-record-current-command #<subr > >>> call-interactively> (hkey-either nil nil)) > >>> call-interactively(hkey-either nil nil) > >>> command-execute(hkey-either) > >> > >> I get this behavior in elisp files as well. Consider the following: > >> > >>> ;; Info-mode > >>> (when (eq system-type 'windows-nt) > >>> (setq Info-additional-directory-list > >>> (quote > >>> ("~/Apps/msys2/usr/share/info" "~/Apps/msys2 > >>> /mingw64/share/info")))) > >> > >> If I move to one of the paths listed, and hit the action button, > >> Hyperbole correctly recognizes the path as an implicit button, > >> highlights it, but then doesn't act upon it until I make some > >> additional keypress. This case does not throw an error, so I can't > >> provide debug information. > >> > >> Feedback #3: Explicit Buttons Should Be Colored > >> =================================== > >> > >> If I have an explicit button in a file -- <(fake button)> -- it does > >> not display in red as intended. Examining the way this stuff is set > >> up, it looks like the button color is tied to the `Hbut` face, and > >> that the `Hbut` face defaults to > >> > >>> foreground: SystemWindowText > >>> background: SystemWindow > >> > >> This basically means black text on a white background, just like all > >> the other normal text in a file. > >> > >> Modifying these faces doesn't seem to stick, either. If I go into > >> Hyperbole's customization {C-h h c a} then the Hyperbole Buttons > >> group, then the `Face Hbut` property and set it to `red` or `#ff0000` > >> -- Hitting `Apply and Save` creates an entry in my custom.el: > >> > >>> '(hbut ((t (:background "SystemWindow" :foreground "red"))) t) > >> > >> and changes the button color correctly... but upon restarting Emacs, > >> it reverts back to `SystemWindowText`/`SystemWindow`. This is true > >> even when `custom.el` is loads correctly. I have also tried this > >> without having an external customization file -- in that case, > >> customizing the face adds the line above to the bottom of my init, but > >> there's no difference in behavior. > >> > >> I was able to force the buttons to always be red by creating this hook > >> -- but that shouldn't be necessary, right? > >> > >>> (add-hook 'hyperbole-init-hook (lambda () > >>> (hproperty:cycle-but-color > >>> "red"))) > >> > >> > >> > >> > >> Thank you for all your hard work on this package. I use Hyperbole > >> basically every day, and I'm always excited for a new release! > >> >
