From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alexander Shukaev Newsgroups: gmane.emacs.help Subject: Re: Something like `without-redisplay'? Date: Tue, 1 Sep 2015 15:56:36 +0200 Message-ID: References: <83egij1qr5.fsf@gnu.org> <83zj16zwup.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1441115843 26394 80.91.229.3 (1 Sep 2015 13:57:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 13:57:23 +0000 (UTC) Cc: help-gnu-emacs To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Sep 01 15:57:23 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 1ZWm3u-0003DT-He for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 15:57:22 +0200 Original-Received: from localhost ([::1]:54400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWm3p-0007Li-Cl for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 09:57:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWm3d-0007LA-KO for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 09:57:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWm3c-0006qu-BL for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 09:57:05 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:33089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWm3X-0006OL-9v; Tue, 01 Sep 2015 09:56:59 -0400 Original-Received: by lamp12 with SMTP id p12so172930lam.0; Tue, 01 Sep 2015 06:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zNJPKV/vIyUX+WH1AQ9tbCMtnfly9CrmvMGd1ze2/k0=; b=sBbzCIo74q2pqZ9CC8SrH3z+0FxraaJwA85BScHcNYVUJX4MCTrC5bwI8ZkIqQ+xkT WL7tVGCIPmZ4KSnU8rC3AFFOs452zuoQhznimgluWeRWw16AC/yE7rgw1JCGyOkTj0nS RVl3UC1APDd39gSgcL4mhujrTx+rscPpWR78hf9nIBge1wyQH3pSAi6wVspfOGjquh3h yeGzyGdecKc2OIp/PymdYwxk+mqUnElmTOhYbIfyuuEemZR9GqlJJrduGNGzHA5tzhk4 5vcoGk1EDRfg1RuTfRUUn4eLTiNf6cRLtnlwFnswhMYOQ+ehbf7Qf1JpXS14kmgmSAj3 ci9g== X-Received: by 10.152.1.164 with SMTP id 4mr13291473lan.64.1441115796600; Tue, 01 Sep 2015 06:56:36 -0700 (PDT) Original-Received: by 10.112.34.17 with HTTP; Tue, 1 Sep 2015 06:56:36 -0700 (PDT) In-Reply-To: <83zj16zwup.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::235 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:106954 Archived-At: >> (defmacro devil-without-window-hscroll >> (&rest body) >> "\ >> Execute BODY without horizontal scrolling in the selected window." >> (declare (debug t) >> (indent defun)) >> `(let ((hscroll (window-hscroll))) >> (set-window-hscroll (selected-window) 0) >> (unwind-protect >> (progn ,@body) >> (set-window-hscroll (selected-window) hscroll)))) >> >> In brief, these are macros which somehow alter viewport (how window >> views a buffer) temporarily and then restore it. > > I don't understand the need for that: since redisplay doesn't happen > as long as the code runs, why would you need to manipulate the > viewport like that during the execution, just to have it back by the > time redisplay is about to happen? > >> For instance, if `auto-hscroll-mode' is on, should I fear that >> `set-window-hscroll' will move point? I personally, have not >> experienced this problem, but still I want to know exactly what to >> expect. For example, would you recommend to wrap >> `set-window-hscroll' into `save-excursion' or that would be >> redundant? By the way, the same would apply to vertical changes in >> viewport (due to vertical scrolling, for example) as Emacs >> auto-scrolls (moves point to keep it in viewport) by default. Yet, >> again, I've never experienced any problem with this too. > > In general, hscroll only scrolls if point goes out of view. Vertical > scroll can happen even with point is in view, under some rare > situations. > > But again, I don't understand what you want to accomplish with these > macros, so I cannot answer your questions yet. 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. 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. 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?