From: Alexander Shukaev <haroogan@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
Subject: Re: Something like `without-redisplay'?
Date: Tue, 1 Sep 2015 17:24:08 +0200 [thread overview]
Message-ID: <CAKu-7WxJYYKFq9uPGr4begwOTUpaY5_zGX83UEiJ70kM+a4xFg@mail.gmail.com> (raw)
In-Reply-To: <83h9nechuu.fsf@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.
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)?
next prev parent reply other threads:[~2015-09-01 15:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-31 9:49 Something like `without-redisplay'? Alexander Shukaev
2015-08-31 14:23 ` Eli Zaretskii
2015-08-31 19:32 ` Alexander Shukaev
2015-08-31 23:37 ` Alexander Shukaev
2015-09-01 2:39 ` Eli Zaretskii
2015-09-01 13:56 ` Alexander Shukaev
2015-09-01 14:52 ` Eli Zaretskii
2015-09-01 15:24 ` Alexander Shukaev [this message]
2015-09-01 15:57 ` Eli Zaretskii
2015-09-01 16:10 ` Alexander Shukaev
2015-09-01 16:47 ` Alexander Shukaev
2015-09-01 17:00 ` Eli Zaretskii
2015-09-01 17:24 ` Alexander Shukaev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKu-7WxJYYKFq9uPGr4begwOTUpaY5_zGX83UEiJ70kM+a4xFg@mail.gmail.com \
--to=haroogan@gmail.com \
--cc=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.