i think this package has a lot of potential to make vim-style editing with evil even more powerful than it already is.

that's why i just blurt out ideas and thoughts in this bug tracker.

keep up the good work. ;)

evil-goggles works by advising evil's operators. e.g. evil-delete, evil-change, evil-yank, etc.

Both evil-cleverparens and evil-smartparens replace those operators with their own versions, which leaves evil-goggles hanging, because it's not plugged into these new versions.

Description

With an active region, and having copied two pieces of text y.
Pasting p and replacing the paste with: M-y (evil-paste-pop)

Results in the highlight remaining visible, and it can't be cleared easily.

One way is to reopen the buffer, or for a temporary buffer,
copy it's contents and paste it in a new temporary buffer.

Reproduction steps

With evil and evil-goggles installed.
init.el contains:

  (require 'evil)
  (evil-mode 1)

  (evil-goggles-mode)

  (setq evil-goggles-pulse nil)

• Create a new buffer: C-x b test RET
• Type:

a
b
c

• Copy the "c" line: yy
• Move up to the "b" line: k
• Copy the "b" line: yy
• Move up to the "a" line: k
• Select the "a": v
• Paste: p
  the buffer contains:

b

b
c

• replace the paste with the previously copied line: M-y
  it calls: evil-paste-pop

Observed

The buffer contains:

c

b
c

the pasted "c" line is highlighted.

Expected

The highlight shouldn't remain.

And/or it should at least be cleared when another operation is performed
that shows and hides a evil-goggles highlight.

Notes

That the highlight is evil-goggles related can be as follows:

• Place the cursor on the highlight and call: M-x describe-char RET
• Switch to the *Help* buffer: C-w j (or C-x o)
• Scroll to the bottom: G (or M->)

The overlay says:

There is an overlay here:
 From 2 to 4
  face                 evil-goggles-default-face
  insert-behind-hooks  (evil-goggles--overlay-insert-behind-hook)
  priority             9999
  window               #<window 3 on test>

Deleting the highlighted line: dd
and describing the char again: M-x describe-char RET
shows that it's still there:

There is an overlay here:
 From 2 to 2
  face                 evil-goggles-default-face
  insert-behind-hooks  (evil-goggles--overlay-insert-behind-hook)
  priority             9999
  window               #<window 3 on test>

Typing at that location shows the highlight on the typed characters.
For example when typing:

abc
def

The buffer now looks like this:

abc
def
b
c

the "abc" line and the letters "def" on the line below are highlighted.

The only way I've found to remove the highlight,
is to reopended the buffer.

In this case the buffer isn't a saved file.
One way to remove the highlight is to copy the whole buffer
and paste it in a new temporary buffer.

System Info

evil-goggles-20200101.1935
Evil version 1.14.0
GNU Emacs 27.1 (build 1, x86_64-w64-mingw32) of 2020-08-21
Windows 10 2004

First of all, thank you very much for this great package.

I'm having trouble setting delete and yank hints independently.
When I do this:

(setq evil-goggles-enable-delete nil)
(evil-goggles-mode)

I still get the hint animation when I delete something.

When I do this:

(setq evil-goggles-enable-yank nil)
(setq evil-goggles-enable-delete nil)
(evil-goggles-mode)

it works fine but now I've lost the hint for yanking. Is this a bug? And if no, how can I disable hints on deletion only?

error: Package emacs-25' is unavailable`

I am on Linux by the way, when I installed this yesterday on my windows machine it worked fine, so I am thinking a possible update might have broken it.

Thanks

for some operations like filling, shifting, and other "transformative" operations (as opposed to "destructive" operations like evil-delete, or "constructive" operations such as evil-paste-*), it makes sense to show a highlight after the transformation, instead of showing the region before the transformation.

for example gqip to fill a paragraph of text currently has a delay before the result is visible. it would make more sense to highlight the result of the operation instead of its input.

is this something you think is feasible?

see title.

Behavior:
Buffer content is (abc d|ef). (cursor at "d")
After pressing cs)], the buffer becomes ef].

Expected behavior:
buffer becomes [abc def]

Setting (setq evil-goggles-enable-change nil) can fix this issue.

Hello,

I'm eager to try this neat package, however it requires Emacs 25. On reddit, skeeto may have a fix:

The only thing that ties it to Emacs 25 is funcall-interactively. This can be simulated well enough with cl-letf. However, I tried changing all of the funcall-interactively to plain old funcall and it seems to work just fine in Emacs 24.

https://www.reddit.com/r/emacs/comments/6x5zzc/evil_goggles_display_visual_hint_on_evil_edit/dmfbl6f/

and I can confirm.

regards

ps: and so cool tip, I didn't know =ip :)

Hi,
it would be a nice to be able to turn on goggles for custom evil-operators.
This could be possible by adding an evil-command-property.

