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 17:24:08 +0200 Message-ID: References: <83egij1qr5.fsf@gnu.org> <83zj16zwup.fsf@gnu.org> <83h9nechuu.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 1441121072 21646 80.91.229.3 (1 Sep 2015 15:24:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 15:24:32 +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 17:24:31 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 1ZWnQA-0006zs-1F for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 17:24:26 +0200 Original-Received: from localhost ([::1]:55042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnQ9-0002SH-MF for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 11:24:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnPx-0002S4-P9 for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 11:24:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWnPw-0005Zi-Ry for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 11:24:13 -0400 Original-Received: from mail-la0-x231.google.com ([2a00:1450:4010:c03::231]:34473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnPv-0005Yc-2u; Tue, 01 Sep 2015 11:24:11 -0400 Original-Received: by laeb10 with SMTP id b10so2211242lae.1; Tue, 01 Sep 2015 08:24:10 -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=V7SR5sy6UmXjdRyNL8//efpHCtDmEsqnEKMEgIh3Hyw=; b=cKXwuENtvx06mh/B6geWJXB1gbEd7IkaZkJOX5qDJMt3VYSviLLWIFfCHBWlmSQkNP Wv5KX013XZOsa7trX23RYkNm0W4cQhg5XZhPFhKtyEUmFsYKjtMsFjfF+5ThTXqj6jjl 25Vg+1QIHrEkqrZ2VV52D00Bj1iZ0KLRBNqkbI5nwSFtRYX+UKPWBhlNyUqeLf/wQyqL GLaHS63YBdNbYQdE/2ncPFAtZkxP+EsQIMpzdPjHCKdet7VVV5kmOZUv+UwwSNC+sfQe seE4g5tH3I2FJ+LhEYzTw67xdDne0sCcIIL3vCM0e1Nz3WlPP2kZhMazWLiD8FD6We2j wNiA== X-Received: by 10.152.36.41 with SMTP id n9mr13619965laj.65.1441121049050; Tue, 01 Sep 2015 08:24:09 -0700 (PDT) Original-Received: by 10.112.34.17 with HTTP; Tue, 1 Sep 2015 08:24:08 -0700 (PDT) In-Reply-To: <83h9nechuu.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::231 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:106957 Archived-At: >> 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)?