> From: Duy Nguyen <ddnguyen2101@gmail.com>
> Date: Thu, 18 Aug 2022 07:47:04 +0200
>
> First config I tried:

> [... 32 lines elided]

> Hope this is sufficient, otherwise please let me know what other
> information I can provide.

Yes, it is sufficient.  Thank you!  What you did is correct.  The
problem here is with Evil.  Specifically, the scroll commands tell Emacs
that they actually are the {next,previous}-line commands.  Try adding
next-line to the pulsar-pulse-functions and then you will see that C-d
pulses.  However, this has the unintended effect of also applying to the
standard j motion.

Here is the problematic code:

    (evil-define-command evil-scroll-up (count)
      "Scrolls the window and the cursor COUNT lines upwards.
    If COUNT is not specified the function scrolls down
    `evil-scroll-count', which is the last used count.
    If the scroll count is zero the command scrolls half the screen."
      :repeat nil
      :keep-visual t
      (interactive "<c>")
      (evil-ensure-column
        (setq count (or count (max 0 evil-scroll-count))
              evil-scroll-count count
              this-command 'next-line) ; PROT: This is the problem
        (when (= (point-min) (line-beginning-position))
          (signal 'beginning-of-buffer nil))
        (when (zerop count)
          (setq count (/ (window-body-height) 2)))
        (let ((xy (evil-posn-x-y (posn-at-point))))
          (condition-case nil
              (progn
                (scroll-down count)
                (goto-char (posn-point (posn-at-x-y (car xy) (cdr xy)))))
            (beginning-of-buffer
             (condition-case nil
                 (with-no-warnings (previous-line count))
               (beginning-of-buffer)))))))

The (setq this-command 'next-line) messes things up for us because we
cannot know if the command is a scroll motion or a line motion.

Perhaps the Evil maintainers have a good reason for designing it this
way, though I, as an outsider right now, feel that it would be better to
treat them as the scroll-up-command and scroll-down-command.

Maybe you can bring this issue to the attention of the Evil maintainers?
Please add me Cc if you do or ping @protesilaos if it is on GitHub.

> On another note, I have tried to make pulsar pulse when I switch to an
> emacs frame (see code above), however there is a delay before the
> pulse when I switch from a non-emacs frame to an emacs frame. See also
> here: https://www.youtube.com/watch?v=S_iTGdwEDc0. Is there any way to
> reduce/remove the delay? Appreciate this is a different topic, so
> happy to create a new mail thread for this if you prefer.

Yes, this is a problem.  It is highly unlikely that pulsar is at fault
here.  But let me look into it to see if I can help you.  More to
follow.

-- 
Protesilaos Stavrou
https://protesilaos.com

> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Thu, 18 Aug 2022 09:29:29 +0300
>
>> On another note, I have tried to make pulsar pulse when I switch to an
>> emacs frame (see code above), however there is a delay before the
>> pulse when I switch from a non-emacs frame to an emacs frame. See also
>> here: https://www.youtube.com/watch?v=S_iTGdwEDc0. Is there any way to
>> reduce/remove the delay? Appreciate this is a different topic, so
>> happy to create a new mail thread for this if you prefer.
>
> Yes, this is a problem.  It is highly unlikely that pulsar is at fault
> here.  But let me look into it to see if I can help you.  More to
> follow.

I tried it but it pulses normally on my end.  Perhaps you could do
something like this?

    (defun testing-pulsar-focus-frame ()
      (let ((pulsar-iterations 5)
            (pulsar-delay 0.025))
        (when (frame-focus-state)
          (pulsar-pulse-line))))

    (add-function :after after-focus-change-function #'testing-pulsar-focus-frame)

Using a named function instead of a lambda is easier for testing purposes.

In the 'let' form you would lower the values to hopefully get the effect
to not last as long.  I have halved them in this sample.

Though, again, this is not pulsar's fault as something elsewhere is
causing such a prolonged delay.  Perhaps there are other functions in
after-focus-change-function which take a lot of time to compute?

-- 
Protesilaos Stavrou
https://protesilaos.com

> Yes, it is sufficient.  Thank you!  What you did is correct.  The
> problem here is with Evil.  Specifically, the scroll commands tell Emacs
> that they actually are the {next,previous}-line commands.


> Maybe you can bring this issue to the attention of the Evil maintainers?
> Please add me Cc if you do or ping @protesilaos if it is on GitHub.


Thanks for checking Prot! I will raise it on their Github and tag you as well!

> I tried it but it pulses normally on my end.  Perhaps you could do
> something like this?
>
>
>     (defun testing-pulsar-focus-frame ()
>       (let ((pulsar-iterations 5)
>             (pulsar-delay 0.025))
>         (when (frame-focus-state)
>           (pulsar-pulse-line))))
>
>
>     (add-function :after after-focus-change-function #'testing-pulsar-focus-frame)
>
>
> Using a named function instead of a lambda is easier for testing purposes.
>
>
> In the 'let' form you would lower the values to hopefully get the effect
> to not last as long.  I have halved them in this sample.
>
>
> Though, again, this is not pulsar's fault as something elsewhere is
> causing such a prolonged delay.  Perhaps there are other functions in
> after-focus-change-function which take a lot of time to compute?


You are right, I just tried my original config on another computer
running WSL and it just works as expected... The issue is only on my
Macbook using emacs-plus@29. I will probably need to raise a
question/issue on this on their Github. Hopefully they will look into
it even if it is a really specific edge case.

Thanks again!
Duy

> From: Duy Nguyen <ddnguyen2101@gmail.com>
> Date: Thu, 18 Aug 2022 10:00:51 +0200
>

> [... 5 lines elided]

>> Maybe you can bring this issue to the attention of the Evil maintainers?
>> Please add me Cc if you do or ping @protesilaos if it is on GitHub.
>
>
> Thanks for checking Prot! I will raise it on their Github and tag you as well!

Thank you!


> [... 21 lines elided]

>> Though, again, this is not pulsar's fault as something elsewhere is
>> causing such a prolonged delay.  Perhaps there are other functions in
>> after-focus-change-function which take a lot of time to compute?
>
>
> You are right, I just tried my original config on another computer
> running WSL and it just works as expected... The issue is only on my
> Macbook using emacs-plus@29. I will probably need to raise a
> question/issue on this on their Github. Hopefully they will look into
> it even if it is a really specific edge case.

Okay.  If there is something we can do about at the pulsar level, then
please let me know.

-- 
Protesilaos Stavrou
https://protesilaos.com

Continuing the discussion from here:
https://github.com/emacs-evil/evil/issues/1659

>  pulsar.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
>
> diff --git a/pulsar.el b/pulsar.el
> index ed62b86..0e2506f 100644
> --- a/pulsar.el
> +++ b/pulsar.el
> @@ -393,7 +393,8 @@ (define-globalized-minor-mode pulsar-global-mode pulsar-mode pulsar--on)
>  (defun pulsar--post-command-pulse ()
>    "Run `pulsar-pulse-line' for `pulsar-pulse-functions'."
>    (when (and (or pulsar-mode pulsar-global-mode)
> -             (memq this-command pulsar-pulse-functions))
> +             (or (memq this-command pulsar-pulse-functions)
> +                 (memq real-this-command pulsar-pulse-functions)))
>      (pulsar-pulse-line)))
>
>  (make-obsolete 'pulsar-setup nil "0.3.0")


Just tried this and it works perfectly! Thank you so much! Looking
forward to the new patch / update :)

Duy