If you do then someone who wants to test evil itself might end up your bundled copy instead. That's a problem because your copy already isn't identical anymore and even if you updated it, it would probably get out-of-date again.

Can't you just assume that evil including evil-tests is available? Or else download it without checking it into the evil-goggles repository (it seems there is already code to do that)?

So I use emacs in daemon-mode with
emacs --daemon
and
emacsclient -create-frame

With this setup the highlights appear, but do not pulse.
If I start emacs normally, everything behaves as expected.

I know that this is a more rare case, but in visual-block range the wrong area is highlighted.
example
d C-v 5 j
the range is highlighted as it would be just visual-state not the block.

It would be nice if evil-goggles can briefly highlight the changes that the previous insert-mode made, right after leaving insert-mode.

A large number of Emacs packages, which provide an appearance enchantment, have their own face. For example, hl-line mode, nlinum, custom highlighting for numbers, etc. I guess evil-goggles should have own face, by default inherit from the region face. Because some themes have specific settings for the diff/region faces or your users would like to customize only evil-goggles behavior.

(defface evil-goggles-face
  '((t (:inherit region)))
  "Evil-goggles face to use for highlighting different actions."
  :group 'evil-goggles)

I could create a PR with this change, but I doubt that only one face is enough, because we have many different actions. So I think there is possible solutions:

1. Add a general face, which will use for any kind of action.
2. Four evil-goggles faces, which will highlight the following actions: yank, add, delete, change a region. Maybe one extra face for a action like pasting.

Hi, I think your package is awesome! However it appears to have a minor quirk when working with multiple cursors using evil-mc. When I perform a bulk action like changing or deleting several words at once with multiple cursors, each action is performed one at a time waiting on the animation of the previous one to complete.

You can see an example of the behavior here.

I would imagine a good solution would be to either disable visual hints when multiple cursors are active or potentially perform all of the hints simultaneously. One other option might be to expose some sort of predicate that can be overridden that would let an end user determine if hints should be run or not.

Thanks!

Hi, I recently noticed that evil-goggles stopped changing the font face foreground when displaying visual hints. I used git-bisect to figure out that the first commit exhibiting this behavior is: f79c03b.

Before: f79c03b
http://drop.bryan.sh/6BGfwzSb4A.mp4

After f79c03b:
http://drop.bryan.sh/x5MrWktqkC.mp4

You can see from the two quick screencasts that the :foreground property is being ignored on all of the evil-goggles-* faces. If I add a :background property to each of my fonts, I can see that the background color does change properly, just not the foreground.

Here's my configuration for reference:

;; Override evil googles colors
(custom-set-faces
 '(evil-goggles-delete-face           ((t (:foreground "#ff6c6b"))))
 '(evil-goggles-paste-face            ((t (:foreground "#98be65"))))
 '(evil-goggles-yank-face             ((t (:foreground "#51afef"))))
 '(evil-goggles-undo-redo-remove-face ((t (:foreground "#ff6c6b"))))
 '(evil-goggles-undo-redo-add-face    ((t (:foreground "#98be65"))))
 '(evil-goggles-undo-redo-change-face ((t (:foreground "#51afef")))))

Thanks!

Can you please add a license file? As it is we cannot use this package for anything other than personal use

when pasting text it helps if the overlay would disappear a little bit slower than it does for e.g. evil-delete.

right now this is a single global number.

The u/redo hint was broken by 674a1be

For example I have evil-commentary installed that was mapped on g c. Well, if I comment only a single line via gcc or something like 10gcc, visual hint works perfectly, but if I want to select region there's no visual hint, which would be more obvious and familiar in this case.

Would you like to add support for visual mode operations to evil-goggles?

Some visual feedback is not shown in org-mode in my setup. For example, D or cw work for me in both text-mode and org-mode, whereas dw or dd show visual feedback in text-mode but do not show any feedback in org-mode.

Not sure if this is related to my setup or a general problem. I am on Emacs 26.1 and use the development version of Spacemacs.

Hello!
It seems that evil-paste-pop does not work with evil-goggles activated.

Reproducing it

1. In Normal state, yank any text using e.g. yy.
2. Yank a different piece of text - say another line (this step isn't actually necessary to reproducing the bug but illustrates the desired goal).
3. Paste somewhere else using p.
4. Immediately afterwards, hit C-p to cycle to the previous yanked item.

This results in the error:

Previous command was not an evil-paste: next-line

Workaround

Disable evil-goggles for paste via the custom variable:

(use-package evil-goggles
  :custom
  (evil-goggles-enable-paste nil))

When using this package with the Doom One theme, the highlighting intensity is very low and can barely be seen.
Can something be done, please?

Hello,

I know you probably don't care, but at work I sometimes have to work on windows, and there evil-goggles is terribly slow. Operations like dw takes up to 2 seconds, and as soon as I disable evil-goggles everything is normal again.

Disabling evil-goggles-pulse seems to fix it...