Re: Something like `without-redisplay'?

[Eli Zaretskii]

> Date: Tue, 1 Sep 2015 15:56:36 +0200
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> This macro is not about redisplay.  I just found one corner case when
> `evil-previous-visual-line' and `evil-next-visual-line' which are
> based on `evil-line-move',
> 
> ;; The purpose of this function is the provide line motions which
> ;; preserve the column. This is how `previous-line' and `next-line'
> ;; work, but unfortunately the behaviour is hard-coded: if and only if
> ;; the last command was `previous-line' or `next-line', the column is
> ;; preserved. Furthermore, in contrast to Vim, when we cannot go
> ;; further, those motions move point to the beginning resp. the end of
> ;; the line (we never want point to leave its column). The code here
> ;; comes from simple.el, and I hope it will work in future.
> (defun evil-line-move (count &optional noerror)
>   "A wrapper for line motions which conserves the column.
> Signals an error at buffer boundaries unless NOERROR is non-nil."
>   (cond
>    (noerror
>     (condition-case nil
>         (evil-line-move count)
>       (error nil)))
>    (t
>     (evil-signal-without-movement
>       (setq this-command (if (>= count 0)
>                              #'next-line
>                            #'previous-line))
>       (let ((opoint (point)))
>         (condition-case err
>             (with-no-warnings
>               (funcall this-command (abs count)))
>           ((beginning-of-buffer end-of-buffer)
>            (let ((col (or goal-column
>                           (if (consp temporary-goal-column)
>                               (car temporary-goal-column)
>                             temporary-goal-column))))
>              (if line-move-visual
>                  (vertical-motion (cons col 0))
>                (line-move-finish col opoint (< count 0)))
>              ;; Maybe we should just `ding'?
>              (signal (car err) (cdr err))))))))))
> 
> behave incorrectly when window has non-zero horizontal scroll.  The
> problem might be deep in how Emacs implements `next-line' or
> `previous-line' or whatever.

More likely, the function in question has  bug.

> But I found a solution, when I use `evil-previous-visual-line' and
> `evil-next-visual-line' in my own functions, I simply wrap their
> calls into the `devil-without-window-hscroll' macro, so that during
> their execution there is no horizontal scrolling.

I'd suggest to find the bug in the function and fix it instead.

> What is important to me, is that the point does not unintentionally
> move as a side effect of `devil-without-window-hscroll'.  That was
> the question basically: can the point move due to application of
> such macros?

It can in rare cases, if you scroll vertically.  It all depends on
what the code does, exactly.

Horizontal scrolling doesn't move point, AFAIR.