From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Something like `without-redisplay'? Date: Tue, 01 Sep 2015 17:52:09 +0300 Message-ID: <83h9nechuu.fsf@gnu.org> References: <83egij1qr5.fsf@gnu.org> <83zj16zwup.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1441119154 19480 80.91.229.3 (1 Sep 2015 14:52:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 14:52:34 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Sep 01 16:52:21 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWmv4-0000Ls-38 for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 16:52:18 +0200 Original-Received: from localhost ([::1]:54837 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWmv3-0008TL-Bz for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 10:52:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWmuo-0008RU-KY for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 10:52:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWmul-00050T-Ud for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 10:52:02 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWmul-0004y9-MI for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 10:51:59 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NU0004006ADKM00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 17:51:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU0004T16MLLN00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 17:51:58 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106956 Archived-At: > Date: Tue, 1 Sep 2015 15:56:36 +0200 > From: Alexander Shukaev > Cc: help-gnu-emacs > > 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.