abo-abo / avy Goto Github PK

I get the below on calling avy-goto-line with avy-all-windows set to t.

Here I have both windows showing the same buffer. This problem does not happen if the windows are showing different buffers.

You can click on the below image to see it enlarged.

I'm a very bad typist. I can quickly write prose or code because my muscles have memorized the relevant words, but typing nonsense is very hard for me. And the "words" you have to type to jump to some target with avy-jump are just random sequences of avy-keys. Every second time I want to jump somewhere, I hit some wrong key and end up somewhere else.

So I've thought it would be very nice if I could select the jump target differently. Here are some possibilities that I can imagine:

1. One target is pre-selected (ideally the target that's in the middle) and highlighted differently, and then I can select the next/previous target using C-f/C-b/<up>/<down>.
2. Instead of using random char sequences from avy-keys, use short English (or whatever) words. The words could come from e.g. a file in /usr/share/dict/. I only have /usr/share/dict/cracklib-small but that already contains nearly 1000 words that are one to three letters short. The problem with this approach is that it will only work nicely with avy-goto-*-style pre or post because then you see the complete word you should type whereas I prefer the at style where this is not true.
3. Since I usually manage to type at least the first character correctly, it would help if I could extend the range of avy-keys to include also uppercase letters. But I'd like those to be used only if then a target can be reached with one single key.

Ok, I just wanted to put some ideas to discussion.

When jumping across frames, point seems to have been moved to the destination frame, however the frame does not seem to be active and is not brought to the front of other frames. After jumping running commands that move point such as forward-char do nothing.

In the attached screen shot I have just used avy-goto-word-1 to jump to the frame on the left at the when command. You can see that the frame was not brought to the foreground.

I have customized this way:

'(avy-all-windows (quote all-frames))

Thanks
Mike

I very much like the idea to display all subsequent keys needed for the decision. The existing pre and post style of displaying these inserts these decision chars, which push original text rightwards.

Can we please have a style that overwrites at jump location, so that underline text does not change location? The way I use it is to look at the location I want to jump to, then issue the jump command; if the location changes in this process I need to scan to find my desired location again, which could be annoying.

Thanks for the awesome work in the first place!

After moving a line, an empty is left behind. It should also be deleted since the old line is moved to the current point.

By definition of this funciton, you intend to jump to somewhere on the same line in the same window.

Then the global value of avy-all-windows should not impact this function.

This problem resulted in this when I tried to jump to a word on the same line in the right-side window.

See the screenshot.

Why are they no two-char leads? Looking at the screenshot from the README this shouldn't be the behaviour.

Instead of prefixing the tree to the target point, it would be nice if the tree could be overlaid on its target as to not disrupt positioning. Your eyes is looking in one spot for the target point; if there are multiple matches on the same (longer) line, the target point can visually move.

The only question to think about would be

What should happen if two overlays would intersect?

The thing that makes Avy great, in my opinion, is the ability to see the whole path of the tree from the get-go (so you can position your hands -- unconsciously, of course). If two overlays were to intersect with each other (think avy-goto-char with an input of SPC), then that advantage would be lost. A possible solution is to customize the value per function (as an alist).

A basic README would be useful. :-)

I think that avy-isearch should be bound to isearch-mode-map for convenience when using isearch. For example:

