Re: Something like `without-redisplay'?

[Alexander Shukaev]

>> 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.

I'd love to, but I'm no expert with these.  Unfortunately, can't
afford some time for this now.

>> 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.

OK, then here is an example

(save-excursion (scroll-down 10)) ;; just scroll
(previous-line 10) ;; then move point with the method we want

I've tested it and so far, I see no problems with it.  I think there
is another option to do the same like this

(save-window-excursion (previous-line 10)) ;; just move point with the
method we want
(save-excursion (scroll-down 10)) ;; then scroll

Which one is more reliable?  Can I even expect any problems with these codes?

> Horizontal scrolling doesn't move point, AFAIR.

Even if `auto-hscroll-mode' is on (which it is by default)?