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.

[mcmillanbb]

This problem seems to be exacerbated by virtual indentation, as happens for example in org mode with org-indent-mode true.
It can also happen with display-line-numbers-mode active, which makes the issue easy to reproduce in plain emacs: in the scratch buffer, with display-line-numbers-mode active, and the point at the end of a line nearly as long as the window, a call to beacon-blink will do this.
(Nearly as long: within the beacon-overlay-length of the right edge.)

It appears that the problem is specifically in beacon--after-string-overlay, which tries to account for visual mode (and make the overlay short enough to not wrap off the screen), but the call to beacon--visual-current-column doesn't take into account the virtual indentation mentioned above.

[Zoybean]

beacon already tries to trim the after-string overlay to fit within the window width (see beacon--after-string-overlay), but the method it uses to obtain the remaining width doesn't take things like visual fill into account.

Something like this seems to work between all my various buffers (with and without visual-fill-columns, line-numbers, and indentation thanks to org-mode), being at-worst too-short by 1:

(defun beacon--width-remainder ()
  "Return the amount of characters that can be displayed past `point' while remaining on the same visual line."
  (-let* ((posn (posn-at-point))
          ((col . _row) (posn-actual-col-row posn))
          (wid (window-width))
          (rem (- wid col)))
    (if (and (eq 0 col)
             (not (bolp)))
        ;; if we're at column 0 but not beginning of a line
        ;; then we're actually just past the end of a visual line,
        ;; not at the start of one. so we're out of room.
        0
      rem)))

the off-by-one could be due to an incorrect choice between window-width, window-body-width, window-text-width, and window-max-chars-per-line, I'm not sure if one of those would work better.

just call it like so:

(defun beacon--after-string-overlay (colors)
  "Put an overlay at point with an after-string property.
The property's value is a string of spaces with background
COLORS applied to each one."
  ;; The after-string must not be longer than the remaining columns
  ;; from point to right window-end else it will be wrapped around.
  (let ((colors (seq-take colors (beacon--width-remainder))))
    (beacon--ov-put-after-string (beacon--make-overlay 0) colors)))

I'll make a PR later if I remember

edit: it looks like it still gets the remainder wrong in mixed-font buffers (e.g. within an org-babel source block), I might tinker more later.