(define-key isearch-mode-map (kbd "M-s j") 'avy-isearch)

There should be an example on the homepage to make the usage obvious to first time user. I like this package. Good job!

The README says:

You can actually replace the M-g g binding of goto-line, since if you enter a digit for avy-goto-line, it will switch to goto-line with that digit already entered.

I can't make this work. When I type M-g g 1 I get a No such candidate, 49 error message.

I really like avy so far, to replace the rather inflexible ace-jump-mode setup I had. However, there is one thing that strikes me as odd about the use of the three faces avy-lead-face*: avy-lead-face-0 is used for the 1st non-terminating lead char, not for all the chars I can select at any given time.

So in a tree with 2- and 3-char possibilities, after I have typed the 1st char, the 2nd char in the 3-char sequences is highlighted with avy-lead-face-0, but the 2nd char in the 2-char sequences is highlighted "normally" with avy-lead-face (because it is terminating the sequence).

To me, that does not make much sense; I would always like all possible choices to stand out. Could you explain the rationale behind the current behavior? It seems this could be changed (even optionally) in the avy--overlay-* functions, what do you think about that? If you agree, I would get to that soon.

With the following buffer content i can not jump to anywhere except the first capital T.

//Text
//Text
//Text
//Text

What's the supposed behavior when looking for something? Should you get all possible single letter triggers before they start becoming multi-letter?

See this screenshot to understand what I mean.

I've switched from ace-jump to avy-jump just recently. One major difference is that ace-jump's overlays are displayed on top of the jump target and only one jump character is displayed at a time. With avy-mode, the overlays always show the complete jump character sequence and are displayed right of the jump target.

At least my personal preference (which is not ace-jump biased too much; I started using that only two weeks ago before switching to avy-jump yesterday) is that I like the ace-jump behavior better because the buffer contents won't switch to the right. That is, if you have 5 matches on a line, each requiring a 2-char key sequence to jump to, then the last match has switched 8 chars to the right. With ace-jump, it stays where it has been before. So this "fix target with your eyes and then jump" thingy works better.

Situation:

After calling customize-face, then I search for avy-background-face.

The foreground and the background faces are changed, and this is saved and set in the current and future sessions. The colors are visible in the customization window.

Issue:

When I call avy-goto-line, then I still get another colors in the backgroud.

Does the face of avy-goto-line not belonging to the group of avy-background-face?

Thanks in advance.

I like the plugin, but what makes it very hard for me to use is that all the text that is to be selected gets moved, because the shortcut letters are written in front of it. To make things more usable, I suggest to put the shortcut letters over the text. Dimming all other text would also be nice.

What I'm basically asking for is http://vimawesome.com/plugin/easymotion, which I consider the ultimate jumping plugin there is.

I hit the key combination C-s C-' by mistake, and avy-isearch seems to infloop at that point. Please fix it to be more robust to that case.

I'd suggest running M-x checkdoc on the source code as there are a few problems here and there and packages in ELPA should generally be checkdoc compliant.

There are some strange things in the docstrings, btw:

(defun avy--goto (x)
  "Goto X.
X is (POS . WND)
POS is either a position or (BEG . END)."
  (if (null x)
      (message "zero candidates")
    (select-window (cdr x))
    (let ((pt (car x)))
      (when (consp pt)
        (setq pt (car pt)))
      (unless (= pt (point)) (push-mark))
      (goto-char pt))))

You shouldn't use uppercase to refer to anything but function params. pos, wnd, beg, end are all confusing in that sense.

Same here:

(defun avy--overlay-at (path leaf)
  "Create an overlay with STR at LEAF.
PATH is a list of keys from tree root to LEAF.
LEAF is ((BEG . END) . WND)."

There's no param str, which makes this docstring confusing for people used to the common conventions.

If I hit . on the char: prompt of avy-goto-word-1 absolutely every single char in the window is offered as a jump. I guess there is a `regexp-quote' missing somewhere?

Hello,

ace-jump-char-to-mode moves the cursor to a character before the jump point. (Similar to how 't' works in vim). Just want to check if there is any avy equivalent of that function?

Thanks

When using the de-bruijn style, it's hard to tell how many characters a certain target needs. Of course, you can tell from context (you can scan forward to the end of the cluster and count the number of non decision chars to determine the needed length.)

I'm not entirely sure how to solve this. One way would be to have different color decision chars based on the number of characters left to type. (As far as I can tell, this is the way evil-easymotion does it. They have yellow for single character jumps and red for two character jumps (no idea what happens if they need three characters).

This issue can track the discussion of this problem. Of course, there may be other solutions, and maybe it bothers me more than it does others.

To reproduce:

• Run (avy-setup-default).
• C-s and then C-'
• C-' is undefined

I had to explicitly evaluate the form.

Seems to me this file has very little value - I'd suggest simply placing it's contents in "a manual setup" section of the README. Might also be worth mentioning installation from MELPA & ELPA.

I think it'd be beneficial if there were 2 commands less to remember and the goto-word commands were simply subword-mode aware - they'd respect subwords if subword-mode is enabled. Alternatively there could be some defcustom with values like - "word-start", "subword-start", "subword-start-when-subword-mode-enabled".

After installing avy, assigning keybindings and restarting Emacs, I get these errors:

command-execute: Autoloading failed to define function avy-goto-char
command-execute: Autoloading failed to define function avy-goto-line
command-execute: Autoloading failed to define function avy-goto-word-1

After installing avy I tried it and everything was fine, but now after restarting it doesn't works!

• Move cursor to a line with [ or ] in it.
• Run avy-goto-char-in-line and choose either the character above.
• Error occurs.

I just tried setting avy-styles-alist to 'at-full for avy-goto-line, and it didn't work.

(I realize that setting avy-goto-line to 'at-full may sound a little weird, because then you can't see the begining of the line... but I personally don't like the text moving around so much. And anyway, I've usually already read the beginning of the line when I start the command.)

Anyway, I started looking at the code, and I noticed that avy-goto-line and avy-isearch have their styles hardcoded to 'pre and post, respectively.

Are you receptive to a patch? I can do a pull request if you want. I can also try to add some code so the default style for these functions is preserved.

Thank you for this extension!

Setting avy-all-windows to t is ineffective. Now it shows the jump locations only in the current window regardless.

avy-goto-subword-1 might not need as much leading chars as avy-goto-subword-0. It might be better to use customized avy-keys instead of (number-sequence ?a ?z).

There seems to be a slight bug where the overlays start incorrectly marking decision chars when using the de-bruijn style.

Example Jump text

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;

It's also interesting to note that this bug is sporadic. Sometimes, it'll highlight it all correctly, and sometimes, it'll highlight it all wrong. This is an example where part of the highlighting is wrong.

Can you suggest how I can get this functionality without using call-interactively?

(defun my/avy (arg)
      "
        `my/avy' -> `avy-goto-word-1'
    C-u `my/avy' -> `avy-goto-char-2'
C-u C-u `my/avy' -> `avy-goto-line'
"
      (interactive "p")
      (let ((avy-all-windows t) ; search in all windows
            (fci-state-orig fci-mode)
            (fn (cl-case arg
                  (4  'avy-goto-char-2) ; C-u
                  (16 'avy-goto-line) ; C-u C-u
                  (t  'avy-goto-word-1))))
        (if fci-state-orig
            (fci-mode 'toggle))
        (funcall fn)
        (if fci-state-orig
            (fci-mode 'toggle))))

The above wrapper function breaks because now the first arg to avy-goto-word-1 is a manadatory arg char; earlier its only arg was an optional arg to toggle avy-all-windows.

I cannot use call-interactively because then my wrapper function arg gets passed on to the function I am calling interactively.

Will we have avy-goto-subword-1 which reads one char first, and jump to subwords? This should be useful for jumping CamelCaseWord identifiers.

I don't believe that to be true. Neither GNU ELPA nor Emac 24.5 contain it.

This is a useful feature in ace-jump-mode that allows jump to any char in a current line using a single character. With current avy-goto-word-1, I frequently have to enter 2 characters.

Right now we you have something like O'Conner, Conner is not treated like a word start. Seems reasonable to split words at apostrophes even for things like we'll, he's, as those are technically two words anyways.

To lower the number of required key bindings one trick could be to use -2 command but fallback to -1 if only one character is entered within 0.5 second (I guess a high value like half a second would give a better UX than something faster).

1. Set the at-full as style for avy-goto-line.
2. Input two lines of text in a text mode buffer - the first line starting with a tab (entered with C-q C-i) then any non-white space text, second line starting with 8 spaces followed by any non-white spaces.
3. M-x avy-goto-line, note the non-white space text in the first line jumped to the left.

It also shows up in a magit-status buffer with unstaged or staged items which are indented with tabs.

Reproduce steps:

1. Open two windows side by side, and my cursor on left window.
2. avy-goto-subword-0 and type char s

The leading chars a, b, c ... are counting from right window, not from currently focus window as the screenshot shown. I think it will be better to make the the leading chars counting from currently focus window so user can jump by typing less leading char.

In the documentation you are binding the avy-goto-char command to the pi key. I guess you are using a keyboard layout similar to this. The first time I saw this I was confused since I don't have a pi key in my keyboard layout. I thought it was something special for the avy package.

Can you change the key binding to something more common, say Ctrl-:?

Thanks

avy.el seems useless on its own, so I'd suggest merging both source files into one. I noticed a bit of confusing amongst users whether this package is called avy or avy-jump, so we'll solve one more problem with such a move.

Idea: When avy-goto-line is invoked, if the input is a number, interpret it as a line number, and goto-line, that way avy-goto-line can use the same keybinding as goto-line.

Perhaps this breaks the philosophy of only dealing with text currently seen?

I just had the strange situation that I wanted to jump to a } in my tex document, and although there were only 15 matches visible, I got avy key sequences of length four!

Well, the reason was that I had two windows with two buffers. One buffer showed my tex document, the other showed the corresponding PDF file using PDF Tools. The problem was that in addition to the 15 occurrences of } in my tex document window, there were several hundreds of matches in the "visible portion" of the PDF buffer.

It doesn't make sense to consider matches in such a PDF buffer because PDF contents are garbage from a human perspective, and the actual contents aren't visible anyway because they are overlayed with an image showing the rendered version of the PDF's current page in terms of the display text property.

So I'd suggest to have some avy-ignored-modes variable where users can add major mode symbols and buffers using these modes shouldn't be considered when finding matches. Obvious candidates to be put on that list by default are all kind of modes for binary data which is then displayed in a human-friendly way, e.g., image-mode, doc-view-mode, pdf-view-mode (from PDF tools), etc.

It would be useful for user to customize what to jump to. For example, a user can create an avy command to jump to all the if occurrences; similar while, for... so I can bind all of them under some prefix key like C-j and quickly jump to with a few key strokes with minimal screen disruption.

I got the idea from this issue: abo-abo/lispy#77

First of all, I think avy-lead-face-0 is a great idea.

1. Add avy-lead-face-0 to pre and post
2. Do not remove chars from overlays when using pre, post, or at-full
   #1.

avy-lead-face-0 appears in my mind to mean that "this char is a decision char". I would love to see this ported to pre and post because that meaning has significance there too. In addition, if 2 is implemented, you can move the avy-lead-face-0 to denote the current generation of decision chars, which might make sorting out which chars are important easier.
#2.

In the current version of avy, typing part of a target causes that level of the tree to be deleted, leaving only decision chars. Unfortunately, because of the nature of pre and post, this causes the current buffer text to be re-shifted on every keypress (i.e. as the level of displacement goes from three, to two, to one, to zero), forcing the eye to follow a moving target.

Instead of deleting the characters from the overlay, I propose highlighting them with a third, "inactive" face instead. They will fade into the background, so it's clear that they're no longer decision chars, but they will still occupy space, preserving the alignment.

Hi abo-abo!

Everything okay in the big city Eindhoven? Thanks for sharing this nice extension. However, I have a question.

I don't often have many buffers open. So I wonder if it would be possible to have my prefered keys come first. Usually it will be the keys on the home row first (asdfghjkl), instead alphabetically. This makes me less move my fingers to the keys, because they're already on the home row.

Ace-jump knows the same option: https://github.com/winterTTr/ace-jump-mode/wiki/AceJump-FAQ

Is that possible for avy-go-to-line too?

1. Split the frame in two windows.
2. Open a text file in one and an image file on the other.
3. Try to avy-goto-word-1 on the text buffer.

Emacs hangs after I type the leading char.

Even with my fix from the second commit in #3, avy-goto-subword-0 isn't too accurate. With a word like ThisIsATest, it considers This, Is, and ATest as subwords. But of course ATest are actually two subwords.

I think a proper fix would be to re-use subword-forward-regexp defined in emacs' subword.el. (That also requires case-fold-seach to be nil, so my second commit from #3 is correct anyway.)

If you attempt to call avy-goto-word-1 with [, it throws the error avy--regex-candidates: Invalid regexp: "Unmatched [ or [^".

See this screenshot.