Open MicahElliott opened 2 years ago
I think this works:
(defun avy-tree (lst keys)
"Coerce LST into a balanced tree.
The degree of the tree is the length of KEYS.
KEYS are placed appropriately on internal nodes."
(let* ((len (length keys))
(order-fn (cdr (assq avy-command avy-orders-alist)))
(lst (if order-fn
(cl-sort lst #'< :key order-fn)
(if (string-match-p "above" (symbol-name this-command)) ; *** THIS IS THE CHECK ***
(nreverse lst)
lst))))
...
Does this seem ok? If so, shall I put in a PR with this change?
@MicahElliott your modfification of avy-tree is interesting , but actually avy-goto-line-above
takes a second arguement , reverse .
if reverse is non nil , the behaviour you request will be available
please close this issue if my suggestion fixes your problem
Let's say I have a window showing many (200) lines. Point is somewhere in the middle or bottom of the screen. I want to jump up say 5 lines. Avy presently is optimized to jump most easily way up to the top of the window rather than 5 lines up. To go upward, I almost always end up typing two prompt chars.
If for the "above" case, the order was reversed, going up 5 lines would always just require typing a single char to jump. I feel that this should be the default behavior for the "above" commands. Isn't it most common to do shorter jumps?
I suppose a workaround is to just rewrite the little
avy-goto-word-1-above
and have the jumpable range limited to ~30 lines up from point rather than(window-start)
. I just didn't see an obvious way to to reverse the labeling.I also see that if I
nreverse
thelst
inavy-tree
fn that it works as I like (for above). So I'm not sure if it's better to write my own hacked up version ofavy-tree
, or figure out if I should learn to write anorder-fn
foravy-orders-alist
, and if that's what it's designed for. But I don't see a way inside ofavy-tree
to determine if the caller was an "above" or "below" fn.Thanks for any tips (and for the amazing tool).