Moving the cursor on to a long line causes it to wrap

[kshenoy]

Let's say a line is just shorter than what can be accommodated on the screen and the cursor is at the end of the line. Then if I move off that line and back, the line appears to grow causing it to wrap and then shrink back at the end of beacon's animation.

I'm guessing this is because as a part of beacon's animation, you /add/ some extra characters on to the end of the line to highlight their background?

[Malabarba]

Yes, that's why it happens.

One way to work around it is to enable truncate-line-mode.

[kshenoy]

Is there a way to change the direction of the animation? i.e. instead of adding extra characters and highlighting their background, can we change the background of the characters before the cursor?

I'm not sure how easy/difficult this would be so please feel free to shoot this down.

[Malabarba]

It wouldn't be super hard, because the current functionality already implements the background changing, one would only need to make it go backwards.

[kshenoy]

Would you be able to take this as an enhancement?

[Mallchad]

I really liked the backwards beacon version, but sadly my brain didn't want to go along with it, after multiple tries of trying to get used to it, since #69 has a less smooth animation and changes the behaviour of the beacon too much, instead of 'always shine from the right inwards' You get 'sometimes shines from the right inwards'. So I went away rather disgruntled and saerched for my own solution....

Which goes roughly as follows.

 (setq cemacs-beacon-size 40
        cemacs-beacon-size-padding 10
        )
  ;; FIX: A placeholder fix to prevent beacon from pushng the text around near
  ;; the end of lines
  (defun cemacs-beacon-truncate-to-line ()
    (let* ((point-along-line (- (point) (line-beginning-position)))
           (buffer-width (window-width))
           (point-window-end-distance (abs (- buffer-width point-along-line)))
           (end-distance-padded (- point-window-end-distance
                                   cemacs-beacon-size-padding))
           )
      (setq beacon-size end-distance-padded)
      (when (> end-distance-padded cemacs-beacon-size)
        (setq beacon-size cemacs-beacon-size)
        )
      (when (< end-distance-padded 0)
        ;; Oops, just set it to 0 and move on
        (setq beacon-size 10)
        (message "Failed to calculate a non-intrusive beacon-size, Refusing to blink")
        )
      )
    )
(add-hook 'beacon-before-blink-hook 'cemacs-beacon-truncate-to-line)

This is of course intended to be written in your config. The way it works is it runs a function before shining the becaon which will try to determine how much space we have to work without doing the jarring wrapping behaviour. Currently it checks based on the current window-width and applies a pre-determined 'padding', which both serves to keep it from spilling over to the next line, and provides aethetic padding to ts nicer to look at.

I don't think its particularly robust or good but its what I'm going to be using for now. Hope it helps somebody.

[Mallchad]

I'd like to make a slight ammendment to this comment.

Since writing this I've since learned that it is possible to eclipse variables without the interpreter compiling, so I think you could possibly bind beacon-size as a let variable and trick the variables into using that.

Probably a more robust method.